openSUSE packagers' take on the 3 month release cycle

[Scott Kitterman]

On Tuesday, July 09, 2013 12:11:48 PM Àlex Fiestas wrote:
> On Monday 08 July 2013 20:16:16 Scott Kitterman wrote:
> > For Kubuntu (also mostly volunteer effort), it took about two weeks to
> > package the 4.11 beta.  For generating package updates for already
> > existing
> > packages, we have a script that will produce initial packages.
> 
> This is quite fast, should be compatible with 3 month release apparently.

It's about 4% of a 6 month cycle and 8% of a 3 month cycle, so the time does 
become more significant on the shorter cycle. 

> > These all have to be test compiled, checked for new or missing files,
> > checked for files that have moved between packages, checked for
> > license/copyright updates, etc.
> 
> I guess you have all this mostly automagically done?

Some yes, some no.  The copyright/licensing stuff is the hardest and it's very 
manual.  It's work that has to be done to ensure we are legally distributing 
the packages, so there's no way around it.

> > In the case of new packages (which the newly split modules are), packaging
> > needs to be developed.  For a split module, the information can largely be
> > derived from the old mega-module, but it's done by hand, it's not
> > automated. Also, all new packages undergo an extra layer of review before
> > they are accepted into the archive that takes more time.
> 
> Maybe I'm wrong, but until plasma-workspace2 I don't see any more splitting
> happening, all modules are now in git, have been split, and in anyway
> "spliting" is something we do exceptionally, we can add rules for that.

Some of the recent releases were more work than we'll probably see in the near 
future, I wasn't trying to predict workload, but describe what's my recent 
experience has been.

> > For 4.11, the new packages took most of the time, but checking all the
> > existing ones still took substantial time due to changes.  Beta 2 took
> > substantially less time, but there are still changes that need to be
> > checked. Assuming no changes that impact the packaging, the RC's, final,
> > and point releases will be mostly running a script and sanity checking the
> > results.
> > 
> > For us, each new major release is a significant effort.  For the added
> > releases (at the halfway mark from where releases would be expected with
> > the current cycle) the .0 release will land just about at the same time as
> > feature freeze for the distro release.  This means not a lot of time to
> > get
> > a fair amount of work done.
> 
> Have you taken into account that releases will be smaller? the amount of
> changes in every release can be expected to be smaller, less breakage, less
> "splitin" less everything.

That's a theory.  I expect it will be someone less churn, but every module has 
to be checked to some degree, so even if it's half the develop changes 
landing, it's not half the work for us.

> > My assessment is that we could live with the three month release cycle
> > from
> > a development perspective.  The biggest thing we'd lose having fewer point
> > releases for post-release updates (we ship all the point releases to our
> > end users and appreciate the added stability they provide).  If we could
> > figure out a good plan to deal with better post-release testing/support,
> > then I think the proposal would be manageable for us (my opinion only, not
> > a collective Kubuntu position).
> 
> Awesome! this is the kind of feedback I want :)
> 
> If we could make all developers make better use of commit tags, I think this
> could help. Once we get use to that we could develop scripts or websdites
> showing all fixes, maybe even with categories, kinda:
> 
> FIX: IMPORTANT
> FIX: MINOR
> FIX: ....
> 
> Also, in the case of BUG: we could extract from bugzilla some information,
> so you can decide whether backport it or not.
> 
> What do you think?

I want the point releases.  The reasons for wanting them are for consistency, 
marketing, and for distro policy releases its' much easier to get a set of 
packages that are part of a release through the post distro release QA process 
than a set of indiviual changes.  Also, as a pratical matter, we manage to find 
the volunteer motivation to package a point release, but only rarely for 
individual changes.  I don't think it would help much.

A related point is KDE support policy.  AIUI, currently KDE will provide 
security support for the previous two releases.  After that, distros are on 
their own.  Did you envision that changing to four with this proposal?  If 
not, you're cutting my upstream security support in half.

I would like to figure out something about a better way to test point releases 
and be able to do them more reliably/longer.  I'll think about it.  I do think 
this has to be addressed in some manner before going to your proposed 
schedule.

Scott K