On Wed, Mar 16, 2005 at 06:57:56PM +1000, Anthony Towns wrote:
> Daniel Jacobowitz wrote:
> >I've suggested (briefly) a slaved testing which tries to enforce sync
> >with the main testing archive.
>
> Hrm, I don't think I've got any idea what that means.
I hadn't thought about the details yet, but here's a stab at it. It
may be completely impractical. I have zilch experience with the
testing scripts themselves, just the basic principle.
My basic idea is to have something similar to the testing migration
scripts, which takes the decisions of the "master" copy running on
ftp-master as an input. At a minimum:
- Packages in sub-testing should not be newer than the versions in
testing, except on purpose. Porters need to be able to use newer
versions when a particular version does not work on their
architecture, but I want a by-hand element involved in that. In
normal, non-schedule-pressured, non-crippling-bug mode, they would
just fix the copy in the main archive and propogate that to
testing, and from their to sub-testing.
- Some other criteria would be used to prevent migration of new
packages, in addition to those used by the primary testing
script. Architecture-tagged bugs in the BTS might do well for
this purpose; or separate by-hand lists.
- Internal consistency and installability would be maintained for
the sub-testing repository in the same way we maintain them for
testing.
This allows the port to leverage the excellent work done by the release
team, and not get in their way - it's completely unidirectional,
nothing feeds back to the "parent" repository. And it allows leverage
of the testing scripts - with some changes, that someone would have
to pony up the time to implement, of course.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
