Re: Standardization, large scale changes, innovations
Le Thu, Mar 25, 2010 at 11:22:36AM +0100, Raphael Hertzog a écrit :
>
> 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).
Bonjour Raphaël,
first of all, I would like to apologise in public for the the unkind comment I
made about your work on debian-devel. I should have sticked to the facts
instead of making a bad taste analogy.
This said, I think that you guess the answer I will make to your question…
I think that we should not standardise on tools, but on interfaces. To take the
patch management systems as an example, there is a convergence on storing
patches in debian/patch, and applying them through the ‘patch’ and ‘unpatch’
targets of debian/rules. I think that it is a good situation, and I recommend
against making a particular implementation the standard.
The debian/rules patching and unpatching targets were not unified at the
beginning, so I think that it is a nice example of that such a convergence can
be achieved in Debian.
I would prefer that interfaces become codified when they attract independant
implementations by their popularity. Let's take the git-core package for
example. It uses files like debian/git-core.docs that have a similar function
and mechanism that their similar counterparts in packages using Debhelper, but
they are implemented via makefiles. If listing the files to be installed in
/usr/share/doc/<package>/ in a debian/<package>.docs file is for instance
getting standard by its popularity, then there will be an advantage to little
by little make it more formal. I think that this example can be generalised.
I maintain a lot of packages that are quite trivial, so I make a heavy use of
helper tools. I find that one of CDBS and Debhelper (with or without dh) is
often more useful than the other in a case-by-case basis, and would be quite
annoyed if one of them were removed from my toolbox.
I strongly share your feeling about innovation. Trust me, when I started to
oppose the way you tie your patch system to the rest of the 3.0 source package
implementation, I really balanced this with the fact that going for 3.0 (quilt)
is anyway better than immobilism. I decided to confront your choices because
what I am asking is not to withdraw your patch system, but to make it optional.
This does not close the door, it just asks the people to make the step by
themselves.
You also described well the difficulty of introducing changes in our core
package management system. I think that we can modify our release strategy in a
way that would allow point updates to that part of our stable systems. A
reorganisation of package priorities and sections would help to put a frame
around this, and would allow other changes that I propose in my platform.
To document and standardise interfaces is a good way to ease experimentation,
and therefore innovation. Also, it would help to introduce changes in a way
that is backward-compatible, and give more independance between developments on
interacting tools, like dpkg and dak for instance.
But there will always be situations in which people need to talk together and
negociate reciprocal concessions. If I am elected DPL, I will ask the delegates
to make sure that requests for coordination are not ignored, and that decisions
are motivated. Not answering is the worse way to say no. Conversely, it may
make sense to formalise the role of the maintainers of core tools like apt and
dpkg by a DPL delegation. But this particular point is not listed in my
platform, and I would not make it a priority. Of course, if maintainers
sponaneously request to become delegates, I will consider their proposition
very seriously :)
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Reply to: