Here is the git flow we use w/ Apache Kafka https://cwiki.apache.org/confluence/display/KAFKA/Git+Workflow
folks have liked the transition from svn IMHO On Tue, Jun 4, 2013 at 2:34 PM, Christopher <ctubb...@apache.org> wrote: > Personally, I'm fine with not having a super-long running release > branch, but I like them for a few reasons: > > 1. It doesn't force rapid releases that are time-consuming and require > testing, but we still have that option if we want. > 2. We can batch a few bugfixes and work on a bugfix release schedule > for nice-to-have, but not urgent bugfixes (patch Tuesdays? :) > 3. We're going to create this branch anyway, so we can stabilize > things for testing prior to release... so why not leave it around for > bugfixes? > 4. Pretending we won't have bugfixes for a prior release is possibly > delusional, and it seems like it doesn't really avoid anything > regarding merging over multiple branches... when we patch, we'll just > have to create these branches from their respective tags before we do > this process. It doesn't seem to save us from this merging process. > > In short, I don't think leaving these branches around diverges from > the proposed branching model... it just keeps them around until we > decide that branch is EOL. If we leave a branch around until it > reaches EOL, and we never make a bugfix in it, then no big deal, no > harm done... just delete the branch at EOL. > > I think branches should be hierarchical for subprojects and contribs, > as in: contrib/InstamoOrWhatever (unless there's a better way to > handle contribs...?) > > I think ticket/feature branches should be deleted after they've merged > back to develop, and should also be hierarchical, as in: > feature/ACCUMULO-9001 > > As for tags, I'm not comfortable tagging anything we haven't voted on > as an official release, and I think the time-consuming nature of that > should be factored in, when considering these long-running bugfix > branches for a release line. > > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > > On Tue, Jun 4, 2013 at 9:35 AM, Keith Turner <ke...@deenlo.com> wrote: > > On Tue, 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 > > > > > > Why? What problems are you thinking of w/ long-running minor release > > branches? > > > > > >> 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. > >> > >> > > It seems like you have a specific workflow in mind, but its not clear to > me > > exactly what you are thinking. Are you planning on elaborating on this > > tonight? Is this workflow written up somewhere? If its not written up, > a > > few quick example scenarios would probably help me get on the same page. > > > > > >> 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 > >>>> > >>> > -- /* Joe Stein http://www.linkedin.com/in/charmalloc Twitter: @allthingshadoop <http://www.twitter.com/allthingshadoop> */
