Re: Library packages depending on data files
On Fri, Feb 06, 2004 at 02:29:20PM +0000, Colin Watson wrote:
> On Fri, Feb 06, 2004 at 02:44:36PM +0100, Eduard Bloch wrote:
>...
> > > [1] even build dependencies are ignored
> > > [2] more exactly, they check whether the RC bug count for a package is
> > > higher than the estimated RC bug count of the version of this
> > > package currently in testing
> >
> > I am not a friend of testing either. It sucks because of generic flaws
> > in the idea, listed above.
>
> Those aren't generic flaws in the idea. The first is fixable in the
> testing scripts but just hasn't been done (aj is happy with the idea, I
> believe, but it's more sensible to do it at the start of a release
> cycle). The second should be fixable by bug tracking system
> improvements, which as of recently are finally making progress again.
There are still problems with testing that aren't as easy solvable.
If testing is frozen, there will be at the beginning of the freeze
packages with a more recent version in unstable than in testing. Someone
will have to check _all_ these packages whether an important fix is
missing in the package in testing or e.g. a known security hole might
stay in testing.
It would be better if the BTS wouldn't close bugs unless they are fixed
in testing (only mark them as fixed-in-unstable) and close them when
they are fixed in testing.
But even this might break if there were problems fixed in a new release
that were never reported to the BTS.
These kind of problems can in no way I can imagine be handled
automatically, and considering e.g. the number of trivial to fix open
bugs a "the maintainers are responsible for this task" is not an option.
> Colin Watson [cjwatson@flatline.org.uk]
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: