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

List:       kde-core-devel
Subject:    Re: KDE 1.90 release plan looking towards KDE 2.0
From:       Christopher Molnar <molnarc () nebsllc ! com>
Date:       2000-03-13 23:33:30
[Download RAW message or body]

What's the job of the co-ordinator for the doc freeze? Is it something a
mere almost novice could handle?

On Mon, 13 Mar 2000 pbrown@redhat.com wrote:

> The following has been taken from:
> 
> http://developer.kde.org/development-versions/kde-2.0-release-plan.html
> 
> Please refer there in the future for up-to-the-minute information.
> 
> 
> KDE 2.0 Release Plan
> --------------------
> 
> The following is the outline for our KDE 2.0 release schedule. All dates
> are subject to revision, but we will try out best to stick to them if
> possible.
> 
> Kurt Granroth and Preston Brown are acting as release coordinators for KDE
> 2.0.
> 
> 1.KDELIBS FROZEN 
> 
> Kdelibs must be frozen to the point that they will not become binary
> incompatible again for a long time, at least a year or more. However, we
> do not want to preclude the possibility of making important fixes and
> additions after the release. For this possibility to exist, we must add
> private member pointers to each class, and clean out any cruft that still
> remains. We will try and get a "progress chart" of each class onto the web
> so that we can track our progress.
> 
> 2.DOCUMENTATION COMPLETE 
> 
> All KDE classes included in the libraries must be documented. If a class
> isn't documented, it shouldn't be included in the final release of the
> libraries. This probably isn't an option, so that means that some classes
> will need to have documentation written.
> 
> Applications included in kdebase should have basic documentation included
> that is accurate and up-to-date with any changes that have occurred for
> that application since KDE 1.x.
> 
> Translations should be complete for at least German, French, possibly
> Spanish, and hopefully many others.
> 
> 3.KDEBASE COMPLETE 
> 
> Everything included in kdebase must be complete. When we say complete, we
> don't necessarily mean all functionality is implemented, but if the
> functionality is indicated to be present, it must work. It must not
> segfault. It must not say "not implemented." If there is some chunk of
> code or stub sitting around for future functionality that will not have
> time to get completed, it should be
> commented out or somehow hidden. 
> 
> Users of KDE 2.0 will be expecting things to function perfectly. It is
> better to have no functionality than broken functionality in a final
> release. Broken functionality generates bug reports.
> 
> We will try to coordinate action items and deadlines in a consistent yet
> time-aggressive manner. Here is are the two major points that need to be
> complete before we can release our first beta, KDE 1.90:
> 
> 
> Milestone Name		Completion Date	Percent Complete	Coordinator
> kdelibs frozen		March 30	80%			Kurt Granroth
> documentation complete	April 15	70%			??? (volunteer)
> kdebase frozen		April 21	60%			??? (volunteer)
> translations complete	April 30	?? 			??? (volunteer)
> 
> 
> This timeline is very aggressive, but necessarily so. We need to get KDE
> 2.0 stable and available to develop applications with, as many third party
> developers are starting to depend on Qt and KDE 2.0 functionality. KDE 2.0
> has been in development for over a year at this point. It is time.
> 
>                         Frequently Asked Questions
> 
> This section will contain frequently asked questions and their answers. It
> will be updated as necessary as time goes by.
> 
> 1.Can I make changes to the libraries after they are frozen?
> 
> That depends. The cardinal rule to follow here is that your change must be
> binary compatible. Click here for a description on what that means and
> ways around it.
> 
> In simple terms, though, it means that applications should not have to be
> recompiled after you make your changes.
> 
> 2.What types of changes can I make after the freeze of each component?
> 
> Almost all changes after the freeze should be bug fixes or completion of
> existing features. If you have a really cool feature you want to add,
> please contact the kde-core-devel list first. Bear in mind that unless the
> feature is really "can't-do-without", you will probably have to wait until
> a later release.
> 
> 3.How solid are the dates given? 
> 
> Hopefully fairly solid. We won't release anything that isn't ready so if
> things slip, then the schedule slips. But we really are going to try and
> meet all of those deadlines.
> 
> 4.When will KDE 2.0 be released? 
> 
> Short answer: "When it's done". 
> 
> Longer answer: Right now, we're concentrating on getting the first beta
> out. The release schedule for 2.0 really depends on what shape the beta is
> in. If it needs some serious work still, then we'll likely do a few more
> betas. If it's rock solid, then 2.0 will come out very quickly after.
> 
> Really, the more people that contribute bug reports and especially FIXES,
> the faster 2.0 will be released. 
> 
> Thanks for your attention, now please get back to work.
> 
> ---
>   Preston Brown
>   pbrown@kde.org
> 

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