[dev] Branches (again), Horde 4.1/5, recent IMAP changes
Michael J Rubinsky
mrubinsk at horde.org
Wed Nov 2 20:05:10 UTC 2011
Quoting Michael M Slusarz <slusarz at horde.org>:
> Quoting Jan Schneider <jan at horde.org>:
>
>> But that's not the only thing we changed for Horde 4, we also
>> intended to set new rules for release management
>> (http://wiki.horde.org/Doc/Dev/ReleaseCycle) and branch management
>> (http://wiki.horde.org/Doc/Dev/Branches). This is the area where we
>> still need to improve.
>
> So here's an example where I don't believe our current branching
> model falls apart.
>
> I have code that adds the ability for portal blocks to only load the
> CSS necessary for the portals themselves, rather than the entire
> application's CSS load. (For simplicity, all of an application's
> CSS is stored in a single file rather than a CSS file for each
> portal block).
>
> The code to do this in Horde/Core is trivial - no more than 30
> lines. It does add a dependency on a new method in
> Horde_Core_Block_Layout_View, but this could be easily worked around
> by bumping the minimum dependency in horde. I've also finished the
> code that converts imp, ingo, and turba to this new feature. Old
> applications are not affected, since if a 'block' subdirectory is
> not found in a theme it defaults back to loading the entire CSS.
>
> Given the recent discussion on code changes - I personally feel this
> is not a serious enough change to have to wait until the next minor
> release. Granted, this is not a bug fix but it is a pretty
> substantial performance gain (especially for IMP blocks, where the
> CSS is substantial).
>
> However, assuming that this should wait until the next minor
> release, where should it go. It can NOT go into the develop branch.
> The necessary changelog entries and package dependencies are
> unknown as of this time, so this change can not be packaged into a
> single commit.
Could you elaborate on why this can NOT go in develop? I don't
disagree that the develop branch is a little awkward to use in some
cases, but I'm curious why you think so strongly that this shouldn't
go in there.
For me, some of my issues with using develop might go away once we all
start using it more, and get in the habit of *always* merging changes
from master into develop.
Putting it into a topic branch is not very useful either -
> not only is there no indication anywhere that this needs to get
> merged for the next minor release, but having this code living in a
> random topic branch means 1) nobody is going to see/use/test it, and
> 2) there is no indication that this code will play nice with other
> changes when merged in the future (better to resolve conflicts now,
> when the code is fresh on the mind).
This is my problem with long-lived topic branches as well.
--
mike
The Horde Project (www.horde.org)
mrubinsk at horde.org
More information about the dev
mailing list