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

[Michael J Rubinsky]

Quoting Michael M Slusarz <slusarz at horde.org>:

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

They are not an arbitrary snapshot. They contain ONLY changes in the  
specific app/library the branch is for.

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

Sure, and you should create a local branch to do this and merge in the  
changes you wish to test. The added benefit to this is that you can  
test all sorts of combinations of versions to ensure any specific 5_2  
application is BC with existing code. For example, I routinely create  
different local branches containing Horde_5_2 along with only 1 or 2  
other 5_2 apps to test that certain features in one library do not  
assume the latest versions of other applications are installed.

> * 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(?)

But this is now no longer a single topic branch, it contains changes  
to two independent packages. They will be merged in the future, yes,  
but now the changes for ingo exist in two separate places. This is  
unmaintainable going forward.


> * Can't be because a topic branch is only "allowed" to change a  
> particular application/library/directory.  No.

Yes.

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

Sure, that may be ideal (or it may not be), but the fact is we are  
stuck with the current situation for Horde 5.2. That doesn't mean we  
shouldn't enforce true topic branches.


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

Why? This is what we did for Horde 5.1, and what all of the active  
developers have been doing so far for Horde 5.2 with no problems. Why  
is it 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.

That's not the point. I want to be able to pick and choose which  
branch is active. If I checkout IMP_6_2, (or merge it into a local  
testing branch) I want it to contain ONLY changes relevant to IMP.  
Likewise for other applications. Otherwise, it becomes extremely  
difficult to test e.g., Kronolith_4_2 with IMP_6_1, and yes, that does  
need to work.


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

See above. This is exactly why it needs to be separate. Merging  
everything into a single 5_2 branch at this point prevents proper  
testing of code. I would be unable to guarantee (as much as I normally  
can, anyway) any ActiveSync changes I make will work correctly with  
different versions of applications being available. That's unacceptable.

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

....and you still can.

git checkout horde_5_2
git branch h52
git checkout h52
git merge imp_6_2
git merge ingo_4_2
git merge kronolith_4_2

etc...

This takes me a whole 10 seconds. What is absurd about that?

> michael
>
> ___________________________________
> Michael Slusarz [slusarz at horde.org]
>
> -- 
> dev mailing list
> Frequently Asked Questions: http://wiki.horde.org/FAQ
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org


-- 
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: 5849 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/dev/attachments/20131113/7b1cb807/attachment.bin>