Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
<[EMAIL PROTECTED]> wrote:
> 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.

[snip]
> 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.
[snip]

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
http://gravatar.com/ctubbsii
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB