openSUSE packagers' take on the 3 month release cycle

Albert Astals Cid aacid at kde.org
Mon Jul 8 20:55:28 BST 2013


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?

Cheers,
  Albert


> Additionally, there are a number of concerns regarding maintainability which
> are openSUSE specific: since the distro has an 8 month release cycle and
> there is support for current version and current version-1, we make
> available newer releases from KDE in specific repositories on the Open
> Build Service, and additionally we submit minor releases from KDE as
> official updates for the distribution.
> 
> The 3-month workflow would not only strain the work within the packaging
> (some of us track the development versions and know how can they become
> moving targets) but also on the whole infrastructure:
> 
> - providing updated packages in the extra repositories will require more
> work - this would also cause an additional strain for supplying updates
> 
> Also, despite the fact that no one is forced to have the latest and
> greatest, there is the issue with user support (as I see in the KDE
> Community Forums, speaking with my forum admin hat on) where issues are
> fixed already but distros don't carry the required updates. So this would
> be detrimental for the distribution(s) anyway.
> 
> Therefore, the only logical conclusion is -1 to this proposal.





More information about the kde-core-devel mailing list