> Hi all,
Hi, I wanted to chip in and share a couple thoughts on the matter,
namely:
(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
explain:
(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).
Cheers,
--
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