"Àlex Fiestas" <afies...@kde.org> wrote: >On Wednesday 10 July 2013 13:22:20 Sune Vuorela wrote: >> On 2013-07-09, Sune Vuorela <nos...@vuorela.dk> wrote: >> > So. first one. >> >> Second one >> >> Release frequency. >> >> We have a giant quality problem. Distros won't ship a .0 release to >real >> users (as opposed to testers/power users) and wait until there has >been >> a couple of bug fix releases. Until we ensure that our .0 releases >are >> usable I don't see how we can cut down on that. >> >> Some distros release in a 6 month cycle. Others in a 8. and ones even >in >> longer cycles. Going for anything shorter than 6 months will ensure >that >> distros are going to skip releases. why work with releases that they >> aren't going to ship to users anyways? >Not by distributions working that way I guess. > >Part of the reasons why I want this release schedule is exactly for >these >distros. Let me explain. > >Right now distributions pick the release they see fit and make a distro >with >it. It might be .0, .2 or .5. > >If a distribution in their right decide to pick a .5 release wile a .0 >is >already out there (this already happened), what is happening here is >that a >HUGE release with a LOT of changes won't even get to the users of that >distribution at least for another distribution cycle. This usually >happens >with distributions that have a release cycle of 9 months. > >With having releases every 3 months we make the amount of features >smaller and >more often so distributions will always be able to pick a more updated >release >than with the current situation. > >> And given there need to be some stabilization and integration work, >I'm >> sure skipping releases would be the default for most distros. >Hopefully >> distros can coordinate and at least skip the same. Mostly leading to >the >> other releases being useless because they only reach very few users. >This is already happening, no change here. > >> And as it currently is, we need the .4 and .5 releases. >and .6 and .7 and .8 and .9, we could have a 4.0.200, there is always >need of >bugfixing releases, question is how many of these point releases are >pending >of upstream KDE and not downstream distros. > >To make it clear, I WANT to have .4 and .5 releases, just not made by >upstream >developers.
Might I suggest the following addition: every year (exact time debatable) we mark a release long term. Distributions are encouraged to release the latest, but those will never get beyond a .3 release. Distributions that want more stability can work together to submit patches to the long term release: every month we will release a new version of any long term release that has a change. I realize this is more work for our packagers, but I hope they can script it to a cron job that just checks for changes and creates tarballs once a month. The purpose of my proposal is to make it easier for our downstreams to work together. If RHEL ships 4.14 in a long term release and Kubunu ships 4.15: odds are a security bug found in one is in the other. However patches between versions may not apply cleanly so it is extrawork for the second distribution to fix: and this assumes they inform each other of the bug. By giving them a common place where they are encouraged to work together they can both provide better quality which makes us look good. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.