Change release schedule 4.2 and schedule for 4.3

[Chani]

On Tue, Sep 9, 2008 at 11:54 AM, Boudewijn Rempt <boud at valdyas.org> wrote:
> On Tue, 9 Sep 2008, Thiago Macieira wrote:
>
>> On Terça 09 Setembro 2008 15:23:43 Torsten Rahn wrote:
>> > The proposed always-summer-in-trunk model rather is an "opt-in" model which
>> > allows the group to become much more loosely bound "together". "Opting in"
>> > would require to take action and make a decision (which people try to avoid
>> > if possible)
>>
>> The current model is already an opt-in one.
>>
>> If someone doesn't want to participate in the stabilisation phase, all he has
>> to do is stop committing.
>
> Sure: but your reasoning is pretty specious. If one stops committing at all, or only
> work in a branch for three months, it feels bad. As if you've placed yourself outside
> the community. Which, in fact, you have.
>
> If, on the other hand, you keep coding cool stuff and, while never really making it
> available to users, still making it somewhat available, you can blog about it and feel
> good and a front-runner who's taking KDE places. While you're still relying on others
> to do the dirty work of bringing your stuff up to scratch and making it releasable.
>
> Right now, having the boring work, i.e., making it into a release, depends on you also
> participating in the stabilistation phase, trunk-is-always open rewards the opposite:
> have fun. do cool stuff, never care about integration or stabilisation, just blog and be
> famous.

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.

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