[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: