Moin,

On Sat, 09 Mar 2002 13:03, Dirk Mueller wrote:
> On Fre, 08 M=E4r 2002, Neil Stevens wrote:
> - the libtool update does _not_ require an operating system upgrade.
>   autoconf is a perl and m4 based package of less than 1MB size in sour=
ce.
>   compiling and installing it takes less than 5 minutes, it is compilab=
le
>   out of the box on about each and every broken system you can think of=
=2E

Many people dislike to install perl-based packages because usually it's h=
ard=20
to uninstall them (at least I felt like that with quite some sources usin=
g=20
perl). That's why people prefer packaged-versions of things like automake=
=20
etc.

>   Furthermore many newer distributions ship it by default anyway.

Not everybody wants to update to a newer distro every half year, I'm just=
=20
lucky to have a new one because I bought a new hdd and reinstalled my who=
le=20
system.
In general backward compatibility is always the better way than supportin=
g=20
_only_ the hippest and newset versions.

>   If you upgrade your operating system instead of updating autoconf its
>   your decision and not forced by KDE itself.

If you want a newer package of autoconf you usually have tons of dependen=
cies=20
which often lead to updating the whole distro.

> - The build requirements update was a step to do anyway. We simply can =
not
>   keep the compatibility with autoconf 2.1x and 2.5x over a longer peri=
od
>   of time. For my personal opinion, adjusting the build requirements is
>   better done for a major release like 3.0 instead of a "normal" releas=
e
>   like 3.1.

Then why didn't that happen somewhere before feature freeze started? Chan=
ging=20
the build-system is also a feature IMHO.

>   b) maintain an "admin.old" directory with the older checkout for
>      people to download and use. However I almost bet that replacing th=
e
>      admin dir before compiling is even more work than updating autocon=
f.

Having an old admin-dir in kde-common and make symlinks in every cvs-modu=
le=20
might be sufficent for developers that cannot currently upgrade their=20
automake/autoconf.
I'd vote for a solution like that

> - With the size of KDE and the amount of apps and the amount of users
>   its unrealistic that you will reach the "open bug reports =3D=3D 0" a=
im
>   at _any_ time.

But sorting out the problems regarding styles/colours was way too late an=
d=20
it's still not finished, at least for me.

The most obvious thing is kicker and kdesktop don't apply new colourschem=
es to=20
their popupmenus, looks funny to have a transparent menu with white text =
just=20
because these damn stupid apps did not set their text-colour to black :/

> The only solution I see currently is providing a "configure" script for
> "make -f Makefile.cvs", that will pick up the "right" admin dir. I will=
 ask
> Stephan and Michael to consider this.

[x] we need that

>   by my "the release coordinator has spoken" - rants. Maybe I was too
>   loose this time, so probably we find the golden way of doing things f=
or
>   KDE 3.1.

Yep, I don't have anything against a real freeze with just bugfixes going=
 in.=20
I know it slows down development quite a bit but overall I switched to=20
unix/linux because of stability, not because I want the same bugginess as=
=20
under other OS's :)

Stability comes _before_ features, never forget that

> > The justification for these changes was
> > explained very well by the KDE 2.2 release coordinator Waldo Bastian
> > in a mail to the developers (5), in which he said "[Y]ou will have to
> > respect release freezes" if you put your code into KDE.
>
> Hmm, I always tried to express that more gently, but if you find Waldo'=
s
> mail okay, I will quote it in my next regular-rant mail ;)

I like a clear statement like Waldo did as well. It's ok to say "Now stop=
 the=20
featuritis and make it work instead".

> > New leadership for KDE 3.1 is needed.

Nah, the "leader" just has to change his strictness a little bit :)

Bye, Stefan aka mETz
--=20
sgehn@gmx.net | ICQ#51123152 | Moege der Pinguin mit euch sein