Change release schedule 4.2 and schedule for 4.3

[Chani]

>>
>> I see it the opposite way around.
>> right now, as kde approaches a feature freeze, everyone rushes to get
>> their pet features in. we get a big dump of barely-working-ish code,
>> everything's a big mess for anyone using kde svn, and we all have to
>> pick through this ugliness and try to get it cleaned up before release
>> time. if someone goes on holidays or loses their laptop or otherwise
>> is unavailable during this time, someone else has to clean up their
>> mess or the bugs end up in a release. (several evil plasma zui bugs
>> got into 4.1.0 because I was busy with SoC and forgot about the
>> release schedule.)
>>
>> if it was "always summer in trunk", features would not be allowed in
>> until they're already reasonably stable. people could develop in a
>> branch (requiring a VCS that does cheap branches, ideally local
>> branches because nobody wants to see my "this is a mess, let's try
>> again next week" commits) and stabilise as they go, not having to
>> worry about a feature-freeze deadline. of course bugs would sneak into
>> trunk, but the big obvious ones would be fixed before that instead of
>> being put off because it's feature-time. people who aren't developing
>> plasma wouldn't see big breakages, they'd just see the sneakier bugs
>> that crept up to the branch they're on (summer or autumn or whatever),
>> and then they can either fix those or nag us about them.
>>
>> I really want to be able to work on bugs or features based on my own
>> schedule, not based on freezes. when we're not in freezes I'm too busy
>> trying to cram in features, so I don't fix bugs I want to fix, and
>> when we're in a freeze then I can't work on a feature without the
>> hassle of setting up a branch or git-svn (which is horribly fragile),
>> even if I've hit a wall with bugs. and then there's the stuff in my
>> schedule that conflicts with kde's schedule entirely, and I might end
>> up doing nothing at all and missing a window because I had homework or
>> something - but I can't just do it later because later it won't work
>> with kde's schedule.
>> it's just silly. the current dev. model really doesn't suit the way I work.
>>
>> I do agree that we should be very careful to ensure people are still
>> encouraged to fix bugs, and keep an eye on the stability of the
>> project, but I believe this change would result in *less* bugs in
>> releases, not more.
>
> I read your complete mail, but I don't see any reasoning for the fact that it would result in less bugs in releases. Can you explain that more?

this spring, I was working on ZUI and keyboard stuff for plasma. I was
perfectly aware of many bugs, and would have liked to solve them then,
but feature freeze was approaching so I just wrote lots of notes to
myself and kept working on features.
in summer, freeze time came, but I got too busy with SoC and didn't
have time to fix bugs. have a look at the ZUI in 4.1.0 to see what the
result was. :(

if we had an "always summer" policy, I would have wanted to, and
ideally would have been required to fix those obvious bugs *before*
merging in features. perhaps one or two of the features wouldn't have
made it for 4.1, but the ones that did get in would've been a lot
stabler.

now that I've lost my laptop I can't even remember what the remaining
ZUI bugs are :(

>
> How come you think that when there is always summer, you assume you have fixed more bugs in your code vs having a somehow forced stabilisation period for that?
>
> Toma

I'm suggesting that the forced stabilisation come *before* the feature
goes in, not after.  there's no guarantee that I'm going to be around
for both the feature period and the stabilisation period when I'm
forced onto the same schedule as all the other kde contributors.

also, since non-plasma kde devs would most likely be using a stabler
branch of plasma (ie trunk or something between unstable and trunk),
they would be seeing something closer to what the users see, and would
be more likely to catch sneaky bugs for us.

right now, a feature starts on someone's hard drive, gets into trunk
when it compiles, might get fixed up a little during feature
development, then probably has some bugs worked out during the freeze
(assuming someone remembers to look at it), then ends up in some
stable branch that not too many people use.

what I'd like to see is that a feature starts in a "spring" branch
(I'm stealing aaron's terms here), being horribly unstable. when it's
cleaned up and polished and appears to be mostly stable, it goes into
"summer", where more developers are exposed to it and will uncover
non-obvious bugs (and with cheap branching it'd be easier for me to
jump over to summer or autumn to look at the problem with them). after
a while it makes its way up to "autumn", and by then it should
actually be stable, but people further from the sub-project it belongs
to will get to use and test it now. by the time it reaches "winter" it
should be very stable and ready for release :) no need to force
everyone all into freeze mode at the same time. we can still organize
bug-hunting parties before release times, but people are free to fix
bugs at other times too without worrying about their features missing
the big freeze.

-- 
This message brought to you by evyl bananas and the number 3.
www.chani3.com