On Tue, Oct 7, 2014 at 9:49 AM, William Slacum < wilhelm.von.cl...@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
