openSUSE packagers' take on the 3 month release cycle

Scott Kitterman kde at kitterman.com
Tue Jul 9 01:16:16 BST 2013


On Monday, July 08, 2013 09:55:28 PM Albert Astals Cid wrote:
> El Dilluns, 8 de juliol de 2013, a les 20:35:22, Luca Beltrame va escriure:
> > (apologies for breaking your threading, but I'm not subscribed to k-c-d;
> > in
> > fact, please CC me with replies, thanks!)
> > 
> > Currently, the people working on openSUSE packages are against the
> > proposal. A detailed explanation follows.
> > 
> > First and foremost, the KDE packaging in openSUSE is almost completely
> > community driven. This means that most of the work is done by volounteers
> > which handle what they can in their (limited) time. Faster releases may
> > mean worse packaging and increased maintenance (and I think this is also
> > an issue w/most non rolling distros).
> 
> From total ignorace, how much time do you need to change a 4.12 to a 4.13 in
> a spec file? What is consuming your time doing a packaging of a new
> release?

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.  

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.

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.

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.

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

Scott K




More information about the kde-core-devel mailing list