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 ba=
se
> > 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 committi=
ng
> 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 diffe=
rent
> branches at the same time.

Hm? You have to react very fast on security exploits. How do you expect t=
his=20
to work? An exploit is found, we commit a fix to the semi-stable HEAD and=
=20
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=
=20
dividing resources. The bugfix branch is used to be able to react fast on=
=20
ciritcal bugs or security holes. And as there hopefully wont be to many o=
f=20
them so it should be easy to apply them to both HEAD and bugfix until we=20
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=20
not render correct are no show stoppers.

> > important to have that branch to be able to fix security problems peo=
ple
> > 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 HE=
AD
> 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=
=20
incremental releases, it wont be really stable, too. But for a release yo=
u=20
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 un=
til
> > we release KDE 2.1. What is your point?
>
> the point is that we agreed on releasing more often and releasing packa=
ges
> separately.

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

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