Proposed adjustments to our release cycles

[Myriam Schweingruber]

Hi everyone,

On Sun, Jun 17, 2012 at 3:16 PM, Sebastian Kügler <sebas at kde.org> wrote:
> On Saturday, June 16, 2012 08:18:05 Maksim Orlovich wrote:
>...
>> What continuous integration and automated testing? How many apps have any?
>
> That's the point, we need to improve here. Some of this can be done centrally,
> some will be with the apps developers. In the long run, we need to improve on
> our quality processes, the Testing team has identified that, and it's a high-
> priority item in the release team as well. I hope we can create a culture with
> a sound (and not too ad-hoc) quality process, which allows us to be more
> flexible in our release management.

With my KDE Quality Team hat on:

I think we should first of all solve one big problem here:
http://techbase.kde.org/Projects/Release_Team#Coordinator_List

As long as

kdelibs
kde-baseapps
kate

don't even have a coordinator for releases, how do you expect to do
this for the upcoming frameworks? Without a release coordination this
will never work, as the current problems have shown.

I also am quite skeptical about the tarballs: it was already difficult
to get a 4.9 beta1 and it would never actually have happened without
Albert jumping in because the existing release-team was not available.
Thanks a lot again to Albert for doing that.

Comparing what we do with what the industry does is a bit blue-eyed as
we don't even have the responsible people around when it is needed.

So in my opinion we need first to strengthen the release-team and
reduce the single points of failure ( or bus number if you prefer).
The coordinators should really take responsibility to get their parts
into shape for the release, especially in regard to freezes that
apparently are not respected in several parts of the current KDE SC
"package". This means better project management on all parts.

So please everybody, get your individual projects in shape and take
responsibility for releases and make sure that an actual release can
be done smoothly. Define team leads and release managers with
stand-ins, introduce commits only through reviewboard, get your CI on
Jenkins in shape, so far half of KDE is not even building on the
current build server, for various reasons that might Jenkins or
project related.

Once we have all that in place we should start discussions on how to
handle releases in the future, but with the current state this is all
future thinking.

Regards, Myriam