Change release schedule 4.2 and schedule for 4.3

[Tom Albers]

At Tuesday 09 September 2008 21:52, you wrote:
> 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.

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?

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