Re: Compromise between ignoring archs and manual approval of updates
On Thu, Sep 21, 2006 at 01:49:21AM -0400, Filipus Klutiero wrote:
> 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.
Yes, I agree; I'm not convinced this would in fact do any good, and I
would recommend against that.
The main problem isn't even the fact that an architecture isn't
considered for testing migration anymore; the main problem is the fact
that it makes maintainers care less, and the fact that it seriously
degrades the quality of a port's testing distribution, which in turn
makes it hard for people to, err, test it, so you get less bug reports
and it gets even harder to fix bugs (how can you fix bugs you don't even
know about?).
> >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".
I'm having a hard time believing this. Sure, I understand the release
team wouldn't want to waste time on ports that are lagging behind;
however, it would be nice if there was more for a problematic port to
work with than there is now.
> But really, this is policy, not "attitude".
Can we please not squabble over words?
> >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?
*sigh*
This is not about me, and this is not about m68k. The above is so far
away from the point I've been trying to make in these last two mails
that I'm starting to think there's something wrong with my English.
Well -- mine, or yours.
> 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.
I didn't call anyone aggressive; please don't put any words in my mouth.
What I'm saying is the following: this is the first time a port has been
removed from Debian, and I would expect that you'd evaluate what you've
been doing so as to make the procedure better for the same situation in
the future. Next time, it won't be m68k, but SPARC, s390, or Alpha. If
you make it hard for a port to get out of problems, you turn Debian into
a great i386/amd64 distribution, but little more.
I'm not saying that we would've made it had we been considered for
testing migration at this point; there were other issues that were
holding us back; if this would've been the only thing, I would've been
asking around for ages already.
But it is a fact that not having a decent testing distribution has
slowed us down from time to time; that having to catch up had we been
able to fix all the other problems would have made it much harder for us
to make it at this point. This is a problem, not just for the m68k port,
but for Debian as a whole, and I would like the release team to consider
this. There is more to testing migration than "if it doesn't happen in
time, maintainers might get angry".
If the release team does consider this and decides that they just don't
care, it's their problem. But then don't come complaining that I didn't
warn you when the SPARC or Alpha port maintainers find that they have a
"slight" problem. I won't deny that the m68k port does not have much
value for most people at this point. In fact, IIRC, that's what I opened
the Helsinki meeting about this subject with...
--
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
Reply to: