Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
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>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB