Ian Jackson wrote:
> Sorry to be discouraging, but I don't think this is the right
> approach.
That's ok, I'm happy to be talked out of the auto-removals part.
> [...] I definitely don't want to see us routinely dropping packages
> from an arch, without anyone having taken a decision about whether
> this is the right thing to do.
Removal can mean two different things BTW:
* ftpmaster removes it from sid (though it will re-appear if the FTBFS
gets fixed)
* maintainer deliberately removes it from the Architecture: list
But I've seen both of these things happening *already* (to kfreebsd),
which is what led me to think about this. I would actually prefer to
avoid it.
I'm sometimes unaware of this until it's too late - because no FTBFS bug
was filed, or porters were not copied on it, or on the RM bug. I used
to file these FTBFS bugs myself but it can be tedious and I got bored of
doing it. Maybe at least *that* work can be semi-automated?
> Toolchain problems with sufficintly wide impact ought to be dealt with
> by deprecating architectures, not by dropping packages piecemeal.
That would be fair enough, if porters are made very aware of the
problems and their implications. I'd like the release team to have a
detailed list of those issues to base their arch qualification on.
I envisage some kind of a scoreboard, graphs, or those weather symbols
we all love to see.
Regards,
--
Steven Chamberlain
steven@pyro.eu.org
Attachment:
signature.asc
Description: Digital signature