Early Branch.

[Sebastian Kügler]

Hey,

On Friday 21 May 2010 10:07:06 Tom Albers wrote:
> 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.

OK, fair enough. I've missed it and people prepared for it, so it's OK from my POV. 
(I don't think it's ideal, but a deal's a deal.) I'd have suggested to postpone the 
freeze for the edu module until after the Edu meeting in Switzerland, just like we 
did for the Akonadi meeting (and a couple of others that were on the virge of the 
freeze ("thawing point"?) in the past.

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

This clear distinction is OK for those that actively develop on PIM, since the time 
compared to learn where stable is is relatively low, compared to the development 
effort put into it. The PIM developers aren't the only people that need to know this, 
and the simple equation is that if we do stabilization in a branch, less people will 
test it since it's a special case.

KDE's codebase and development process is complex enough as it is, if we now 
introduce per-module-policies, we're alienating those that don't have lots of time to 
find out about policies on their hand, and that weakens our community and increases 
the threshold for new contributors.

> 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 think such an experiment is fine (though pretty useless at the moment with concrete 
plans to move to Git), but it's enough if we do it with one module. I think KDE PIM 
is too critical (overall, and in its current phase) to conduct experiments like this, 
and we've granted this exemption to the Edu people already.

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

That increased effort goes for release managers, and more importantly for testers. 
Now it's not like I have too much time on my hands, but testing is never enough.

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

I see that quite differently, every citizen in the community has to adhere to this 
schedule, commercial contributor or not. At the time we make the schedule, we can 
talk about how we create one consistent schedule that works for everyone, that's the 
whole point of discussing the schedule and doing it based on common agreement here. 
Making a difference between paid and voluntary contributors is not how KDE works, 
though.

I'm concerned that we're weakening the development rhythm we need in KDE, and that 
we're creating exceptions too easily. Maybe we can rethink the whole situation once 
we moved to Git and have collected some experience there. Trying this kind of stuff 
right now is just a waste of time (if you count the experimental value).

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

The whole of trunk needs to be tested. Realistically, banning stabilization efforts 
into a work-branch will significantly reduce testing (look at how well our stable 
branches in SVN are tested and you see what I'm talking about).

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

I still disagree. For the sake of the experiment, we have the Edu module. That's good 
enough to find out. Besides, I find this experiment of very limited value to future 
decisions about the development process, since that's likely to change somewhat, or 
maybe even significantly with the Git migration (which also happens to make branching 
a lot less painful).

So, still a clear objection from my side. Sorry.
-- 
sebas

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