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
+
Mike Drob 2013-06-11, 23:10
+
Josh Elser 2013-06-11, 23:18
+
Mike Drob 2013-06-11, 23:25
Copy link to this message
-
Re: [git] Documentation and Plan of Action
Josh Elser 2013-06-11, 23:39
Cool.

I don't want to go into super-specifics in the write-up, but I can
probably work something into the developer section similar to your quote
of ... myself... About OBE changes between versions :)

Thanks for the feedback, Mike.

On 06/11/2013 07:25 PM, Mike Drob wrote:
> Great, makes sense.
>
>> [...]after making the changes in version1, it is your responsibility to
> make sure whatever necessary variants exist in their appropriate versions.
>
> +1 Something like this should go into the documentation.
>
>
> On Tue, Jun 11, 2013 at 7:18 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
>
>> It's not an empty commit. It's just circumstantial that the changes for
>> your commit are empty. The fact that you noted "changes X version version1
>> should not be applied to version2" is important and that merge tracks such
>> information.
>>
>> The same is applicable when version1 and version2 depend on two different
>> versions of a dependency. Say your new code in version1 calls a method
>> whose signature changed in said dependency from the version version1
>> depends on as opposed to the version of the dependency version2 depends on.
>> Point being, after making the changes in version1, it is your
>> responsibility to make sure whatever necessary variants exist in their
>> appropriate versions.
>>
>>
>> On 06/11/2013 07:10 PM, Mike Drob wrote:
>>
>>> 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://**m**ail-archives.apache.org/mod_**<http://mail-archives.apache.org/mod_**>
>>>>>> mbox/accumulo-dev/201305.mbox/****%****3CCAL5zq9bH8y0FyjXmmfXhWPj8axo*
>>>>>> ***
>>>>>> sn9dZ7%2Bu-R1DK4Y-WM1YoWg%**40**mail.gmail.com<http://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>
+
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