[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:       Ferdinand Gassauer <f.gassauer () aon ! at>
Date:       2001-03-04 10:07:50
[Download RAW message or body]

On Saturday,  3. March 2001 14:15, David Faure wrote:
> On Saturday 03 March 2001 15:31, Vadim Plessky wrote:
> > 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.
>
> [....]
>
> Ok, let's go for this argument again.....
>
> It has always been up to the packagers to split the packages if
> they want to. We just can NOT take care of 60 tarballs when releasing KDE
>  - and confuse people with "what the hell should I download amonst all
> this".
>
> By releasing the "big" packages as is, we give people choice
> (between downloading the monolithic tarball and downloading more
> fine-grained RPMs or other binary packages). If we released one tarball
> per application, there would be no choice.
>
> Especially with the interface given by http://ftp.kde.org (where one needs
> to drag and drop every file he wants to download), it's a good thing we
> don't have 60 tarballs :)

But with ftp and konqueror it's only 4 clicks away ;-)

IMHO we have 3 groups to deal with

- end users: they should get the packages from their distributors (or they 
are in trouble) and it's up to the distributor to divide the big packages 
into small ones if he thinks that is of advantage for his customers. IMHO 
business production installations should be allocated here too.

- developers: they know what they do (hopefuly ;-)

- peolple who install betas and CVS: they will have to download big packages 
or got to cvs/cvsup and compile themselfs.

For critical patches small packages could be provided (example kdemail out of 
kdenetwork, or kde_js) which override the basic installation. But this again 
is up to the distributors.

another possibility to reduce the need of bandwidth would be to set up a 
rsync server providing always the latest big rpms. (although I do not know 
how good rsync works with rpm packages)

just my 0,02
--
(post KDE 2.1 on SuSE 7.1, source: cvs max 24 hours old daily rebuild) 

mit freundlichen Grüßen / with best regards
Ferdinand Gassauer

PS. 
Besuchen Sie doch auch unsere WEB-Seite
please visit our WEB-page
http://www.goesing.at




 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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