Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> GIT


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 <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 4, 2013 at 9:07 AM, Josh Elser <[EMAIL PROTECTED]> 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.