accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: [git] Documentation and Plan of Action
Date Thu, 13 Jun 2013 04:21:27 GMT
On Wed, Jun 12, 2013 at 10:45 PM, David Medinets
<> 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.

> 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

View raw message