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

[Michael J Rubinsky]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>>
>>> 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.
>>
>> Unfortunately I have had one client (and one potential client) both  
>> ask me why activity in Horde seems to be lessening lately.  And why  
>> a feature I had added didn't show up in github - because they don't  
>> understand the concept or they don't understand where to look by  
>> default.
>>
>> Not to mention that if you actually clone our git repo, what is  
>> ALWAYS the default branch?  master.
>
> And this still makes sense to me, because I think that people expect  
> a usable, mostly stable code if they checkout our source. And this  
> is exactly what master gets them. But whatever we decide to put in  
> master, we should communicate this better.
> One option could be to have a separate README.md in the different  
> branches that are only used for Github, i.e. not distributed with  
> the release packages to not confuse users. These README.md files  
> would contain a shorter version of the original README files and a  
> note that the user is currently looking at the current  
> stable|development|whatever branch.

Agreed. If people want to use non-stable, bleeding edge code, they  
should explicitly have to checkout that code. It's not too much to  
expect people using this code to be familiar with how git works. After  
all, branching is central to the development model with git.


-- 
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/20130327/763b4e81/attachment.bin>