accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: [PROPOSAL] 1.7/2.0 branches and git workflow change
Date Tue, 07 Oct 2014 16:36:32 GMT
On Tue, Oct 7, 2014 at 9:49 AM, William Slacum <
wilhelm.von.cloud@accumulo.net> wrote:

>
> I think Christopher's real issue (re: #2) is that it's ambiguous what
> bleeding-edge/trunk development should look like, because we don't have a
> defined goal. I proposed getting rid of master, or treating the 1.7 branch
> master, because we really don't know what 2.0 will look like yet. Divergent
> histories doesn't solve that.
>
>

I am a strong -1 on getting rid of master. Especially now that we are
talking about getting 1.7 out the door, we need a place that is for future
facing work so that 1.7 can start stabilizing. We will generally need a
place like this and it doesn't make sense to name it for a version e.g. if
we might end up with 1.8.



> As for tracking which issues are in a release, you do remove noise if you
> have a fix that only goes in a historical branch. That's about it, because
> it's still a function of good commit messages (which we're pretty awful at,
> if you subscribe to kernel-style commit message convention) to even infer
> which Jira issues are in some graph of history.
>

Even with just a jira id I can automate pulling the subject out of jira,
which we're generally better at setting to something useful. We have gotten
*loads* better at including a jira id (there were 2 missing in the last
month).



>
> Sean, you keep mentioning a release manager opting out-- how would that
> process go, in your mind? Would a release manger revert commits, or rewrite
> history to remove/delete commits? Could release managers for 2.0 and 1.7
> decide differently on whether or not they want to include a fix from 1.6?
>
>
In the commit-then-cherry-pick approach either the RM would give guidelines
for what they want included, give a sign-off on specific patches they want
included (on jira I guess?), or they could be responsible for all
cherry-picks to the branch depending on their temperament.

I suppose this could also be done in the merge-forward model, but it
results in even more complicated histories and/or a worsening of the "did
this jira actually impact this branch" issue.

And yes, the RMs could decide differently on if a fix had acceptable side
affects for their branch, which could lead to things like a bug being fixed
in 1.6.2  and master but not in 1.7.0. In practice we would deal with this
the way we mostly do now: through discussion, alternative solutions, and
release notes.

-- 
Sean

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message