Re: testing process broken
Bill Wohler <wohler@newt.com> wrote:
>cjw44@flatline.org.uk (Colin Watson) writes:
>> Bill Wohler <wohler@newt.com> wrote:
>> > The process by which software gets into testing needs to be much
>> > more rigorous than it is. Consider:
>> >
>> > xlibs won't upgrade because of bugs in ssh-askpass, sndconfig
>> > and/or playmidi that are "fixed in unstable." Why then, did xlibs
>> > get moved to testing and not the others?
>>
>> I don't quite understand this
>
> See bugs 90118 and 90345 for more details.
Oh, app-defaults bugs. Bah. I think we squashed the last of those this
weekend, at least on i386. This was a bit of a systemic problem, really;
the xlibs maintainer wanted to move /usr/X11R6/lib/X11/app-defaults to
the more sensible location of /etc/X11/app-defaults, and symlink the old
location to the new. Unfortunately, lots of other packages installed the
old location as a directory, so RC bugs were filed against them all -
but, of course, not against xlibs, since it was canonical. In an ideal
world, the most correct solution would probably have been to have xlibs
have a versioned conflict with all packages with old app-defaults, but
that would've been a seriously long conflicts line.
In the absence of explicit dependencies, maybe it should have been
handled manually in some way. I suspect the thought didn't occur to the
right people.
>> [The python-newt/libnewt0 dependency] sort of bug is *intended* to
>> be fixed by testing, and usually is. I'm not sure why it slipped
>> through the net, but it's a genuine bug as opposed to a design flaw
>> (it seems you're presenting it as the latter).
>
> Only out of ignorance. Thanks for the clarification, that's a
> relief. Question: should we report such bugs under the package with
> the dependency, the package that it was dependent upon, or something
> else like `project' or `general?'
ftp.debian.org would probably be the best place (the ftpmasters tend to
be somewhat overworked, but it should be read by at least some of the
right people). Maintainers of individual packages actually can't do
anything much about what versions end up in testing, apart from the odd
indirect nudge here and there; it's a bit weird.
>> The [testing] design is solid, though, so give it a little time to
>> get the rough edges rubbed off before labelling it as "broken".
>
> I expect nothing less than solid from you folks. I'll keep the bug
> reports coming.
Please do. Sorry if I sounded a bit acerbic earlier!
--
Colin Watson [cjw44@flatline.org.uk]
Reply to: