Re: Let's remove mips, mipsel, s390, ...

[Brian Nelson <pyro@debian.org>]

"Thaddeus H. Black" <t@b-tk.org> writes:

> [Not private.  Reply on-list if you wish.]
>
>> However, I do think that not including amd64 (while keeping mips and
>> friends) in the sarge release due to mirroring problems is ridiculous.
>
> Amen, brother.
>
>> ... packages are uploaded too frequently, ...
>
> How often is probably too often, in your view?  (This is just a
> question.  I happen to keep a package which uploads irregularly ten or
> fifteen times per year.)

Short answer: As long as your package is a candidate for testing (and
you feel is generally fit for testing) but is being blocked by something
else, you should probably wait to upload until the current version makes
it into testing.

How often is that?  Well...

Consider package 'foo', which has either a direct or indirect
relationship with 50 other packages in Debian (it depends directly on a
few packages, those packages depend on other stuff, and some packages
depend directly on foo, etc.).  And say it's being blocked from testing
because some package in there is broken.

How do you get all of these into testing?  You have to fix the broken
package, and have all of the interrelated packages become simultaneously
eligible for inclusion in testing.  Since there's a constant churn of
packages in unstable, probably someone will upload some package in
chain, which means all of the others will have to wait for it.  Or
someone uploads a new upstream release, which turns out to be too buggy.
Then all of the packages have to wait for that one to get fixed.

In general, it would probably work best for testing if an upload turns
out to be free of RC bugs that the maintainer doesn't touch it for a
couple months.  Of course, we're all volunteers and maybe in a couple of
months the maintainer won't have time to do another upload.  But he or
she has time now, so why not just do it now?  And, without any kind of
established release timeframe, maintainers don't generally know if it's
best to wait on an upload or just do it right away.  For example, if a
maintainer decides it's best to wait until the next release to make a
big packaging change because the release appears to be near, more than
likely that maintainer will be sitting on their hands for 6 months
before they finally realize, hey, we're not actually going to release
soon.  So they make the upload, break some stuff, and generally push
back the release even more.

I don't think overly frequent uploads are the real problem.  I think the
more significant problems are:

1. Package dependencies are too complicated and interrelated.

2. Library shlibs are too tight.

3. The overall discontent with our releases taking too long make some of
   the general developer population disinterested with the release, and
   thus don't take proper care to ensure their packages are entering and
   working in testing.


The newer libtool versions are definitely helping with (1), though only
to an extent.  Modern software is just getting very complicated and is
using lots of libraries.  Unless we throw out things like GNOME and KDE,
there's really no way around it.

(2) is definitely something that needs work.  It seems like every
library package out there is just using 'dh_makeshlibs -V', and that's
unfortunate since the dependencies produced are in most cases overly
tight.

As for (3), well, that's been a known problem for years and no RM has
yet figured out how to motivate the troops.

-- 
Society is never going to make any progress until we all learn to
pretend to like each other.