accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron G <>
Subject Re: GIT
Date Tue, 04 Jun 2013 14:09:51 GMT
Sorry about that, didn't catch that I'm the thread.  

On Jun 4, 2013, at 10:04 AM, Josh Elser <> 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:
>> as a branching strategy.
>> Sent from my iPhone
>> On 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
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
>>>> 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