KDE SC 4.11 Release Schedule

Martin Gräßlin mgraesslin at kde.org
Sat Jan 19 18:21:27 UTC 2013


On Saturday 19 January 2013 18:25:20 Albert Astals Cid wrote:
> El Divendres, 18 de gener de 2013, a les 19:37:52, Martin Gräßlin va 
escriure:
> > On Tuesday 15 January 2013 23:27:53 Albert Astals Cid wrote:
> > > El Dimarts, 15 de gener de 2013, a les 16:30:50, Allen Winter va 
escriure:
> > > > Howdy,
> > > > 
> > > > A proposed KDE SC 4.11 Release schedule is now available at
> > > > http://techbase.kde.org/Schedules/KDE4/4.11_Release_Schedule
> > > > 
> > > > (created using toma's really useful releaseschedule program)
> > > > 
> > > > Please review and report back any obvious problems, for example
> > > > conflicts with conferences (i.e. Akademy).
> > > 
> > > I'd like to propose some changes for 4.11, i'd like everyone to comment
> > > 
> > > 1) Drop Betas to 1
> > > 
> > > 	It doesn't seem "to me" that having extra betas gives us much more
> > > 	quality,
> > > 
> > > so my suggestion is to drop Beta 2 and move Beta 1 to happen in Beta 2
> > > time
> > > (moving also Hard Freeze) which gives us 2 more weeks for feature
> > > development
> > > 
> > > 2) Drop RCs to 1
> > > 
> > > 	Same thing, it did not feel to me as that it gave us much, drop RC2 and
> > > 	RC1
> > > 
> > > one week into the future
> > 
> > I don't think that the number of Betas and RCs are too much and I think
> > that more Betas and more RCs help improving the quality. Reducing the
> > number of Betas and RCs means removing the chance to properly test stuff.
> > In KWin we had more than once that we pushed a patch to a beta to see if
> > it fixes a problem with the option to still revert it in the next beta.
> > We need to do that in case of driver related issues which the devs cannot
> > reproduce due to lack of hardware. If there are no betas which would
> > allow us to do such "experiments" we would not do it as the risk is too
> > high, but that also means that a large user group would lack an important
> > improvement. We never push such changes in the minor releases as they are
> > not tested at all prior to the release.
> 
> I see your point, wouldn't the "less Beta/RC but more weekly 'unofficial'
> releases" suggestion help you even more?
That depends on whether distributions will package it, release it and users 
will upgrade to it. From what I see users seem to think that if it has an "RC" 
flag, it's stable enough to be testable. So I am not sure whether they would 
pick an "unofficial" release.
> 
> > I think that the 4.11 cycle was not optimal, but I think it is because it
> > overlapps with Christmas and New Year.
> 
> Why was that suboptimal? We've been having that since all the 4.x.odd
> releases
I have the feeling that we are drifting more and more into February and to be 
honest I have never considered the betas/RCs around Christmas to be a good 
idea. It's bad for all those devs doing paid KDE development, it's bad for 
students (at least in Germany it overlapps with exam time, also in the US the 
term ends before Christmas). I will try to play with bugzilla to see whether 
there is a difference in number bugs reported in beta phase .odd vs .even.

--
Martin Gräßlin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20130119/56da9e2d/attachment.sig>


More information about the release-team mailing list