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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
