Early Branch.

Sebastian Kügler sebas at kde.org
Fri May 21 01:05:00 CEST 2010


On Thu May 20 2010 19:11:38 Tom Albers wrote:
> The KDEPIM whishes to branch early, as there are lots of development in
> KDEPIM, a feature branch is needed. To keep the workflow a bit sane, I
> suggested that next to KDE-EDU, aslo KDEPIM branches of. All KDEPIM
> releases will come from that 4.5 branch. Feature development can then
> continue in trunk.

Why not create a work branch for the feature development?

I'm actually not too happy with individual modules branching off for bugfixing 
and using trunk for feature development. We have a freeze for a reason (common 
rythm of development, reaching acceptable level of quality), and if we need to 
explain SVN users which trunk branches are frozen, which ones are open for 
features, and which ones should get the bugfixes, we're making things *really* 
complicated, as policies are KDE SC-wide, not only apply to a subset of the 
modules within it. I get it that feature development in trunk is easier, but 
the main focus is getting our current trunk release ready. That holds true for 
other modules as well, and it requires a bit of discipline from all or us. 
Opening up parts of trunk for feature development just sends out the wrong 
message, and I fear it might have negative effect on the quality of the 
upcoming release. We're in release mode now, and it's not like that should 
come as a surprise to anyone.
I'm not convinced we should open up trunk for development on features we're 
not even planning to release inside KDE SC now (i.e. akonadi / kmail mobile).

Also, asking for delaying the PIM release because there's not enough time to 
get it to an acceptable level of quality in time for 4.5.0, and at the same 
time requesting opening trunk for new features is a bit odd. I do know the 
business background here, but I would highly appreciate if KDE schedules were 
taken into account as well.

I get it that lots of stuff is happening in PIM, and I'm really happy about  
that, but we need to keep things sane for others as well, and maintain a 
leveled community.

> Any objections to this request? If not, Dirk, can you set that up?

I'd like to find a better solution for the above problems.


http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9

More information about the release-team mailing list