Re: m68k release future
On Fri, 27 Oct 2006, Anthony Towns wrote:
> On Fri, Oct 27, 2006 at 02:13:03PM +0200, Wouter Verhelst wrote:
> > Um, I think I've missed something. What'd be the functional difference
> > between the two?
>
> testing-m68k == having something that updates from unstable at its own
> pace for m68k only. That might mean lagging behind the real testing if
> there are toolchain problems, eg. If you wanted it to, it could mean
> advancing ahead of the real testing if some RC bugs for some release
> architectures don't apply to m68k.
That's what I was planning to work on. I do not anticipate advancing ahead
at the current stage, with the usual we're-getting-real-close-to-release
frenzy :-) Barring a real bad messup in one of the other archs, but I'd
rather not see that.
> etch-m68k == having something that matches etch.
While I see that we're getting back into step, we're lagged by a
considerable margin. What Roman is arguing for is to postpone dropping
m68k from etch. If I understand you right, we will at least have to
uncouple m68k testing from the rest of testing. If we succeed in catching
up fast, we might end up with a m68k testing that closely approximates
testing (possibly minus a number of packages that we decide to drop).
> Right now, the practical difference is that m68k needs to be dropped from
> actual etch, and some new suite created that you guys can start poking at.
> If that's testing-m68k, then you'll probably find yourselves diverging
> from etch to the point where an etch-m68k release isn't possible. I
> might be wrong on that score though.
I expect us to diverge at least temporarily. What your earlier suggestion
precludes is rejoining etch in the (unlikely, from your POV) case that we
catch up. Roman mainly takes issue with that, I think.
> Maybe you want to have a testing-m68k now, with the expectation of doing
> a snapshot that matches etch as closely as possible when etch releases,
> and leaving it open whether you want to do snapshots again in future
> before the next new stable release.
That was my plan, at least. Please note that I still haven't received any
further information as to how to use the code at
http://ftp-master.debian.org/testing/update_out_code/ (I think I am
missing testing/Makefile.PL), or whether I need to get access to
ftp-master first. If you rather do without my help on testing-m68k, or
think I'm not up to it, just say so.
> > Isn't it going to be so that we'd be able to do our own
> > arch-specific NMUs in both cases? Or is it in both cases going to be a
> > matter of deciding which package will be part of the distribution and
> > which not?
>
> Well, mostly, I was hoping you'd tell me what you want to do for that...
>From my POV, mainly the former. Plus reordering the build queue based on
what packages make the most sense to have, both from a dependency and
build dependency perspective, and from a 'might actually be useful for
m68k' perspective. In that order of priorities.
> > The point is that if we can actually get something out that is as close
> > to etch as possible, that we don't have to redo everything the security
> > team is doing already anymore.
>
> > If we do our own snapshots and we do want security support, we would be
> > pretty much on our own. That's not what I'd like to see.
>
> I'd like to see snapshots for testing anyway, and Joey Hess has
> expressed a similar interest, among others. We haven't managed it yet
> though, obviously. The unembargoed security team are doing some work
> at supporting testing again atm too, btw.
Well, seeing that you're at least as busy as everyone else, I'd prefer to
get as close to released etch as possible, to be able to piggyback on the
security team's work. Not to mention to prevent bug rot in general.
In summary: I should rather try for testing-m68k, and try to let that not
fall behind too much. If things look up, get as close to the other archs
as we can (and I'd appreciate the option to rejoin etch if we can make
it). Get a snapshot 'etch-m68k' around the time etch is released, if we
cannot get close enough.
Michael
Reply to: