On Wed, Oct 18, 2006 at 09:30:00AM +1000, Anthony Towns wrote:
> On Tue, Oct 17, 2006 at 09:12:52AM +0200, Ingo Juergensmann wrote:
> > What are the porters wanted to say? "We want to release with Etch?"
> No, releasing with etch is out of the question -- m68k doesn't meet the
> release criteria.
Oh well...
It doesn't meet the release criteria because of the toolchain problems, that
have now been solved. With a little time and adding some still failing
packages to N-F-U, I'm quite confident to fulfill the release criteria.
> 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?
> + keeps the arch alive
> - some work to keep m68k-testing in sync with real testing needed
Who's doing that work then?
> - doesn't have real releases
> - may not have security support
I don't think security is a real issue. See below.
> * have m68k be in unstable and have an "etch-like" release, same as
> amd64 did
> + arch is alive, even if not releasable
> - someone needs to do release management for it, which means
> fixing at least the 700 uninstallable packages, etc
With the fixed toolchain issue the number of uninstallable packages will
significantly drop in the next time, I'm sure.
> - someone needs to do security support for it on an ongoing basis
>
> 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.
> 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?
If you want to kill the m68k port, please say it straight out!
> > Release m68k with Etch by:
> That's no longer an option. You need to think outside that box.
You still keep refusing to give arguments why it's no longer an option. For
me it *is* still an option when we bring down our backlog and add some
packages to N-F-U. Even some RMs would considering this option if the count
of uninstallable packages drops <100 packages. So, why isn't this an option
for you? Who is "you" anyway now? Ftp-master or DPL? I'm just curious...
> Sorry, I know we're talking somewhat at cross-purposes here because
> I've been staring at dak behaviour for years and y'all haven't. You
> need to come up with a way of managing your own testing/stable release
> yourselves, leveraging the work of the release managers/security team,
> but not relying on them to assist you at all.
> That might involve having a different package selection to what's in
> official etch, eg; but if so, that will be a divergance that will create
> more work for you, and you'll need to have a plan to deal with that.
I believe adding problematic packages to N-F-U is actually a nice plan. So
far you haven't brought up arguments why this can't be done - except "m68k
is not matching the release criteria" - whereas I try to find a way how it
can match them again.
> > 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...
> > Hmmm, I doubt that this work out well. It's just a feeling.
> > Most m68k users are using stable, I'd say, so a stable release would fit
> > best the needs of our users. Forcing them to use testing might be a bad
> > idea.
> Having it be a "stable" release means handling security updates for 1.5
> years or more, which can be a significant amount of work, since it has
> to be in addition to the ongoing effort to maintain testing/unstable.
Again... I don't think that security updates are an issue, as Joey stated
repeatedly in the past that this doesn't matter much, if the security teams
builds on m68k or not.
I've even offered the security team the former buildd akire, which the
wanna-build admins failed to add its ssh key to the w-b access again after a
dead disk for *over* a year now, which is partly a reason for our current
backlog. So, if you want to help the m68k port instead of stating "it
doesn't meet the release criteria", a way to do so would be to ask for its
ssh key inclusion with your DPL hat on.
Otherwise the offer to the security team of using akire as a security buildd
still stands. I can't do much if the security team don't want it, but then
again I interpret that as a matter of fact that the security team has enough
m68k buildd power already.
> > Anyway, when m68k would be allowed to rejoin Etch with point release, things
> > might be ok,
> I wouldn't expect this to happen, anymore than amd64 joined sarge during
> any point release.
> > 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...
--
Ciao... // Fon: 0381-2744150
Ingo \X/ SIP: [EMAIL PROTECTED]
gpg pubkey: http://www.juergensmann.de/ij/public_key.asc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
