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:
http://buildd.debian.org/stats/graph2-quarter-big.png
before you can reasonably be considered for release.
Even if you fixed _every single problem affecting m68k_ you won't be
able to do that for etch at this point. That's out of the question. For
etch+1, it might be a different story of course.
> > 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.
> > 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.
> > 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.
> If you want to kill the m68k port, please say it straight out!
Personally, I'm not fussed either way. If someone wants to support m68k, I'm
all for it staying. If no one does, I'm all for it going.
> I believe adding problematic packages to N-F-U is actually a nice plan.
It would probably be worth having a separate list of "unsupportable"
packages, and having them be REJECTed if uploaded -- that way it doesn't
cause problems if someone builds them by hand and tries uploading, eg.
But these things need to be more than just "I believe ... could work";
they need to be "I'm think ... will work because ... and I'm willing to
do ... to make it work."
> > > This is of course just a quick shot. We can elaborate details in the next
> > > days when you're agreeing that a partial release is better for m68k than no
> > > release at all.
> > No release at all is better than a release that isn't supported on an
> > ongoing basis and drags down Debian's overall quality. No release at all
> > is better than a release that requires support work from the release or
> > security team, and thus detracts from our support of the official stable
> > and testing releases.
> Uh?
> You proposed a amd64 release above and now you're saying that no release is
> better for our userbase? Strange argueing...
The amd64-sarge release was supported on an ongoing basis, didn't drag
down Debian's overall quality, didn't require support from the release
team, and only had security support after the security team reviewed
it and decided it wouldn't detract from our support of official stable
releases.
> > > If any plan to release m68k with Etch needs some additional mirror space,
> > Archive/mirror space isn't the concern. (Well, up to a point)
> At least mirror space was an issue for amd64...
Since then we've managed to get arch criteria and the mirror split, however.
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature