Re: new release process (package pool) being proposed
On Tue, Oct 26, 1999 at 11:27:06AM +1000, Anthony Towns wrote:
> 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.
Gee... why? I don't see the relationship.
> 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.
I already said I intend to do that. I do have my day job to
take care of, and I have to have www.cosmetica.com.br working
before friday, but I'll do whatever I have to do to write this
code. Not because I think it's necessary, but to ``silence all
the whiny little objectors''.
> > 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.
I never said it was ``political _only_'' :-) My point is that,
it's _so much_ political that I thought it would be polite to
ask first. Because the subject is touchy, not because it isn't
technical. Let's see. If someone proposes that we drop ftp at
all, it would be a very technical question right? Even then, it
would be a very touchy political subject, so he'd better ask
first, right? That's what I mean.
> 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.
I see this risk, yes. But I'd still like to see what's the
general feeling about it. I can implement it alone if needed
(not that the code will be specially pretty, but it'll work).
> 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.
The number of risks is as big as proposing without code. I'd
get a lot of objections on the ground of ``your code sux''
instead of ``the idea sux'', and this would be as pointless as
any other way.
> > 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
Check _all_ the followups. These threads degenerated into
flamewars. Of course the ugliest ones were in -private (as
always). Search for ``pool'' in the -private archives (@master)
[inability to test the pools efficiently]
> 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).
Looks cool. See? That's one of the reasons I asked... 500 heads
think better than one :-)
> > 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.
Debconf would still be useful if it wasn't policy. Debhelper
isn't policy but it's useful.
> 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.
I'd really appreciate help. Not only programming, but even
working on a middle-ground between our proposals, because yours
sounds very reasonable too. I'd still prefer to leave multiple
versions of a package in the lower layer (call it ``pool'' or
``unstable'' - I like the name change for psychological
reasons, it will make people see it's a different thing). And
I'd still like to leave maintainers the option of deleting
packages from the middle layer.
> 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...
That may sound tyranical, but this is a good enought reason to
vote for me ;-)
[]s,
|alo
+----
--
I am Lalo of deB-org. You will be freed.
Resistance is futile.
http://www.webcom.com/lalo mailto:lalo@webcom.com
pgp key in the web page
Debian GNU/Linux --- http://www.debian.org
Brazil of Darkness - http://www.webcom.com/lalo/BroDar
Reply to: