Releases in 3 months

[Scott Kitterman]

On Wednesday, July 10, 2013 06:54:06 PM Àlex Fiestas wrote:
> On Wednesday 10 July 2013 18:26:55 you wrote:
> > On Wednesday 10 of July 2013 18:08:04 Àlex Fiestas 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.
> > 
> > The Linux kernel itself maintain old branches with big number of point
> > releases. See 3.0.85, 3.2.48, 3.4.52, done by kernel developers.
> 
> Done by the kernel developers interested on those.
> 
> My proposal is to make the parties interested on this, actually do this.
> 
> > > [...]
> > > 
> > > > 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.
> > 
> > Uhm... are you sure this will work? It can work for paid contributors, but
> > not for unpaid ones. Moreover, this means that it's fine if users don't
> > receive
> 
> > the last version, which was one of your goals stated above:
> I can't fight with distros, and I don't want to fight with them. If distros
> need .5 .6 and .200 so be it, just they will have to do them themselves (and
> I hope we can make the process smooth so they can actually do it).
> 
> As has been said in this thread, almost no KDE developer is using the stable
> branch, blindly backporting has shown to be dangerous and has created many
> issues in the past so we are not the right people to make these point
> releases.

I think distros can help with getting more testing and even provide good 
feedback on if a point release is baked.  I don't think we should be looking 
in git and deciding what should be backported or not.  I think the developers 
of the code should do that.

Scott K