Re: Compromise between ignoring archs and manual approval of updates
Wouter Verhelst a écrit :
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,
It's normal that maintainers care less when an arch loses it's canditate
status, since among other reasons fixing things will unlikely make a
difference in "official" Debian. Did you mean that it makes maintainers
care too few?
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?).
This is a direct consequence of not considering an arch for testing
migration...I don't see how it could be any different unless one wants
to manage its own testing.
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.
Sure, but what?
But really, this is policy, not "attitude".
Can we please not squabble over words?
Whatever.
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.
When rereading myself, it's hard to believe that I simplified
"aggressive with removing an architecture from being considered for
testing" to "aggressive", but I did. Sorry.
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.
If one reads popcon to the letter, Debian is *already* little more than
a great i386/amd64 distro, that is about 8% 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 it doesn't happen in time, users will be 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...
Seriously now, what should the release team do to both consider and
care? Steve Langasek won't pull a magical "SCC"-friendly trick out his
sleeve now that his m68k enemy is dead [for 4.0]. If nobody has concrete
propositions, the release team will consider, care, and do nothing
particular. If you have concrete proposals, I think that Steve already
welcomed these, so please share. Also, if the release team does nothing
while it should do something, it will be Debian's problem, not just the
release team's. But nobody will complain to you if something happens to
SPARC or alpha. There's only a chance that people are grateful that you
suggested an efficient improvement.
Reply to: