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

Re: Challenge: Binary free uploading

> Hi all,

Hi, I wanted to chip in and share a couple thoughts on the matter,

  (a) why (at the moment) "Debian's buildd network" is not an area
  particularly suited to get improved by "looking at what Ubuntu is
  doing" (in other words, why little Ubuntu does there can be directly
  imported into Debian)

  (b) how the Ubuntu NoMoreSourcePackages initiative linked by Anthony
  is way more than "zomsg, look, our i386 builddz can `bzr get` and
  don't pass -b to dpkg-buildpackage"

                                 * * *

Let's start with (a). For good or bad, the fact is that in Debian,
ensuring that uploads have received a fair amount of testing and human
supervision, _both_ in terms that the source package is correct and
builds correctly, and that the binary packages do work properly, is
still a big concern.

Whenever changes like "binary-less uploads" or "autosigning buildds", or
similar, get proposed, the above concern is normally enough to stop
them. For example, if you mention in -devel the idea "maintainer does
not generate the source package, but buildd does from a VCS", a big part
of the discussion goes to ensuring the change would not negatively
affect to the amount of testing the packages get:

> * Anthony Towns [Sun, 16 Jul 2006 16:47:12 +1000]:

> and if the build was successful, make the .changes file, the
> source and the binary packages available, so that they can be checked by
> hand, and uploaded to the archive.

> * martin f krafft [Sun, 16 Jul 2006 14:24:19 +0200]:

> it's just too easy to sign and send back a changes file when you are
> currently too busy with other things.

> Thus, my idea was to require a certain number of certificates to be
> attached to the changes file, which prove that the source has been
> tested. E.g. lintian could issue a certificate just as well as

> * Stephen Gran [Mon, 17 Jul 2006 00:00:10 +0100]:

> Why not just require binary uploads, and then chuck the binary away?
> Then we are where we are today (someone managed to get the thing to
> build at least once), but all debs are built from source on the buildd's.
And, of course (with penalties, even!):

> * Bernhard R. Link [Sun, 16 Jul 2006 11:54:32 +0200]:

> I think this should have some check reading the download-logs and
> refuse the upload (and perhaps also delete all built files and
> blacklisting the requestor for a month), if the generated .deb files
> were not downloaded or the signed changes sent in within some absurd
> short time making it inplausible the build was actually checked.
> Something like a quarter of an hour, I'd suggest.

> On a second thought, perhaps better half an hour and also checking the
> .diff.gz was downloaded...

This is why, IMHO and while the above does not change, maybe it's just
more efficient to make improvements to Debian's own buildd network by
conceiving them ourselves, by just thinking on what we need from buildds
so that they adapt to our needs better.

But also, I'm really very curious (and would welcome insight from any
Ubuntu people reading this) how the above mentioned concerns for
"ensuring a minimum amount of testing" are addressed in Ubuntu. If I let
my creative mood trump in, I can think of a couple discourses that would

  (1) “if you think carefully, in the very end a lack of testing only
      hurts the autobuilders, whilst results in saved time for the
      maintainers in the common case. And since in Ubuntu we have the
      resources to increase the number of autobuilders, but our number
      of maintainers is low...”

  (2) “uploading source & binaries is sooo 20th century, mate.”

                                 * * *

Now for the (maybe more interesting) (b). Seems like after Antony posted
the link to https://wiki.ubuntu.com/NoMoreSourcePackages, the discussion
has mostly centered around the "buildds that speak to VCS" part of the
spec, but I'd like to draw your attention into a couple points that are,
IMHO, worth having spelled out (and of which "builddz talk VCS" is just
a by-product of):

  * what it really says there is "we find that the source package hinders
    our development model, so we plan on freeing our maintainers of that
    burden [pretty much as they freed them of the 'final binary packages
    are built in a clean environment provided by the maintainer' concept],
    and let they exist as an internal buildd component only".

    (In the paragraph above, "our development model" means "that where
    everybody can upload any package". But note that, obviously, that
    while they can say "everybody can play", they can also (and do) say
    "everybody can play, provided they wear the appropriate costume [bzr]".)

  * if one continues reading, though, it is not only about making things
    more suited for the "everybody can upload" environment that Ubuntu is.
    Under the "Design" section, some really nifty scenarios for maintaining
    packages under bzr is described (the "loom" plugin), which is then
    integrated with their HCT. Really yummy.

    But at the same time this makes things easier for the maintainer, it
    is also true that (since in Ubuntu they can force at some point that
    all changes to the distribution and derivatives are made through
    this schema) it gives the owners of the Bazaar and HCT a perfectly
    structured record of all the changes to a distribution, upon which
    certain operations (say, updating a client's own derived distribution
    from Dapper to Fluffy, and integrating some changes from the Ulumu
    derivative) much less time consuming.

    [Not that I have nothing against this, just wanted to spell out what
    may one be giving away without realizing by just using certain tools.]

But well, neither Debian is a "free for all" environment so that source
packages still don't suit us just fine, nor it has a need for a highly
structured and versioned record (in VCS form) of all the introduced
changes, so nothing here in (b) of high interest for us, except for
looking a bit around to see what the rest of the world is doing. Though
probably in the mid-term future we'll end up move a bit in these
directions (a wild guess).


Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
            Listening to: The Rolling Stones - You Don't Have To Mean It

Attachment: signature.asc
Description: Digital signature

Reply to: