Re: Bits from the release team and request for discussion
Hi Anthony,
On 2009-08-03, Anthony Towns <ajt@master.debian.org> wrote:
> So arm's dropped off that page, kfreebsd-* have been bumped to "TBD",
> and alpha, hppa are still accompanied by ia64, powerpc, mips and s390 as
> being "at risk". There's lots of fields with just a "?" -- apparently
> there's no info on whether the RMs have concerns about everything but
> amd64, m68k, s390 and sparc... Anyway, some suggestions:
I'm grateful for those suggestions, Anthony. That page is just a pain
to maintain though. Not everything on it is up-to-date yet but I updated
quite some chunks.
> m68k isn't "available" anymore, afaics -- it's not in unstable;
> doesn't seem any point having it in the list afaics
Yep, I thought the same but didn't dare to drop it. I agree.
> amd64 has d-i support, surely? it did for lenny, despite lenny's
> page...
I marked it as green now, together with upstream support.
> querying port maintainers for amd64 and i386 seems like a waste of
> time. is there really any concern that no one will be
> around to support them?
I guess there is no real concern there as glibc/gcc maintainers are mainly
working on that architectures. So porter requirements can be waived, IMHO.
However there should be port maintainers for the others and I see some
lacking in that regard. (One gets hit by a bus and the port dies or
similar.)
> the <foo>-concerns should probably have two possible states: "no",
> or "yes" with one or more links to mailing list threads
> stating those concerns
ACK.
> having the "Porting machine" answer be "yes" with a link to
> the appropriate http://db.debian.org/machines.cgi?host=foo
> page would be as informative and help make the table
> take up less space
True. I'm even not sure if everything's up-to-date there, yet. Aliases
would be great like machine=$arch-porterbox.
> using blue to distinguish waived requirements might be helpful,
> with something like Users: "45 (w)" to save space. Having
> (w) link to a list post explaining the waiver would
> probably be helpful for people who'd like to understand
> why armel gets a waiver for multiple buildds but hppa
> doesn't, eg.
hppa has currently 4 buildds because at least one is very crashy. But maybe
we should decommission that twin then.
I fully agree on the waiver thing, it also helps when revisiting the
decisions.
> both s390 and alpha seem to be keeping up with the build
> up-to-dateness requirements, based on the buildd.d.o
> graphs. probably worth linking the row headings for those
> percentages to the buildd.d.o graphs, really
While that might be currently true for alpha I expect that to drop rapidly
as soon as problems pop up because nobody will care. That's probably
playing into the number of porters part, but still.
> redoing the qualification page every release seems pointless; it's
> a wiki page so it's not automatically up to date or
> correct, and still needs to be validated by the release
> team; and arch maintainers don't seem to particularly be
> excited about doing it for exiting architectures... after
> initial qualification, why not have the status page be
> the canonical summary, linking to list posts for further
> information as necessary?
There is still the problem that we want porters to commit themselves for
a cycle. I don't see how we should find out about them, too, if they
do not reply on mailinglists for example.
Kind regards,
Philipp Kern
Reply to: