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
Attachment:
signature.asc
Description: Digital signature