KDE Frameworks Release Cycle

[Harald Sitter]

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.

Ah that makes more sense. Thanks for clarifying :)

HS