[dev] [commits] Horde branch imp_6_2 updated. 0f66952d02819f2f48506987d27e5d6ebda1b071

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>> The branch "imp_6_2" has been updated.
>> The following is a summary of the commits.
>>
>> from: 6be4899f38615d05cc40e2b42c3bb253b1aad3e9
>>
>> 0654001 Remove regex example
>> a155547 Update help file.
>> a3fc983 Use session token instead of Horde_Token
>> 0f66952 Merge branch 'ingo_3_2' into imp_6_2
>
> Do NOT merge other development branches into imp_6_2! Please revert  
> the merge of horde_5_2 and ingo_3_2 ASAP. If you want to test  
> different development branches, create a local branch where you  
> merge to.

Why?

* Can't be because the versions contained in master are special for  
any reason.  They are just an arbitrary snapshot.  Makes a lot more  
sense to test the new development code against the code that users are  
likely going to install.  Meaning: it makes much more sense to run IMP  
6.2 against Ingo 3.2 and Horde 5.2, since those are the versions that  
are going to exist in the real world when formally released.

* Can't be because of merging concerns.  All these branches are going  
to be merged into master.  And they will apply cleanly.  That's all  
you can ask for from a topic branch(?)

* Can't be because a topic branch is only "allowed" to change a  
particular application/library/directory.  No.  If we want this, we  
need separate repos -- which would be GREAT, and I've been pushing for  
this for awhile now, but that's not the current situation.  Regardless  
- **I** forked imp_6_2 in the first place.  It was meant to be a  
branch that contains all the changes in IMP that will be released in  
version 6.2.  It was never intended, and can't under a monolithic  
repo, to be a branch that only contains changes within the imp  
directory.  That's absurd.  It is trivial to figure out what has  
changed between a directory in a topic branch and master, so there's  
no reason to artificially enforce that at the branch level.

* Can't be because this isn't a better way to actually test the code.   
Bug reports/fixes are occurring ONLY because this code has been merged  
into the imp branch and is being used (for the record, I'm not the one  
finding a lot of these bugs either.  So telling me that it is MY  
responsibility to create a branch that combines all this code is doing  
nothing more than removing eyeballs from the code).  Otherwise, you  
make the changes in ingo_3_2 and then nobody uses the damn branch and  
then we dump it all into master and make some release candidates and  
then release code that hasn't been tested fully with the code that is  
using it - i.e. other applications.  Ingo 3.2 is not being used in a  
vacuum - it is being used in relation to other applications.

In other words: we need to keep all the shitty aspects of a monolithic  
repository without being able to leverage the one major benefit a  
monolithic repo has - to be able to switch between branches and be  
able to have a working system to test?  No.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]