Early Branch.

[Tom Albers]

On Fri, 21 May 2010 01:05:00 +0200, Sebastian Kügler <sebas at kde.org>
wrote:
> Why not create a work branch for the feature development?

That would have been fine if I would have known you had a problem with it.
The exception request for edu was made a month ago, and nobody objected to
it, nobody even replied to it, so I considered it to be ok. In that light I
considered KDEPIM could just jump on the exact same train.
 
> 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. 

It's not that bad as you describe. The branch is created in order to
comply to the freezes we have set. We now have a clear distinction for what
is stable and where features are going. It's not making things '*really*
complicated', they just branch of a bit early, just like we would have done
at release candidate time. 

Maybe we should just consider it as an experiment for the 'always <insert
your favorite season here as long as it is not winter> in trunk' we talked
about years ago. Let's see if it works out for edu and pim and _consider_
this the default for 4.6, and yes that needs discussion in any case.

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

I don't think it will have any negative outcome, although you can only be
sure if the time arrives. In any case in both cases a feature branch would
have been created, there was no way around that. Doing it trunk with the
branch for the stable stuff makes a lot of lives easier. Maybe not for
release managers, but it is for teams working on those. Both teams have
indicated that they will double check everything is kept in sync between
the two code trees regarding bugfixes. For translators it is transparant. 

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

Again, this situation is exactly to facilitate that. The PIM people need
to honor the KDE Schedule and they know it. But you need to consider that
PIM development is largely relying on commercial development, which has
sometimes have a different schedule. We need to find a balance between
that. Forking PIM because the schedule does not match the commercial one is
to be avoided and on the other side delaying the releases because the
commercial agenda does not match is unacceptable too. Balance. With this
important kdepim release coming up, we need another month. But there are so
many pim-developers that the features go hand-in-hand with them. Testing
and creating the mobile apps makes sure they run into all kinds of bugs
they have to fix and which also apply to the desktop applications.

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

Agreed.

Again I think we need to consider it as an experiment and let it go for
now. We can decide to never do it again in the end if it sucks big time. 

Best,
-- 
Tom Albers
KDE Developer