Re: A concrete proposal for rolling implementation
On 12471 March 1977, Stefano Zacchiroli wrote:
>> What I expect to be needed is to make rolling a "real" suite that
>> retains packages. That will probably be needed sometimes. Though
>> packages only in rolling should be a transitory situation that the
>> rolling team is expected to minimize.
> Early on in the CUT discussions on the cut-team mailing lists, I seem to
> remember---although I can't find a reference to that right
> now---ftp-master saying that to have a new suite it's enough to hand
> them a self-contained list of package/version pairs. Of course I've no
> idea whether they'd agree in doing that for rolling as it's being
> described here, but technically there are most likely little obstacles
> to that. IANAF-M.
Generally speaking, for a suite managed by someone else, in the way of
testing, we need a list containing
package version architecture
lines (where architecture includes source and all). We don't care how
one gets to this list.
We also need some knowledge about various suite properties (see table
suite in projectb) as well as version constraints (does it have to be
newer than experimental? older than stable? both at the same time?). And
it also wants to have something sane responsible for it. That is, a
team, somewhat defined, which is responsible for whatever ends up in the
suite. Which we can skin alive if needed. Something like that.
Obviously we do not want a million of suites. Every extra suite costs
time and work to maintain it. (This WILL be a bit different as soon as
we fleshed out a PPA like thing inside dak, which we currently draft a
"how this could look and work", but more on that later, when its ready
to discuss)
--
bye, Joerg
I'm convinced that the ftpmaster team are ninjas -- they do their stuff,
but they do it quietly and behind the scenes, so everybody thinks
they're asleep at the wheel...)
Reply to: