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

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>