Hi Anthony, On 2009-08-03, Anthony Towns <a...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
