Re: Bits (Nybbles?) from the Vancouver release team meeting
On Thu, Mar 17, 2005 at 05:58:21PM +1000, Anthony Towns wrote:
> Daniel Jacobowitz wrote:
> >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:
>
> I think it's easiest just to assume everything's on ftp-master; for
> mirroring, stuff's already planned to be split onto ftp.d.o and scc.d.o
> anyway. The only reasons that wouldn't happen is if ports need
> non-developers to be able to upload, or are using up lots of disk really
> wastefully.
OK. I'm going to keep the two logically separated, to answer possible
resource constraints, but it would certainly be easier this way.
> > - 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.
>
> Okay, so we've got a new suite; is that global for all scc arches, or
> separate, a la "subtesting-s390", say? The question there is "Will s390
> have a different version of the package to m68k, if one or the other is
> being more aggressively maintained?"
I don't know. This depends mostly on the dynamics of the ports teams
and on the amount of work it turns out to be. It may be that holding
up for other architectures would be just as much a problem for the s390
mantainers as it is for the core release managers; or it may be that
the overhead is too high to justify doing it for less than the full
set.
> So, say you have "foobar 1.0" in subtesting for s390, and "foobar 2.0"
> in testing and "foobar 3.0" in unstable for i386. Your buildd's been
> somewhat broken for a few weeks, and you haven't built foobar 2.0 or 3.0
> yet, but you've got it working again now. What happens then?
>
> Do you build foobar 3.0, find out there are some s390 specific bugs,
> watch it go into testing anyway, not accept it to subtesting because
> those bugs need fixing, get 3.1 uploaded to unstable, built it, watch it
> go into testing, and then have it go into subtesting too?
>
> Or do you build foobar 2.0, upload your debs to unstable, find it works
> perfectly, and get into subtesting, then wait 'til 3.0 gets into testing
> before building it and finding out it has problems?
Both of these are plausible; the difference is whether you autobuild
from unstable or testing. I would prefer the former, which means your
former case.
> Do you use the testing scripts, and thus aim to ensure subtesting's
> dependencies are consistent, or do you just copy debs across and hope?
> If the former, why bother looking at testing at all, instead of just
> pulling from unstable, and calling it, say, "scc-testing-s390"? OTOH,
> only pulling from testing makes it simpler to end up with something you
> could call "etch" for s390.
Right. I'd want to use the testing scripts, somewhat brutalized. My
hope for using testing as an input is that, come freeze time, the ports
would be relatively close in versions to the release architectures. In
particular, it would prevent them from getting ahead. The remaining
differences can be patched up by hand.
> > - 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.
>
> One of the problems with this is that you wouldn't benefit from the
> "hints" the release team prepares for britney; which might screw you
> over completely. OTOH, dealing with smaller numbers of architectures is
> easier, so maybe some of the existing automation would be more
> effective; and maybe the other britney features we planned at the
> meeting will make this irrelevant anyway.
This is definitely a real problem. Architectures which stay very close
to up-to-date might be able to take advantage of hints; I don't know
how often that would work in practice. Maybe it would motivate
additional work on the automation.
> I would really like to see some real use cases for architectures that
> want this; I'd like to spend my time on things that're actually useful,
> not random whims people have on lists -- and at the moment, I'm not in a
> good position to tell the difference for most of the non-release
> architectures.
Sure. The idea is still half-baked. If it has merit, someone needs to
finish cooking it...
--
Daniel Jacobowitz
CodeSourcery, LLC
Reply to: