KDE Frameworks Release Cycle
ervin at kde.org
Tue Apr 29 13:09:28 UTC 2014
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
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
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.
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud supporter of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the release-team