accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: GIT
Date Tue, 04 Jun 2013 20:15:52 GMT
On 6/4/13 2:34 PM, Christopher 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 just want to keep make note that this will affect things much more 
than previously in SVN as a merge is more than a guess at metadata.

If you have long-lived branches, this necessitates that there are very 
many viable options in which a bug-fix can be applied (any branch at 
all).  Not keeping these around will force the developer to think about 
where their fix is supposed to go (earliest, non-EOL'ed version).

Again, this is mostly a stylistic argument, and where I tend to disagree 
with you. :)

> I think branches should be hierarchical for subprojects and contribs,
> as in: contrib/InstamoOrWhatever (unless there's a better way to
> handle contribs...?)

I believe we'll need to make separate repos for subprojects and 
contribs. This is one of the things I need to investigate how it's 
currently handled. New repos are certainly the easiest to manage.

> 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

Works for me.

> 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.

I personally like being tag-heavy; however, there is a fine line here as 
I already stated. There's no reason to not make a tag for something 
you're working on in a feature branch that you want to share with 
someone else (while you continue work on that feature). They can 
checkout that tag which is assumed stable to an extent (the reason you 
wanted someone else to pull it in the first place) and then make a 
branch if they want to change something.

Point being, I do not want to preclude developers from making tags 
unless it's an ASF release as I believe this gimps Git quite a bit. IMO, 
for tags, the line should be drawn between "internal" and "external". 
Tags advertised or intended for public use should (probably) be voted 
on, while internal-only intended (doesn't preclude someone from finding 
and downloading themselves) are encouraged.

> --
> Christopher L Tubbs II
> On Tue, Jun 4, 2013 at 9:35 AM, Keith Turner <> wrote:
>> On Tue, Jun 4, 2013 at 9:07 AM, Josh Elser <> 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
>>>> On Tue, May 21, 2013 at 5:44 PM, Christopher <>
>>>>> 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

View raw message