KDE Frameworks Release Cycle

[Kevin Ottens]

On Tuesday 29 April 2014 15:18:55 Mark Gaiser wrote:
> On Tue, Apr 29, 2014 at 3:09 PM, Kevin Ottens <ervin at kde.org> wrote:
> > Hello,
> > 
> > On Tuesday 29 April 2014 14:33:12 Harald Sitter wrote:
> >> On Sun, Apr 27, 2014 at 3:15 PM, David Faure <faure at kde.org> wrote:
> >> >  * Everything is developed in master, so each release will contain a
> >> >  few
> >> >  new features and bugfixes;
> >> > 
> >> > Of course, going with this type of cycle comes with some price of its 
own:
> >> >  * Features in released modules can only be introduced in a very fine
> >> >  grained way so as to not jeopardize the stability;
> >> 
> >> I suspect that's bad wording, but those two things sound contradicting to
> >> me.
> > 
> > IMO, it makes more sense if you reintroduce some of the context:
> >> > * CI should be always green, breakages should be treated as stop the
> >> > line
> >> > events (all commits following a breakage should only be to try to get
> >> > things back to normal);
> >> > * There should be a strong focus on automated tests and peer review:
> >> > all
> >> > modified code should come with corresponding tests; if you got a
> >> > framework
> >> > which is low on test coverage because of its architecture it's likely
> >> > time
> >> > to focus on the tooling and test harnessing.
> >> 
> >> If everything is developed in master (i.e. features are not developed
> >> in a feature branch and then merged into master) but features mustn't
> >> affect the stability, how do you ensure latter if someone develops a
> >> feature locally (alas, no feature branch on git.kde.org) and then
> >> pushes at any day (since there is no feature freeze)?
> > 
> > Because of the above: thin slices, all peer reviewed, all with automated
> > tests (slightly oversimplifying since we can't have 100% coverage, but
> > that's what we're aiming).
> > 
> > In more words, having those constraints push people toward not making
> > large
> > feature branches be it online (git.kde.org) or locally. Or if they do so
> > nonetheless, each of the commits will have to be reviewed separately
> > anyway
> > and will have to be small (baby steps) and with automated tests.
> > 
> > That means features will enter gradually and not in a big bang fashion as
> > we usually do (via large commits or merge commits). What we're after by
> > doing that, is earlier exposure and testing by the other developers,
> > discussion generated in turn, and each step destabilization risk should
> > be lower.
> > 
> > That's basically more discipline required.
> > 
> > Hope that clarifies.
> > 
> > Regards.
> > --
> > Kévin Ottens, http://ervin.ipsquad.net
> > 
> > KDAB - proud supporter of KDE, http://www.kdab.com
> > 
> > 
> > _______________________________________________
> > release-team mailing list
> > release-team at kde.org
> > https://mail.kde.org/mailman/listinfo/release-team
> 
> I asked a few folks the same question, but i might as well ask it on the
> list. Why don't we simply introduce a "merge window" like the kernel.

Because our community structure has nothing to do with the kernel. A good way 
to see that is that we struggle to get any of our feature branches tested by 
lack of contributors. Unlike ours, kernel feature branches get a lot of 
testing prior to merges.

We just happen to be way smaller in head count while having a similar amount 
of code in the whole community.

> How i see it is as follows:
> 
> 1. The first week (first 7 days) of each month is the merge window.
> 2. Features that are merged should already be heavily tested before it
> makes it's way in.

We've been constantly failing that for years now.

> 3. The rest of the month is stabilizing.

And that too we've been failing at, developers keep playing in their 
development branches instead of stabilizing.

> 4. followed by a release at the end of the month.
> 
> Just wondering... since the kernel approach seems like a really good
> one for short release cycles.

But we're not the kernel, so we're going for something different.

Cheers.
-- 
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/20140429/762a4450/attachment.sig>