[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: XFree 4.2.0 - again

* Lasse Karkkainen (tronic2@sci.fi) [020415 22:04]:
> Someone said that X is a difficult package to maintain and that there is 
> nothing wrong if PACKAGING it takes 3+ months. People have managed to 
> install it from sources in matter of HOURS (well, that didn't work for 
> me, dunno why). Based on that packaging it during a single weekend 
> should be possible. As we are talking about UNSTABLE here, no real 
> testing needs to be done before releasing - that's what the Debian 
> Unstable is for, right?

I'm going to try to explain why this isn't the case.

Just so you know, I was, for the most part, the only developer for
TurboLinux version 6.0 through 6.0.4 (give or take).  I took over
for someone else who did the beginning part of migrating to the new
libc.  I had someone help by doing the X packages, but I always had
to fix "inter-packages" issues.

TurboLinux *never* had a package as good as Debian had at the time.

To package something for debian, it must not just *compile* for the
developer (which is all we really cared about at the time at
TurboLinux), but it must compile on the rebuild server.

It also must compile on multiple platforms.   That isn't usually a
trival task (we only cared about x86 at TL).

Dependencies between packages is hard. Since xfree includes the x
libs, a *lot* of packages depend on it.  No one would be happy if
installing X4.2.0 removed all their x applications.

In addition, imaging that Brandon created a crappy, done on a
weekend, package for x.  Can you imagine the number of bugs?  And
Brandon would have to reply to them all.  Under the way bugs are
managed in Debian (even under unstable) this would be hell for him.

Now, maybe you have some point.  Perhaps some packages should be
flagged as "very alpha" (ie, pre-beta).  In that case, bugs
*wouldn't* be allowed to be posted against it, and maybe the user
would have to manually say "I understand this package could destroy
everything" for each alpha package.

That might be a nice feature.  But then again.  When Brandon gets
packages that are that quality, he usually makes them available
seperately, which has a similar effect.

Finally, you mentioned that you thought that maybe someone else
should do the new packages since Brandon is busy finishing up X4.1
for woody/testing.

On the surface, it seems like a good idea.  But in practise, it
requires the new developer to be in tight coordination with the
goals of the new developer.  In practise, it would be better if this
(currently fictional) developer finished up 4.1 for Brandon, while
Brandon does the starts on the new one.

Allowing packages as complex as the X packages to upgrade smoothly
is very hard work and Brandon does a very good job.

I hope that I have explained why Brandon is doing a very good job
and that it *is* very hard, despite the fact that it seems like it
should be fairly easy.

I understand your fustration, since this is something that impacts
whether you can use Debian on your new hardware.  But its something
that should be done right.

I don't know how you'll take this email, or how badly you feel after
the responses on the mailing list.  It might be worth knowing that
every so often (about every few months) a flame-Brandon-fest starts.
I don't particularly like this because Brandon does do a good job.

I would like to ask you to offer an apology to Brandon, saying that
you didn't know that it was a difficult task and maybe say thank you
for the work he has done already.  But that's your choice.


	Quidquid latine dictum sit, altum viditur.
	(Whatever is said in Latin sounds profound.

The Doctor What: <fill in the blank>             http://docwhat.gerf.org/
docwhat@gerf.org                                                   KF6VNC

Attachment: pgpVUjbGLffgr.pgp
Description: PGP signature

Reply to: