Re: m68k not a release arch for etch; status in testing, future plans?
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
Reply to: