Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

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


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.
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB