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

List:       kde-core-devel
Subject:    Re: KDE 2.0.1 and 2.1 Release Schedule
From:       Marko Samastur <markos () elite ! org>
Date:       2000-11-23 2:18:38
[Download RAW message or body]

Hi,

Sorry for a quite long post (if it actually makes it to kde-core-devel).

On ?etrtek 23. november 2000 02:55, Torsten Rahn wrote:
> >   I don't think that any application which was in KDE 2.0 is in
> > worse shape in the CVS than it was before, so I really think we
> > need to put all of them in the beta. KWord which has a branch is a
> > special case.
>
> I don't think so. Imagine people who only have a bad modem-connection
> and discover that basically only 50% of all apps they have downloaded
> have noticably changed since 2.0.1. I would feel like being played
> for a sucker!
> So please include only those modules which have suffered noticable
> changes.

I agree with Torsten. There's plenty of us living in a world of 
expensive slow connections. Some of us still download KDE, but it's 
getting more difficult with increasing size, others just wait for 
distributions to include it.

While bandwidth and prices will improve in time, the managing side 
won't. There are more and more KDE programs out there and IMHO opinion 
it will get increasingly difficult to decide which should be part of 
default desktop and which shouldn't. More of them included, more effort 
will be needed to make a release and I think the last release showed 
the limits of this approach.

I believe that the best way would be to reduce what is considered KDE 
release. It should be only kdelibs and kdebase with few small, but 
often used programs like a text editor or viewer of popular graphics 
formats (+ konqueror). Everything else should be treated like an 
additional packages.

Other packages would be released when KDE developers thought that there 
was enough progress made for a release. To avoid waiting between 
different projects, programs would be chosen between then stable 
releases. When there would be a general feeling, that new package could 
be released, developers would set a date in not too distant future, 
when consideration on which programs to include would be made. This way 
all would have opportunity to polish their program, if they feel that 
new stable release of it is not too far off. Since in case of programs 
that are in the middle of a heavy development, older, but stable 
version would be used, this would leave developers total freedom in 
setting their own pace.

Different approach would be to still reduce number of KDE desktop 
packages to kdelibs and kdebase, other packages would be broken apart 
and programs would be released when they get new stable version.  
However, I don't think this approach would really work, because it 
would be nearly impossible to make packages for major distributions on 
ongoing basis. Without them, current versions would be used only by a 
smaller group of KDE users (IMHO this is a problem already). It could 
be also problematic because some distributors update only to major 
releases.

Apart from other possible shortcomings, both scenarios would have a 
really awful way of handling those releases, that significantly change 
the infrastructure (like move from 1.1.x to 2.0), because they would 
give a desktop with doubtful support of other programs. That this can 
be a problem, showed the last release, where some of us lost quite a 
lot of programs because KDE packages for Red Hat 6.2 didn't make it 
possible to have both KDE 1.1.2 and KDE 2.0 installed. I think it's 
important to acknowledge, that in time like this there will be a 
significant time when people will use programs created for older and 
newer version of desktop,  and reacting accordingly. But this is off 
topic to the main theme of this post, so I'll stop here.

Kind regards,

	Marko

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