Hi,

Sven Burmeister schrieb:
> He is using the least risky way in order to be able to test new KDE versions 
> for the next SuSE release and hence helps fixing bugs and thus contributes to 
> the quality of a SuSE product, i.e. something those that do not test newer 
> versions of KDE profit from.

I'm not sure that using these packages really helps finding and fixing
bugs for the next release. The best and maybe even the only way to do
that is using factory.

10.1 + build service is not what will become the next release - that is
factory and nothing else. There might be artifacts because the way the
base system and the KDE packages are combined is different from what
will become the next release. There might be even wrong bug reports
because of that, which might actually consume additional time and effort
instead of helping.

> Further he is using a bugfix-release, hardly any bugfixes are backported and 
> supplied via YOU, so this is the only choice apart from more risky (betas and 
> alphas) or more inconvenient methods (compiling).

Of course bugfixes will be supplied via YOU. Actually there was already
a qt3 + kdebase3 bugfix YOU.

The packages in the build service are not bugfix releases. Don't mix up
the upstream development with the packaging work: From the stand point
of upstream development, KDE 3.5.3 is clearly a bugfix release, but
packaging software is much more than downloading it and making it
compile. There is integration work to do, and a version upgrade to
something that is published as bugfix release from upstream does not
necesserily have to behave like a bugfix package because upstream
development and packaging are very different things.

> If Novell would think this is too risky for users, it would not call 
> it "genuine added value" but "genuine added risk".

Added value == added risk. There is no contradiction here.

Sometimes I seriously dislike the way people expect these extra packages
to work. Some users expect them to have the same or even higher quality
than the originally distributed ones because the difference between the
version-release number and the work that has to be done to make packages
behave as expected is not clear.

And claiming that using these packages helps improving the quality of
the next release is a very problematic thing. This might be true in many
cases, but there might be exceptions, caused by artifacts and possibly
invalid bug reports as described above.

Sometimes I just don't understand why these extra packages are so
popular among consumers. The packagers are spending huge amounts of time
for doing integration work and bugfixes only, everyone who read
opensuse-commit in the last months is able to know that, and then
consumers just throw everything away because there's something available
that looks like a bugfix update because it has a higher version-release
number.

By the way, splitting KDE itself and the most popular KDE applications
into separate repositories is a great step forward compared to the old
supplementary FTP. It can prevent some common problems and
misunderstandings - if people appreciate and follow the split instead of
quickly adding both repositories to their $PACKAGEMANAGER configuration
just because they can...

Andreas Hanke

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to