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


Also, I think short-lived feature/bugfix/etc. branches make sense in
the form, "<apacheID>/ACCUMULO-<issue#>".

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Tue, Jun 4, 2013 at 6:09 PM, Christopher <[EMAIL PROTECTED]> wrote:
> I can get behind this also, but I have an additional suggestion that
> diverges from the proposed model at
> http://nvie.com/posts/a-successful-git-branching-model/ (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
> http://gravatar.com/ctubbsii
>
>
> On Tue, Jun 4, 2013 at 5:51 PM, Keith Turner <[EMAIL PROTECTED]> wrote:
>> On Tue, Jun 4, 2013 at 10:01 AM, Josh Elser <[EMAIL PROTECTED]> wrote:
>>
>>> 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.
>>>
>>
>> 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 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.
>>>>> >
>>
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