Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> [git] Documentation and Plan of Action

Copy link to this message
Re: [git] Documentation and Plan of Action
On Wed, Jun 12, 2013 at 10:45 PM, David Medinets
> It troubles me that we are referring to the master branch as unstable.
> While we are not following the dictums of Agile methodology it is clear to
> me that the master branch should always be potentially releasable. It is
> not a dumping ground for untested features or half-complete code.

I think the master should be generally stable, in the "nightly build"
sense. I thought that's why we discussed feature branches. I think
perhaps we're confusing "latest" and "subject to change prior to
release" with "unstable". This may be a question of semantics. What do
we mean if we say "unstable"? If we're defining it as "latest", "not
release-quality tested", or "subject to change before a release", I
think it's fine to call it "unstable". If we mean "partially completed
features that are not remotely ready to be tested for a release", I
think we definitely don't want that kind of "unstable" in master.

> The SHA1 value of a change tracks it across all branches. No need to
> perform no-op merges. Simply check the branch history to see it contains
> the SHA1 hash you're interested in.

I think it's still useful to merge forward (even if it's an effective
"no-op"), for two reasons:
1) It keeps the history between older supported versions and newer
versions linear, which makes it easier to merge non-"no-op" fixes
across supported versions.
2) It's still useful to record that a bug has been at least considered
and resolved in a newer branch, even if nothing needs to be done.
Simply requiring that the merge process be performed as a part of the
workflow helps prevent bug regression.

Christopher L Tubbs II