accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: GIT
Date Tue, 04 Jun 2013 22:09:15 GMT
I can get behind this also, but I have an additional suggestion that
diverges from the proposed model at (suggested
earlier in this thread):

I'm not a fan of separate "master" and "develop" branches, since
"master" is only used as a pointer for tracking the latest and
greatest stable tag. I think just a "master" would be fine (for active
development on the next anticipated major release), because I think
it's safe to assume people know what tags are and how to use them if
they want a stable version. If we *really* need a pointer, I'd rather
call it "stable", as it's more explicit.

Christopher L Tubbs II

On Tue, Jun 4, 2013 at 5:51 PM, Keith Turner <> wrote:
> On Tue, Jun 4, 2013 at 10:01 AM, Josh Elser <> wrote:
>> On 6/4/13 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?
>> I do not like them. It's mainly a personal opinion. Most modern SCM tools
>> (even that 'terrible' SVN) strongly encourage you to release early and
>> often. As such, I don't like having branches named like tags/releases. This
>> is mostly a personal opinion; however, you can also read that as opinions
>> after using git for ~5 years.
> Discussed this w/ Christopher and Josh.  I understand Josh's point of view
> a bit better now.  One thing I was unsure about was what to name these
> transient branches for gathering bug fixes.  Christopher suggested using
> snapshots, which seems very natural to me.
>   * For serious bugs in 1.4.3  take 1.4.3 tag and create 1.4.4-SNAPSHOT
> branch
>   * Merge bug fixes to 1.4.4-SNAPSHOT from bug fix branches
>   * Eventually tag 1.4.4 and delete 1.4.4-SNAPSHOT branch
>   * 1.4.5-SNAPSHOT would only be created on an as needed basis.
> I think this is nicer than leaving a 1.4 branch around.
>>>  >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
>>>> >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
>>>> >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.
>> That's correct. I don't have the time to make a good write-up right now.
>> I'll try to outline what I think would work fully tonight, but I tried to
>> outline the general gist of what I think is best.
>>>  >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.

View raw message