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

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

> 	the <foo>-concerns should probably have two possible states: "no",
> 		or "yes" with one or more links to mailing list threads
> 		stating those concerns


> 	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

> 	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: