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

Re: Standardization, large scale changes, innovations

On Thu, Mar 25, 2010 at 11:22:36AM +0100, Raphael Hertzog wrote:
> Hello,
> those questions are for all candidates. By standardization I mean that
> something should be used as default tool unless reasons exist to use
> something else (I do not mean that we sould impose something to
> everybody for all cases, but it should still be what's used in >95% of the
> cases).
> 1/ Do you believe that it's a good move to standardize our packaging tools?
>    (example: debhelper is almost standard, quilt is gaining status of the
>    standard patch system thanks to the new source format)

It has advantages and disadvantages.

The major advantage of standardized tools is that anyone can look at a
source package and immediately start working on it.

The major disadvantage of standardized tools is that if someone's
workflow, or their packages' upstream's way of distributing things, does
not agree with a particular standardized toolset, they would have a
harder time working on their packages; or they could disregard the
standards and (eventually) be frowned upon.

Since I got fed up with undocumented non-standardized tools a few years
ago, I filed a bug against policy which eventually, after a lot of
discussion, resulted in the README.source bit in policy. I think that
'documenting' can be a great help in alleviating the disadvantages of
the absense of standardized tools, without imposing any workflow on

So no, I don't think we should standardize too much. There are cases
where it makes sense (e.g., I don't think anyone would suggest allowing
uploads of RPM packages to the archive), but we shouldn't overdo it;
people should have the freedom to work in whatever way works best for

> 2/ If yes, what would be the next thing that it would be good to try to
>    standardize/uniformize?

I don't, so nothing :-)

> 3/ Do you have any preference on the tools that we should try to
>    standardize on (which source format/patch system, dh7/CDBS/yada/etc.,
>    VCS helper, etc.)?


> 4/ Organizing changes that have an impact on (a large part of|all) the
>    archive is very difficult:


This is another reason why we should't overdo it; unless there is a
substantial benefit that cannot be gotten at in other ways, I think the
downsides of trying to move the whole of the archive to something new
can far outweigh the benefits.

>    How can we change our processes so that doing/organizing such changes
>    is less of a burden?

They are not.

Consider how debhelper became a standard within Debian. Nobody ever
started filing bugs, asking people to use debhelper; rather, someone
(Joey Hess) wrote something, and uploaded that something to the archive.

People liked it, and started using it. Some filed bugs, or patches, and
debhelper improved as a result. So more people started using it, and
more bugs/patches got filed. Etcetera.

Note that when debhelper was first written, it was by far not the only
thing available to build packages; e.g., there was debmake, yada, and a
bunch of other things. These aren't used anymore, because debhelper
eclipsed them all -- not because anyone told anyone not to use them.

I think the debhelper way is the best way to achieve standards within
Debian: rather than trying to convince people through arguments, we
convince people through technology.

I also think that dpkg's current nagging about the 3.0 dpkg formats are
a mistake, for precisely that reason. People who don't like the 3.0
formats will ignore the nagging, and get annoyed; people who do not
dislike it don't need nagging to eventually migrate, anyway.

> 5/ I have the feeling that Debian is innovating less than it used to do.
>    We are more often followers rather than leaders.
>    Do you share that feeling?

Yes, to some extent. But I'm not convinced that trying to standardize on
anything will change that -- on the contrary.

>    What shall we do to make that change?

To encourage innovation, people must have the freedom to experiment.
Innovation is impossible if too many standards are imposed on people.

The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.

Attachment: signature.asc
Description: Digital signature

Reply to: