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

Switch to Threaded View
Accumulo, mail # dev - GIT


Copy link to this message
-
Re: GIT
Josh Elser 2013-06-04, 14:01
On 6/4/13 9:35 AM, Keith Turner 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?

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.

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

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.