accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Stein <crypt...@gmail.com>
Subject Re: GIT
Date Tue, 04 Jun 2013 18:39:10 GMT
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 <ctubbsii@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 <keith@deenlo.com> wrote:
> > On Tue, Jun 4, 2013 at 9:07 AM, Josh Elser <josh.elser@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 <ctubbsii@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>
*/

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