Releases in 3 months

[henry miller]

"Àlex Fiestas" <afiestas at kde.org> wrote:
>On Wednesday 10 July 2013 13:22:20 Sune Vuorela wrote:
>> On 2013-07-09, Sune Vuorela <nospam at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130711/bf1aa523/attachment.htm>