You may want to look at: http://nvie.com/posts/a-successful-git-branching-model/
as a branching strategy. Sent from my iPhone On Jun 4, 2013, at 9:07 AM, Josh Elser <josh.el...@gmail.com> wrote: > Yay, Git. Wait... > > I was going to wait to respond until I collected all of the info, but since I > still haven't gotten that done yet, I figured I should just say "sure". > > The one thing I do want to get hammered out is the general workflow we plan > to use. I believe that one "unstable" or "development" branch will satisfy > most use cases as we typically don't have much active development against > previous major releases. > > The thing I don't care for (putting it mildly) is long-running minor-release > branches. I'm curious of suggestions that people might have for how to work > around this. One possibility would be to be git-tag heavy while being more > lax on official apache releases. > > Merits: > - Less merging through 2-3 branches which a bug-fix might apply > (1.4->1.5->1.6) > - Less clutter in the branch space (could be moot if we impose some sort of > "hierarchy" in branch names, e.g. bugfixes/ACCUMULO-XXXX, minor/ACCUMULO-XXXX) > - Quicker availability of fixes for consumers (after a fix, a new tag is made) > > Downsides: > - Could create more work for us as we would be noting new minor releases. > Does Christopher's release work mitigate some/most of this? > - Creating git-tags without making an official release _might_ skirt a line > on ASF releases. Some artifact that is intended for public consumption is > meant to follow the release process. > > Personally, I'd consider making the bold assumption that, over time, we will > create the infrastructure for ourselves to make better and better releases > which will also mitigate this. I'm curious what everyone else thinks. > > I'll try to make time tonight to get info on all of the necessary below. > > On 6/1/13 4:28 PM, Christopher wrote: >> Reviewing this thread, it seems everyone is pretty much in favor of >> this. I propose we proceed by electing a "git transition advisor"... >> someone who: >> >> 1) is sufficiently knowledgeable with git to identify roadblocks >> during the transition and is willing to make it a point to propose and >> follow through with solutions, >> 2) can serve as the main point of contact with INFRA tickets related >> to the transition, >> 3) can advise other developers on best practices for things like when >> to branch, where to put contribs, when to delete a branch (if ever), >> etc. for things related to the shared repo. >> >> Item 3 is really something we can all do to the extent that our >> expertise allows, but it'd be nice to have somebody willing to do item >> 2, in the context of their experience in item 1. >> >> I would like to nominate Josh Elser, because I think he's qualified, >> and because his exact response to this inquiry was "Yay, git." >> >> -- >> Christopher L Tubbs II >> http://gravatar.com/ctubbsii >> >> >> On Tue, May 21, 2013 at 5:44 PM, Christopher <ctubb...@apache.org> wrote: >>> I'm sure this has been entertained before, I'm starting to think that >>> we should seriously consider switching to git, maybe sooner (during >>> 1.6 development cycle?). >>> >>> -- >>> Christopher L Tubbs II >>> http://gravatar.com/ctubbsii
