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. etch-m68k == having something that matches etch. 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. 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. > 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... > 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. Cheers, aj
Attachment:
signature.asc
Description: Digital signature