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

Switch to Threaded View
Accumulo >> mail # dev >> [git] Documentation and Plan of Action


Copy link to this message
-
Re: [git] Documentation and Plan of Action
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>
>>>>> >
>>>>>
>>>>>
>>>>> 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: