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

List:       kde-core-devel
Subject:    Re: KDE2 release schedule update
From:       Dirk Mueller <mueller () kde ! org>
Date:       2000-09-27 16:53:47
[Download RAW message or body]

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. 

> 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. 

> 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.

> 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.  


Dirk

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