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

[Vilius Šumskas]

Michael J Rubinsky <mrubinsk at horde.org> rašė:

> 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.

Looking at current Github dashboard page made me finally realise that  
splitting every application and every library into separate  
repositories is a way to go (the opposite I thought a year ago). It is  
starting to be confusing to see all those branches and thousands of  
tags in one repository even though I need only couple of libraries and  
two application from it.

Also I totally agree with Michael M for making master a HEAD branch  
and branching x.1 branches starting with alpha (or beta) step in a  
release cycle.

-- 
   Vilius