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