Re: Woody retrospective and Sarge introspective
Raphael Hertzog wrote:
> Le Wed, Jul 31, 2002 at 02:08:57AM +1000, Anthony Towns écrivait:
> > Which adds an extra distribution that has to be:
> >
> > * carried on the mirrors (+50%)
> > * tracked in the BTS (+75-100%)
> > * maintained by each developer (+100%)
> > * administered by ftpmaster, etc (+30%)
> > * understood by our userbase (+30%)
> > * tested (+90%)
>
> Luckily enough, there are similar figures on the other end :
> - average size of the hard drive +100%
> - average growth of network capacity +x%
> - number of debian developers +100%
Perhaps you missed the "each" in what aj said. It was my experience that
once testing came out, I had to devote about double (or more like
triple) the time to keeping track of which versions of my packages were
in which distribution. This involves reading the output of a
grep-execuses cron job each day, which I never had to do before testing,
and looking at complex dependnency issues in testing, and
downgrading/fixing falsely release critical bugs that keep my packages
out of testing, and taking care to pace my release frequency so that new
versions of packages get a chance to get into testing.
This is not work that can be diminished for my by adding another
developer to the project. If I have to do all this work for all of my
packages for another distribution on top of testing, it simply means
more work for me. Especially if this "candidate" thing requires _manual_
promotion from testing.
(Not to mention that vast increase in the number of debian developers
brings with it many problems of its own, which you are ignoring or
sweeping under the rug with so many other problems.)
> As for maintainers, the doubling of work is not always self-evident
> since people already provide two version of the packages but one in
> experimental and one in unstable.
By contrast, I have not found that tossing a package into experimental
or some other apt repository is a lot more work, because it's not
something I have to worry about keeping in a releasable state.
> And as I said, not all maintainers
> will use the possibility to have 3 versions of their packages. Very
> simple packages may well go into candidate directly without having
> separate versions for unstable/testing (example: several of my
> binary-all perl modules would fit in that category).
If you provide this out, why do you think anyone will bother with doing
it any other way? And if noone does, what is the benefit of candidate
then?
> For our userbase, candidate is not difficult to understand in particular
> if they already managed to understand testing ! :)
Good lord man, were you on debian-user and #debian over the last 1.5
years? Vast, vast confusion.
> I wouldn't call that a minor problem when it involves the update of
> hundreds of packages with new (not very well tested) code. By pushing
> those in unstable/testing we're effectively making sarge unreleasable
> until things settle down (several months imho).
Provide concrete examples of packages in sarge that have had brokeness
"pushed" into them from unstable. The vorbis breakage? No, there are
release critical bugs holding it out. The
base-config/debootstrap/aptitude/dselect breakage? Nope; base-config has
a RC bug on this, debootstrap probably does too,
--
see shy jo
Reply to: