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

List:       kde-devel
Subject:    Re: 2.2 RELEASE SCHEDULE (proposal) [NOTE: 2.2 != 2.1.1]
From:       Vadim Plessky <lucy-ples () mtu-net ! ru>
Date:       2001-03-03 12:51:40
[Download RAW message or body]

On Saturday 03 March 2001  8:48, Dawit Alemayehu wrote:
|   On Saturday 03 March 2001 01:29, Waldo Bastian wrote:
|   > http://developer.kde.org/development-versions/kde-2.2-release-plan.html
|   >
|   > KDE 2.2 Release Plan
|   > ================
|
|   Most of the the time I abstain from forcefully commenting on release
| schedules.  Well, actually I did one time and that was the original release
| for 2.0 which I objected to.  Anyways, IMHO this release schedule is a bit
| too aggressive for its own good.  I was planning on a re-design of the http
| io-slave so that we can easily add support for webdav and I am sure some
| people have similar things to do.  However, this is a minor issue for me
| compared to bombarding people with one release after another.  Shouldn't we
| at least give the users a month or two to digest the stable release at the
| time (2.1.1) before throwing yet another beta release on them ?  I know our

I vote for one-Beta-per-Month here, so KDE 2.2 Beta at the end of March is 
ok, IMHO.

Of course, I do no think that *every* package should be updated.
There was discussion/opinion to release JavaScript/KHTML upgrades more often 
than once in 3(4) months.
For some reason, that haven't happen.

By the way, to release KJS/KHTML packages often, we need to *separate* 
kdelibs in dseveral packages. Then upgrading will be more smooth and  
seamless.

kdebase should be splitted also. If you are happy with Control Panel and 
unhappy with Konqueror, *why* should you download Control Panle (as part of 
one, *monolitic* kdebase) once more?

Such split will exactly needs of people with slow connections, like me.
Otherwise, you can spend one hour downloading 10MB kdebase RPm 9ohh, now it 
is already 13MB!! ), just to find that something in broken in it. (like, 
userAgent selection is not working in 2.1 release)

One more argument for regular, once per month, Betas.
When Beta is announced, packagers (hopefully) make some effort to do 
packaging. Developers do final bugfixing to make it compiling.  
If you download CVS, there is no warranty that it will compile.

There was also request on kfm-devel for separate (without kde-something) 
Konqueror. Some people just want Konqueror, they do not want / can't afford 
to have all KDE packages installed.  
// tip: these are not only Ice WM or other-WM users, but web designers who 
want / need Konqueror for testing.

Such split will satisfy needs of these users as well.
 
| release were a bit too lengthy before, but I feel that we are doing a 180
| and going in the opposite direction now. People, specially those that use
| slow connection to download this stuff, might feel overwhelmed and simply
| ignore our beta releases.  This is a lose of potential bug reporters to us.

Well, from what I see on kde-user and kde-general, people do not download 
Betas (or even final release) because ... there are no RPMs available.
making Betas available more often, you increase RPM's *availablity*

Even on slow connection, you can download KDE rpms in about 5 hours.
It's some time, but you can do it at night.

|  As much as most of us hate some of the meaningless bug reports we receive,
| I do not think we want this, do we ?  As far as I am concerned a flurry of
| releases are just as bad as far apart ones.
|
|   I apologize if this sounds like a flame to people , but I am really
| concerned about the shrunken time frame here.  As such I respectfully
| disagree with this time frame.
|
|   Regards,
|   Dawit A.
|

-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
http://kde2.newmail.ru/index_rus.html  (Russian)
Do you have Arial font installed? Just test it!
http://kde2.newmail.ru/font_test_arial.html
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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