On Fri, Oct 27, 2006 at 05:55:13PM +0200, Michael Schmitz wrote: > > 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.
Err, I'm talking about what we do prior to etch's release. > > 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. I was actually more thinking you'd end up ahead of etch proper, but whatever. (I don't know if it's likely or not; I just don't think it's relevant atm, and don't want to spend time discussing it) > > 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), There's no perl stuff anymore. update_out.py is the script you want. We're probably better off having a tutorial session at some point when we know what we're trying to actually achieve, though. > 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. No, I just like to know what we're trying to achieve before starting to do anything. Okay, so the idea is: (a) move m68k from etch to testing-m68k (b) automatically promote m68k packages from unstable to testing-m68k when the same version gets promoted into etch. (c) when, or after etch has released, make a snapshot of testing-m68k called etch-m68k if possible. possibly simply include that in etch proper if the RMs deem it to meet the release criteria. (d) over time, improve the promotion rules for testing-m68k to be a proper m68k-only britney run with appropriate criteria for m68k (for example, counting debian-68k@lists.debian.org:m68k-rc usertagged bugs as release critical, or :m68k-non-rc as not being RC in spite of a serious severity) Yes? No? Cheers, aj
signature.asc
Description: Digital signature
