Compromise between ignoring archs and manual approval of updates
Wouter Verhelst a écrit :
On Tue, Sep 19, 2006 at 09:22:29PM -0400, Filipus Klutiero wrote:
Wouter Verhelst a écrit :
Even if you still think that doing this early rather than late is
necessary from your point of view, I would still like to search for
alternatives, a compromise; say, that you create a stage in between 'not
considered' and 'fully considered', where e.g. a package could move from
unstable to testing even if it's broken on a not-fully-uptodate
architecture, but not remain there indefinitely and certainly not
release like that (unless the architecture is eventually fully dropped).
So what to do after the definite period of time? Remove it from testing
on all arches? That's not an option.
Could you explain that a bit more? Why is it not an option?
It's not an option because it does nothing good to Debian to remove the
package for all other architectures, except increasing the lagging
architecture's archive coverage in testing; which is certainly not worth
removing useful software for other archs.
You're free to search for alternatives, but there's little to find.
I realize that. I also want you to realize that the current way is not
optimal, and will actually make it harder for an architecture to reach
releaseable status again once it's no longer in that status.
It was clear from the message I was replying to that you considered the
way the release team handles this non-optimal, and this is what makes me
react. If ignoring an arch for testing propagation is not optimal, there
has to be a more optimal way to handle things, between that and manually
approving updates that introduce regressions as is done by default.
There may be possible compromises here, such as adding a constant delay
from the moment where an FTBFS on the problematic arch becomes the only
blocker for testing transition. For example, foo 1-1 is in testing for
m68k and an urgency low 1-2 upload FTBFS on m68k. If 10 days after the
upload nothing else but that FTBFS stops propagation, add the package to
a "recess"(?) DB. If there is no improvement after 5 days and the
package is still otherwise ready for testing propagation, update anyway.
Nevertheless, I expect that even if implemented, such a measure would
only be of little help, for very temporary issues.
Currently, it's a bit like, "once you're there, we don't care about you
anymore". Instead of helping architectures, you push them deeper into
problems with that attitude.
Or "once you're there, we can't afford to help you anymore". But really,
this is policy, not "attitude".
Note that I'm not complaining about this -- the rules were clear, and I
don't think we would've reached it had they been different in the way
that I'm suggesting; however, I do feel that this is something which
needs to be thought about for the next release cycle, because you *will*
run into problems otherwise.
Problems such as not officially supporting m68k? Sorry, but I don't
think that's a big deal in 2006/2007. I agree with Steve Langasek that
the effort from m68k porters was diligent, but it's normal that support
is decreasing at this point, and I guess the release team would like
this to be accepted without being called [a bit] aggressive.
Reply to: