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

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


+
Christopher 2013-05-21, 21:44
+
John Vines 2013-05-21, 21:51
+
Corey Nolet 2013-05-21, 22:06
+
David Medinets 2013-05-21, 22:05
+
Christopher 2013-05-21, 22:12
+
Benson Margulies 2013-05-21, 22:25
+
Mike Drob 2013-05-21, 22:25
+
Mattmann, Chris A 2013-05-21, 22:28
+
Benson Margulies 2013-05-21, 22:29
+
Michael Wall 2013-05-21, 23:32
+
Keith Turner 2013-05-22, 14:32
+
Billie Rinaldi 2013-05-22, 14:40
+
Josh Elser 2013-05-22, 14:57
+
David Medinets 2013-05-23, 00:42
+
John Vines 2013-05-23, 00:47
+
Jason Trost 2013-05-23, 12:23
+
Josh Elser 2013-05-23, 13:08
+
Christopher 2013-05-23, 15:40
+
David Medinets 2013-05-23, 18:02
+
Jason Trost 2013-05-26, 18:54
+
Billie Rinaldi 2013-05-26, 19:15
+
David Medinets 2013-05-22, 00:25
+
Josh Elser 2013-05-21, 22:27
+
Christopher 2013-06-01, 20:28
+
Jason Trost 2013-06-02, 17:54
+
Josh Elser 2013-06-04, 13:07
+
Drew Farris 2013-06-05, 02:05
+
Benson Margulies 2013-06-05, 02:24
+
Josh Elser 2013-06-05, 02:16
+
Benson Margulies 2013-06-05, 02:26
+
Sean Busbey 2013-06-05, 02:46
+
Christopher 2013-06-05, 03:35
+
Josh Elser 2013-06-05, 02:49
+
Keith Turner 2013-06-05, 12:44
+
Josh Elser 2013-06-05, 13:16
+
Keith Turner 2013-06-05, 14:51
+
Josh Elser 2013-06-05, 16:23
+
Christopher 2013-06-05, 16:29
+
Billie Rinaldi 2013-06-05, 16:48
+
Christopher 2013-06-05, 17:07
+
Aaron G 2013-06-04, 13:41
+
Josh Elser 2013-06-04, 14:04
+
Aaron G 2013-06-04, 14:09
+
Keith Turner 2013-06-04, 13:35
+
Josh Elser 2013-06-04, 14:01
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.
>>> >
>>> >
>>>
>> 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.
>>>
>>
+
Christopher 2013-06-04, 22:09
+
Christopher 2013-06-04, 22:11
+
David Medinets 2013-06-04, 22:27
+
Billie Rinaldi 2013-06-05, 12:17
+
David Medinets 2013-06-05, 16:49
+
Christopher 2013-06-05, 16:59
+
Christopher 2013-06-04, 18:34
+
Joe Stein 2013-06-04, 18:39
+
Drew Farris 2013-06-05, 01:37
+
Josh Elser 2013-06-04, 20:15
+
Christopher 2013-06-04, 21:05
+
Josh Elser 2013-06-14, 01:41