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.
The question is what to do _instead_.
Options are:
* drop m68k entirely
+ no work required
+ saves space
- arch is officially dead
* just have m68k in unstable, same as hurd-i386 has been
+ no work required
- installability etc not guaranteed
- pretty much makes m68k a "dead arch"
* have m68k be in unstable, and have it have its own "testing-like"
suite of some description
+ keeps the arch alive
- some work to keep m68k-testing in sync with real testing needed
- doesn't have real releases
- may not have security support
* 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
- 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.
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.
> Release m68k with Etch by:
That's no longer an option. You need to think outside that box.
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.
> 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.
> How about an IRC meeting about that issue on Saturday 6:00
> p.m. UTC on #debian-68k?
(I won't be able to make any IRC meetings reliably 'til next week; you shouldn't
let that stop you from having one though)
> 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.
> 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)
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature