KDE Frameworks Release Cycle

[Harald Sitter]

On Tue, Apr 29, 2014 at 2:50 PM, Aleix Pol <aleixpol at kde.org> wrote:
> On Tue, Apr 29, 2014 at 2:33 PM, Harald Sitter <apachelogger at ubuntu.com>
> wrote:
>>
>> ahoy, quick question that just when we discussed this in kubuntu:
>>
>> 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.
>>
>> 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)?
>>
>> HS
>> _______________________________________________
>> release-team mailing list
>> release-team at kde.org
>> https://mail.kde.org/mailman/listinfo/release-team
>
>
> By being stubborn in different ways:
> - Ensure merged features are unit tested.
> - Don't let things get merged if they make other tests to fail.
>
> The idea is that when it's merged, it should already be stable.

How do you enforce that though if you don't have branches? Everything
needs to go through RRs? Doesn't that actually increase the amount of
time the limited contributors have to spend on everything (what with
RRs generally being more paper work)?

Mind you, automation for RR QA, such as automated CI runs with the
proposed changeset and auto-merge attempts would probably reduce the
work a bit but still there's more paper work involved for everyone I
feel.

HS