[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    RELEASE DUDE: Re: Support for animated icons (on mouseover)
From:       Dirk Mueller <mueller () kde ! org>
Date:       2002-01-17 1:00:47
[Download RAW message or body]

On Mit, 16 Jan 2002, Matthias Elter wrote:

> >The main question is: given the current feature freeze, is it ok to commit 
> >this nonetheless ?
> I tend to say "yes" but considering the clear "no" from our release dude 
> to John Firebaughs kicker auto hide tweaks my opinion is either reject 
> all features commits or define clear rules which features may break the 
> freeze.

FAQ, see: 

http://developer.kde.org/development-versions/kde-3.0-release-plan.html

In short: 

- no new features to "core" parts (kdelibs / kdebase) that are not listed
  in the feature plan. 

- for listing them now in the feature plan, it requires reviewal first.

Now I didn't define "reviewal", and it doesn't mean "depends on what the 
release dude says", especially as I don't feel capable of deciding 
myself about some of the questions I get asked (i.e. because I don't know 
that specific code). 

Instead I'd like to suggest the following rules / procedure, which also 
worked well in the past:

- posting of a patch with a short description, and if the are "enough" 
  pro the patch and it was tested, then go ahead. 

- "enough" - depends on the situation. I'd say it is at least _one_ other
  developer that can judge about the patch (and hopefully tested it), 
  and in case of veto's more pro's than con's. The implicit "if nobody
  replies its okay" rule for bugfix-patch-postings does not apply. 

So its in short the "commits require reviewal" rule. Of course this outline 
is open for comments in case you think I've missed here something important.
Don't consider this completely hardcoded and strict - i.e. I would say the 
maintainer's vote counts a bit more than those that are otherwise not 
working on the affected code. This is not a formal procedure - I prefer 
discussing and finding an agreement over any formalism. We should 
have better things to do than bending rules. 

However, as a little reminder I want to append my usual rant about the 
schedule: Remember, we're very late in the release schedule, and for various 
reasons I actually do not want to delay it significantly anymore. So 
whatever you might think of _now_ that urgently _has_ to be in 3.0, please 
think twice about it first. 3.0 is not the end of the world, and IMHO it is  
preferable to ship something stable/bugfree over something that has the 
latest gimmick. 

The _focus_ should be to get the API in a sane state and having things 
_easily_ _extensible_ for possible useful later changes and additions. And 
in case you're feeling bored now that you cannot work on the latest feature 
idea you're dreaming of for the whole last month already, think about taking 
a small look at the bugs database. Especially before you add a 
POST_3_0_BRANCH :-)


Dirk
[prev in list] [next in list] [prev in thread] [next in thread]