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

[Michael J Rubinsky]

Quoting Ben Klang <bklang at horde.org>:

> On Mar 26, 2013, at 5:13 PM, Michael J Rubinsky <mrubinsk at horde.org> wrote:
>
>>
>> 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.
>
> Not dictate, no, but I'd like to make the point that Github brings a  
> lot of visibility to a project.  If it doesn't cause a negative  
> impact to our workflow, I think there is value in making our  
> activity visible there.  Github is fantastic for turning bug  
> reporters into contributors, largely by way of pull requests.   
> Social Coding isn't just a slogan they use, I've seen it in action  
> and I'm a believer.  /me steps out of pulpit.

Don't get me wrong, I love github. In fact, I use it over Chora for my  
daily needs. I just don't think that the lack of commit history for  
every active branch on the front page is reason enough to take the  
drastic step of reorganizing our branching model.


> One other thing: we can tell Github what our "default" branch is.   
> If that branch is not "master" then we can change it so the landing  
> page for Horde shows better activity.  Perhaps that is a middle  
> ground here.

Perhaps, but it's not a solution that can work with our current branch  
structure. Each application/library has it's own x.1 development  
branch, no since one could really be seen as a good candidate for a  
default branch to show.
-- 
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/79921dbe/attachment-0001.bin>