[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: new release process (package pool) being proposed



On Mon, Oct 25, 1999 at 05:29:46PM -0200, Lalo Martins wrote:

[package-pool/hardlinks/mirror bandwidth efficiency]
> Jason informs me this is already done by rsync, and we're
> moving our mirrors to rsync, so, this is already solved
> regardless of whether we want to use the Incremental process or
> not.

This drops heaps of things from the `package-pool' style though. You
can't have multiple source versions, you can't have multiple binary
versions, etc.

> > 	* do `installability checking'. I've done some code (see my
> > 	  previous mail) that checks depends/conflicts within main.
> > 	  It's about 2000 LOC, bits of which are incredibly horrible
> > 	  and complicated.
> Have you tried using apt code?

The Apt code doesn't do real installability checking (it ignore conflicts,
which I think are important for this application); and the existing
checking apt-cache does isn't exactly what's needed here. It was more
convenient (for me) to do it without trying to learn libapt as I went. :-/
I'd like to go back over it a bit and see if it can be added to Apt at
some point though.

In any event, if the code really is that easy, that's just more argument
to doing it beforehand to silence all the whiny little objectors.

> > > Please make a list of the code we would need.
> > > Please make a list of the added burdens on the ftpmasters.
> > Erm. As proposer, this is really /your/ job.
> No, because I made a ``political'' proposal - if we _want_ this
> new system. If this was a ``technical'' proposal it would have
> gone privately to the ftp team.

Trying to say it's this or it's that is pretty stupid. It's really both.
If you try to pretend it's just political, you'll end up with a nice
proposal and general agreement, that's never implemented; or else you'll
end up with a whole bunch of completely political objections about how
this isn't the right way to go about it, or this hurts my feelings,
or this other way of doing it would be clearly better, or whatever.

Think of demonstration code as a nice trump card to get by these
objections.

A prototype is also the best (and, IMO, only) way of showing feasability
too. And if it's not feasible, we shouldn't be voting on it.

> No, it's very different. Debconf is a much less touchy subject
> politically. Variations on the ``package pool'' theme have been
> around for more than one year, and every time it's brought up
> there are strong objections.

Cite?

Here's at least one counter-cite for reference:
   http://www.debian.org/Lists-Archives/debian-devel-9808/msg01028.html
   http://www.debian.org/Lists-Archives/debian-devel-9808/msg01050.html

> Or in other words: When debconf was brought up, there was
> consensus. If there hadn't been, it would have to be voted on
> first. Even if it wasn't voted on, anyone could just have gone
> and coded it, because testing debconf wouldn't mean _screw up
> the whole archive_. But we can't just ``test'' a new release
> process, can we? Either we do it, or we don't.

Sure we can --- we can hijack some other SPI owned / temporarily donated
machine and run the scripts on it, and have the ftp maintainers (or
proposers pretending they're ftp maintainers) make it work for a month or
two. Should give you a good idea how much work goes into it, and whether
any automation is properly handled. Should also give you an idea just
how worthwhile it is (ie, if you can still get at fresh-but-bugfree
packages in spite of buggy new uploads).

> But if I sit to work on an implementation of the incremental
> release process, and the project decides not to use it, I will
> have completely lost some weeks of my life (one, I say, but you
> swear it's more). So you see my point now?

Well, maybe we differ in how many people we think want it, but I don't
see much difference here from debconf, personally.

In any event, how about we work on getting the code written? I'm going to
keep plodding away at my code, if you (sing/plural, take your pick) want
to work on that too, feel free to bug me either on this list, -devel, or
by private email.

Cheers,
aj, who might add that he sees voting as a quick and easy way of ignoring
    the objections of up to 49% of your population...

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
        results in slower code, and it results in more bugs.''
                                        -- Linus Torvalds

Attachment: pgp5JUCvHBs77.pgp
Description: PGP signature


Reply to: