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

[Jan Schneider]

Zitat von Vilius Šumskas <vilius at lnk.lt>:

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

I feel very much the same. A year ago I was still in favor of a single  
repository to easier test and commit changes across different  
packages. The more important CI and distribution techniques like  
Composer become, the more I see the disadvantages of that model, like  
Gunnar outlined them already long ago.

I would take that route completely though and create separate  
repositories for each framework package too. I wonder if there are  
limits for the number of public repos per organization in Github? IIRC  
we already tried to find that out in the past.

> 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


-- 
Jan Schneider
The Horde Project
http://www.horde.org/