[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: KDE Frameworks Release Cycle
From:       Kevin Ottens <ervin () kde ! org>
Date:       2014-04-29 13:09:28
Message-ID: 2817690.ASKfaiHe4d () wintermute
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hello,

On Tuesday 29 April 2014 14:33:12 Harald Sitter wrote:
> On Sun, Apr 27, 2014 at 3:15 PM, David Faure <faure@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


["signature.asc" (application/pgp-signature)]

_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


[prev in list] [next in list] [prev in thread] [next in thread]