Fwd: KDE Frameworks Release Cycle

[Kevin Ottens]

Hello,

On Tuesday 20 May 2014 16:38:54 Aaron J. Seigo wrote:
> keeping in mind that this thread is not about Plasma or any of the KDE
> applications, the expectations and goals of the *Frameworks* developers
> _and_ users (app devs) are probably unique in this case.
> 
> the Frameworks team would probably do everyone a favor by clearly stating
> their goals in terms of stability expectations and rate of change so we know
> how to weight the different outcomes that happen.

The aim is the following in my books:
 * no regression on existing and already released features ever;
 * every new code got reviewed and is coming with automated tests;
 * at most between two and five new API addition per release per framework 
(variation obviously because adding classes isn't the same than adding 
methods).

Obviously the difficult point as certainty goes is the last one, as it is 
highly dependent on the amount of contributions which mainly come from 
volunteers and on the amount of time available from reviewers.

> On Tuesday, May 20, 2014 09:45:36 Scott Kitterman wrote:
> >  - Developers backport "safe" fixes to the stable branch.
> 
> this is a critical issue. not enough developers who backport are able to
> accurately judge this consistently enough. many reasons exist for this
> (tooling, testing, experience, blah blah) but reasons are just reasons -> if
> we rely on developers to backport safe fixes, it's going to break (because
> it does already) and that will defeat one aspect of what Kevin is trying to
> achieve: higher quality
> 
> there are ways around this, however! it is not uncommon in other projects
> for people to "own" a long term branch and only they merge in patches.
> period. that person needs to be disciplined (so they don't just become a
> rubber-stamp bureaucrat), but this is one area where having a bottleneck is
> actually good: you don't WANT lots of changes. you WANT a slow rate of
> change. you WANT every change to be justified.
> 
> for it to work that person(s) needs to be able to say "no". they also need
> to be allowed to say "no". if they won't say "no" when necessary, there is
> no point in having them there. if developers submitting patches rebel
> whenever they do say "no", then there is no point in having them there.
> 
> that implies the need for an explicitly defined position and probably have
> an initial public "show of hands" vote of support by the existing
> contributors to Frameworks to grant the position legitimacy.
> 
> i honestly don't see having a long term branch working otherwise. and
> perhaps that's were some of the tension arises: one party is asking for
> something that doesn't work but which they feel a need for, and the other
> party doesn't want to do something that doesn't work ;)

I think you nail it down perfectly. This type of branch got actually discussed 
before making the initial proposal, it's not that we don't like the idea at 
all, it's that we don't feel confident to make it work at that point in time. 
Again that's a question of not lying, I prefer not offer something than offer 
something which gives a wrong feeling of quality/safety.

So that's basically why right now we're thinking going without it. It doesn't 
exclude reevaluating later, probably once we rolled several releases over a 
longer period and know more.

At that point we'll be able to figure out if what we deliver can reach a 
quality level high enough that the cost of a stable branch is not worth the 
value it'd add, or if we should pay the stable branch cost because this extra 
stability is worth it.
 
Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20140521/4097b9b7/attachment-0001.sig>