KDE Frameworks Release Cycle

[Mark Gaiser]

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. 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.
3. The rest of the month is 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.

Regards,
Mark