Fwd: KDE Frameworks Release Cycle

[Albert Astals Cid]

El Diumenge, 27 d'abril de 2014, a les 15:15:32, David Faure va escriure:
> FYI.

Interesting fact here that original the mail was just sent to k-f-d and k-c-d.

I am seeing similar patterns in the plasma land, where they went their own way 
with the releasing discussion and only sent to this list after the discussion 
happened (or that's my impression) (Note i'm not complaining of being left 
aside since actually i was there in person for the KF5 dicussion).

I'm just raising the question if we want to:
 a) Try to make the KF5 and plasma people work more in the release-team list 
when discussing about releases
 b) Rename the release-team list to kde-applications-release-team or something 
like that to make it clear it is about "KDE Applications" side of the previous 
three "Applications, Plaform and Workspaces" sides of a release
 c) Disband the relase-team altogether.

I'd like a) to happen but i can see if being hard so i'm open to anything 
people want :)

Cheers,
  Albert

> 
> ----------  Forwarded Message  ----------
> 
> Subject: KDE Frameworks Release Cycle
> Date: Sunday 27 April 2014, 11:51:01
> From: Kevin Ottens <ervin at kde.org>
> To: kde-frameworks-devel at kde.org
> CC: kde-core-devel at kde.org
> 
> Hello people,
> 
> As you may have noticed, we're covering quite a few tasks here during the
> sprint. But, we're also having discussion topics, and the most important one
> we covered is the release cycle. Indeed, we got the question several times
> already of "once 5.0 is out what will happen?" It is what I'll try to
> address in this email.
> 
> Short story: we'll go for a one month release cycle, with no branch.
> 
> You can stop reading here, thank you, bye!
> 
> ...
> 
> Still here? Oh you want more details!? OK, read on. :-)
> 
> So, we had a team discussion here with Albert, Aleix, Alex, Alex, Aurélien,
> David, Rohan and myself. We juggled with several options, trying to address
> the following constraints:
>  * We don't have many contributors;
>  * We don't have enough testing in the stable branches, developers tend to
> have a hard time to dog food those;
>  * We don't have enough contributions coming from the application developers
> because it takes a lot of time for them to benefit from their changes so
> they tend to workaround instead and consider kdelibs more and more as a
> black box; going forward we don't want that for KDE Frameworks.
> 
> We ended up settling on the "one month cycle, no branch" option because we
> think it should address the constraints above. In a more detailed way here
> is what we mean by "one month cycle, no branch":
>  * Everything is developed in master, so each release will contain a few new
> features and bugfixes;
>  * The only freeze will be a message and docbook freeze, it will happen for
> the last two weeks prior to release (so we'll be in message/docbook freeze
> 50% of the time);
>  * Releases will materialize in the form of a tag and a tarball;
>  * We tag the release at the beginning of each month, as close as possible
> to the first day of that month;
>  * Unlike previously, tags will be pushed immediately, we'll first tag a rc1
> and produce the tarballs, if no issue is found by packagers in a week then
> it will be retagged as final, if issues are found we'll tag a rc2, etc.
> 
> Currently David will be the one producing the releases. He'll announce the
> exact dates for the freeze and release of the current cycle during the first
> 10 days of the cycle since that's partly based on his own availability.
> 
> 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;
>  * 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.
> 
> Thanks for your attention.
> 
> Regards.