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

List:       kde-core-devel
Subject:    Re: KDE2 release schedule update
From:       Matthias Elter <me () caldera ! de>
Date:       2000-09-28 8:19:26
[Download RAW message or body]

On Wed, 27 Sep 2000, Dirk Mueller wrote:
> Matthias Elter schrieb am Mittwoch, den 27. September 2000:
> > KDE 2.0.1 is intended to fix the most critical bugs the large user base
> > we will have as soon as it is adopted by the distributors will find.
> > Problematic web pages are not critical. I can work with KDE even if
> > kthtml can't render ww.foobar.com. I can't work with KDE if say kwin
> > crashes every 2 hours on certain systems.
>
> And whats wrong with committing these to the head branch?
>
> > The KDE_2_0 branch wont live longer than a few weeks.
>
> Then we can live very well by reviewing feature patches before committing
> them. this way we can add new features and be sure to stay relatively
> stable.
>
> I don't think its a good idea to open a bugfix branch because its just too
> likely that a change to the bugfix branch isn't correctly transfered to the
> HEAD branch or vice versa. CVS isn't really suited for working on different
> branches at the same time.

Hm? You have to react very fast on security exploits. How do you expect this 
to work? An exploit is found, we commit a fix to the semi-stable HEAD and 
freeze HEAD for two weeks to be able to release a semi stable version?

As I said, this is not about branching developement and this is not about 
dividing resources. The bugfix branch is used to be able to react fast on 
ciritcal bugs or security holes. And as there hopefully wont be to many of 
them so it should be easy to apply them to both HEAD and bugfix until we 
release 2.1.

> > it's only purpose is to release a version of KDE 2.0 that fixes "show
> > stoppers" we find after the "show" (and we _will_ find some) fast.
>
> well, there might be a lot of "show stoppers" that are simple to fix
> anywhere.

Define the word "show stopper" please. As I said, bugs like www.blub.com does 
not render correct are no show stoppers.

> > important to have that branch to be able to fix security problems people
> > find in KDE 2.0 fast. Those of us who are paid to work on KDE by a
> > company who is interested to have a 2.0.1 release soon after 2.0 (and I
> > bet all distributors are) _will_ have to commit  fixes to the KDE_2_0
> > branch.
>
> I don't see the problem. those fixes can as well be committed to the HEAD
> branch, because HEAD isn't supposed to get unstable any more! We've had
> this too often the last few years.

Yes, but while we don't want HEAD to become really unstable as we aim for 
incremental releases, it wont be really stable, too. But for a release you 
have to make sure it _is_ stable and this involves a few weeks of freeze.

> > Hm? Distributors will ship KDE 2.0.1, the fixed version of KDE 2.0 until
> > we release KDE 2.1. What is your point?
>
> the point is that we agreed on releasing more often and releasing packages
> separately.

Thats why we should branch. We can't release 2.0.X releases fast enough when 
we try to release them from HEAD. If we hard freeze HEAD to make 2.0.X 
releases happen, this will slow down 2.1 developement. And yes, speaking of a 
2.1 relase I'm talking about kdelibs and kdebase. Seperate kdenetwork 
releases for example are of course what we aim for, too.

-- 
    _____     ___
   /  __/____/  /                Caldera (Deutschland) GmbH
  /  /_/ __  / /__           Naegelsbachstr. 49c, 91052 Erlangen
 /_____//_/ /____/          Matthias Elter,  email: me@caldera.de
==== /_____/ ======   phone: ++49 9131 7192 300, fax: ++49 9131 7192 399
 Caldera OpenLinux                  http://www.caldera.de

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