Sorry about that, didn't catch that I'm the thread.
On Jun 4, 2013, at 10:04 AM, Josh Elser <josh.el...@gmail.com> wrote: > Aaron, yeah, I presented that as an option (or at least a good read). The > premise is good, although I don't think we would want to implement that 100% > as it just doesn't jive with how we do releases. > > Thanks for re-copying that, though. I'd encourage anyone who wants to discuss > workflow to take a moment and read that page and consider it from a > high-level. > > On 6/4/13 9:41 AM, Aaron G wrote: >> 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 >>
