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

Switch to Plain View
Accumulo, mail # dev - [git] Documentation and Plan of Action


+
Josh Elser 2013-06-05, 03:04
+
Josh Elser 2013-06-06, 01:58
+
Josh Elser 2013-06-11, 02:44
+
Sean Busbey 2013-06-11, 11:16
+
Josh Elser 2013-06-11, 12:55
+
Mike Drob 2013-06-11, 15:44
+
Josh Elser 2013-06-11, 16:05
+
Christopher 2013-06-11, 16:26
+
Josh Elser 2013-06-12, 00:46
+
Christopher 2013-06-12, 19:49
+
David Medinets 2013-06-13, 02:45
+
Christopher 2013-06-13, 04:21
+
Josh Elser 2013-06-13, 02:59
Copy link to this message
-
Re: [git] Documentation and Plan of Action
Mike Drob 2013-06-11, 23:10
It was originally a general question, because I wasn't sure on what the
proper answer.

Actually, I'm still not quite clear - should the person who did the fix for
Version1 immediately do a merge into Version2 with an empty commit so that
history looks pretty? Or is it better to wait until the next merge and then
fix it as it happens? The first option sounds less liable to bite somebody
in the rear.

Probably worth expounding on the example work-flow in the documentation
though.
On Tue, Jun 11, 2013 at 12:05 PM, Josh Elser <[EMAIL PROTECTED]> wrote:

> The person who implements the workaround in Version1 should ensure that
> when Version1 is merged into Version2, the correct code is present in
> Version2.
>
> Do you think this merits a section on the document or was this a general
> question?
>
>
> On 6/11/13 11:44 AM, Mike Drob wrote:
>
>> How do we handle the following situation:
>>
>> There are two active development branches - versions 1 and 2. Branch 1
>> uses
>> external library  version 7, while Branch 2 uses external library version
>> 9. It is discovered that version 7 of the external library has a bug, with
>> a known workaround. In this case, the workaround should be applied to
>> branch 1, but does not need to be applied to branch 2. What is the
>> git-friendly way to make these changes, not merge them into the later
>> branch, but still have a proper history and allow future fixes against
>> branch 1 to merge cleanly?
>>
>> Mike
>>
>> On Tue, Jun 11, 2013 at 8:55 AM, Josh Elser <[EMAIL PROTECTED]> wrote:
>>
>>  Sean,
>>>
>>> I was referring to Christopher's notes on the maven commands; using the
>>> release plugin, making RCs, publishing to the ASF staging area, promoting
>>> to the RC if the vote passes, etc.
>>>
>>> http://mail-archives.apache.****org/mod_mbox/accumulo-dev/****
>>> 201305.mbox/%**
>>> 3CCAL5zq9bH8y0FyjXmmfXhWPj8axo****sn9dZ7%2Bu-R1DK4Y-WM1YoWg%**
>>> 40mail.gmail.com%3E<http://**mail-archives.apache.org/mod_**
>>> mbox/accumulo-dev/201305.mbox/**%**3CCAL5zq9bH8y0FyjXmmfXhWPj8axo**
>>> sn9dZ7%2Bu-R1DK4Y-WM1YoWg%**40mail.gmail.com%3E<http://mail-archives.apache.org/mod_mbox/accumulo-dev/201305.mbox/%3CCAL5zq9bH8y0FyjXmmfXhWPj8axosn9dZ7%2Bu-R1DK4Y-WM1YoWg%40mail.gmail.com%3E>
>>> >
>>>
>>>
>>> I don't believe that information is markdown-ified/CMS'ed at all.
>>>
>>> I did add the high-level release guide to that comment with a place
>>> holder
>>> for when we get the specifics also written down on the CMS.
>>>
>>>
>>> On 6/11/13 7:16 AM, Sean Busbey wrote:
>>>
>>>  Release Guide:
>>>>
>>>> http://accumulo.apache.org/****governance/releasing.html<http://accumulo.apache.org/**governance/releasing.html>
>>>> <http**://accumulo.apache.org/**governance/releasing.html<http://accumulo.apache.org/governance/releasing.html>
>>>> >
>>>>
>>>>
>>>>
>>>> On Mon, Jun 10, 2013 at 10:44 PM, Josh Elser <[EMAIL PROTECTED]>
>>>> wrote:
>>>>
>>>>   Alright, I think I covered all of the content that's needed.
>>>>
>>>>>
>>>>> http://people.apache.org/~******elserj/git/git.html<http://people.apache.org/~****elserj/git/git.html>
>>>>> <http://**people.apache.org/~**elserj/**git/git.html<http://people.apache.org/~**elserj/git/git.html>
>>>>> >
>>>>> <http://**people.apache.org/~**elserj/git/**git.html<http://people.apache.org/~elserj/git/**git.html>
>>>>> <http://**people.apache.org/~elserj/git/**git.html<http://people.apache.org/~elserj/git/git.html>
>>>>> >
>>>>>
>>>>>
>>>>>>
>>>>> Disclaimer, I actually got Christopher to say "it's kind of long...".
>>>>> Yes,
>>>>> this was intended. I'd rather be (painfully) explicit front and lift
>>>>> out
>>>>> a
>>>>> TL;DR version from the master document.
>>>>>
>>>>> _Please_ give feedback now as to what is still unclear about after
>>>>> reading
>>>>> the document. I'd hate to have wasted all of this time writing this to
>>>>> just
>>>>> change our minds again in the near future
>>>>>
>>>>> Also, please look for text in _emphasis_ as these are things which I do
>>>>
+
Josh Elser 2013-06-11, 23:18
+
Mike Drob 2013-06-11, 23:25
+
Josh Elser 2013-06-11, 23:39
+
Christopher 2013-06-12, 20:21
+
Josh Elser 2013-06-12, 22:15
+
Christopher 2013-06-12, 23:09
+
Drew Farris 2013-06-13, 01:05
+
Josh Elser 2013-06-13, 01:16
+
David Medinets 2013-06-13, 02:48
+
Josh Elser 2013-06-13, 02:52
+
Drew Farris 2013-06-13, 01:38
+
Josh Elser 2013-06-13, 02:00
+
Josh Elser 2013-06-13, 03:23
+
Christopher 2013-06-13, 05:16
+
John Vines 2013-06-13, 17:36
+
Christopher 2013-06-13, 17:49
+
John Vines 2013-06-13, 17:55
+
Corey Nolet 2013-06-13, 20:26
+
Josh Elser 2013-06-13, 23:54
+
Josh Elser 2013-06-13, 23:52
+
Eric Newton 2013-06-12, 22:52
+
Christopher 2013-06-12, 21:35