On Wed, Oct 18, 2006 at 07:00:21PM +1000, Anthony Towns wrote: > On Wed, Oct 18, 2006 at 09:49:50AM +0200, Ingo Juergensmann wrote: > > Oh well... > > It doesn't meet the release criteria because of the toolchain problems, that > > have now been solved. > > No, it hasn't. You need to be reliably abouve 95% for the entirety of:
Yes, it has. The toolchain has been solved, but the backlog isn't. Occasionally, the fact that our backlog grew is a direct consequence of the toolchain being fixed, but let's keep that as a side note. (not that I think we could release with our current backlog, but let's keep the facts clear and straight) [...] > > > The question is what to do _instead_. > > > Options are: > > > * have m68k be in unstable, and have it have its own "testing-like" > > > suite of some description > > Who's managing that suite then? > > The suite itself? ftpmaster would make it, and a britney script would > be cronned to handle it. That shouldn't require any particular attention > though. > > > + keeps the arch alive > > > - some work to keep m68k-testing in sync with real testing needed > > Who's doing that work then? > > Hinting a new britney instance appropriately does require some time > though, and since m68k doesn't meet the release criteria, the release > team won't do that. If there's no one interested in doing it specifically > for m68k (and able to), no one will. I'd be willing to work on this, provided someone can give me some guidance (I've never touched britney hints). > > > We'll be defaulting to "just have m68k in unstable" fairly soon > > > unless someone comes up with a plan to manage the testing-like or > > > etch-like stuff on an ongoing basis. > > Well, we have offers for ftp-master roles out of Debian. Still, I think it > > is better for everyone to have a (maybe) reduced set of packages being > > released with etch. > > It's not the ftpmaster stuff that needs to be done, it's the RM and > security stuff. Security stuff for *sarge* is already a problem, with > the xfree86 update currently blocking the release of r4, due to lack of > an m68k build, eg. That was the direct result of the ISP in front of the buildd being braindead. It's being fixed. > > > Note that since m68k is *not* meeting the release criteria, having the > > > release team or the security team do release management or security > > > updates is not an option. Someone from the m68k team will need to those > > > things themselves, and be committed to keeping transitions in sync on > > > m68k, doing security rebuilds and updates as necessary, and so forth. > > How likely is it, in your opinion, that someone from the porters > > team can do that, besides of dealing with porter tasks, buildd admin > > stuff and implementing coldfire support to the m68k port? > > I have no idea. In essence that's what I'm asking. I'm postponing coldfire support 'till post-etch. I wasn't getting far anyway, and it's not going to help at this point. I can put my time to better use by doing other things. [...] -- <Lo-lan-do> Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
