Re: libstdc++... Help please
On Wed, Apr 30, 2003 at 01:42:20AM +1000, Anthony Towns wrote:
> I'm not sure where you get that from; woody was released July 20th last year,
> which is a little over 3/4th of a year ago, and uploads were being accepted
> into testing without special consideration up until pretty much a year ago
> today. The libreadline-java from stable, for example, was uploaded on 19th
> April 2002, eg.
> You can make claims about things like X being overly old (X 4.2 was
> released January last year, we're shipping X 4.1 in woody), but that's
> not really very meaningful when we're not shipping X 4.3 (released two
> months ago) even in unstable.
Woody was effectively frozen around Jan 2002, no major changes to
packages were permitted, etc. The fact that other distributions make
releases 2 - 3 times a year and debian still does multi year releases
ensures the users we have left, that aren't using it solely for servers
where stability is paramount, will be using unstable.
On a side note tracking bugs in testing would be interesting, because it
is generally thought testing is more stable than unstable, but I doubt
this is really the case. Right now we generally close a bug once it goes
into unstable but that bug that was just fixed probably still exists in
> > wasn't as bad as before woody was released, when it was ~ 2.5 years old.
> If you're implying this isn't a good thing, and that we should be providing
> current software that's bug free and reliable, you might like to consider
> fixing all of:
- snip my numerous RC bugs -
I plan to work on them as soon as I graduate (which is in two weeks)...
I closed quite a few bugs (RC and regular) when I had some free time
earlier this month, I still have around 600 open bugs though.
In general I don't think its a good idea for a package to having only
one maintainer. It may work for smaller packages, but even then many
times maintainers vanish or forget to update their packages. I think
having a rcs system that contained all the packaging information
required to build the entire distribution in one place that all DD's
had access to (and actually used) would be a good thing. That along
with a method of automatically determining which packages are out of
date with upstream (possibly using a mandated watch file) could help
to keep debian up to date. Having a centralized repo could also help
with other things such as updating i18n templates, etc. (imho of