[dev] [commits] Horde branch mnemo_4_1 updated. 7324877f91d83f8de26d41ba7ca05be559255994

[Michael J Rubinsky]

Quoting Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>>
>>>> I still think we need to look at making master the git HEAD  
>>>> branch and having "release" branches.  This helps with merge  
>>>> conflicts since those who commit a general fix to the release  
>>>> branch also have to concurrently commit such a fix to the master  
>>>> branch, and they are in the best position to resolve merge  
>>>> conflicts rather than having a later committer try to figure this  
>>>> out later.  This would also enforce the fact that only bug fixes  
>>>> should go into the release branch, since its a PITA to have to  
>>>> make multiple commits if you are developing something that is a  
>>>> new feature instead.
>>>
>>> Those are good points pro your argumentation for a different  
>>> branching model.
>
>> More points:
>>  - Currently, we have all sorts of topic branches for the x.1  
>> versions.  But this means that changes to each individual topic  
>> branch are probably not being tested by others.  I pretty much run  
>> imp_6_1 myself, but I don't get a chance to test turba_4_1 at all -  
>> I'm just switching to it, committing, and then switching back.  For  
>> total code coverage, it sort of makes sense if us developers are  
>> testing all next-generation versions at this point, rather than  
>> dumping them all into a common branch a month before releasing.
>
> I've been running on a local branch, that I merge all the x.1  
> branches into. In fact, I've been developing directly against this  
> local branch and either switching branches or cherry-picking the  
> commits into the correct topic branch before pushing, depending on  
> the number of commits/changes involved.
>
> I just use a short shell script to manage the checkout, pulling and  
> merging of the upstream topic branches into my combined branch. It  
> was a major pita at first, but I've gotten to like this approach  
> since it makes it easy to test not only all of the cutting edge code  
> against each other, but also to test the x.1 changes of an  
> individual package against the rest of the x.0 stable code to assure  
> there are no BC breaking surprises.
>
>>  - An increasing presence for those wanting to look at the latest  
>> features/advancements in IMP is our page on github.  As it stands  
>> now, you go to that page and it sort of looks like progress has  
>> stagnated/slowed since the release of H5 (since master is always  
>> the default branch shown).  That couldn't be farther from the  
>> truth.  And there is very little indication that the current x.1  
>> topic branches are important.  After all - H4-Icalendar branch  
>> appears much more prominently than horde_5_1, for e
>
> An interesting point, but not an argument in and of itself for  
> switching our branching model. We shouldn't let Github's UI dictate  
> how we organize our repository.

..and while I agree the default "code" page shows only master's  
history by default, the "branches" and "graph" pages do show there has  
been activity - even if it's not as in-your-face as a list of commits  
might be.
-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6062 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.horde.org/archives/dev/attachments/20130326/07e3f63f/attachment.bin>