openSUSE packagers' take on the 3 month release cycle

[Àlex Fiestas]

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.

> 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?
 
> 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.

> 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.

> 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?