Re: Standardization, large scale changes, innovations
On Wed, 2010-03-31 at 18:13 -0700, Russ Allbery wrote:
> Wouter Verhelst <wouter@debian.org> writes:
> > My father, for instance, often drives a screw into a piece of
> > wood with a chisel when he doesn't have a screwdriver around.
> > And I've also seen him chop off bits of wood with a
> > screwdriver, on occasion.
I like this example... If I were using a screw driver when I should use
a chisel, I would be rounding off the shaft of the screw driver, which
makes it unsuitable to screw at some point (and I am likely to hurt
myself too)
If I use a chisel to screw, I am spoiling the screw (and I am likely to
hurt myself too)
In both case:
1. I am shooting a bullet in my own feet, as I am making my futur
significantly tougher, just to a little bit lazy now.
(Also, this is really not nice if I am working with someone).
2. Not using the appropriate tool is amateurism. If you ever hire a
professional, which happens to do such thing, then just fire him off
before he makes a mess. (I am not suggesting to fire off any DD that
don't use dh ;-)
> > The same is true with Manoj. You may think debhelper is the best thing
> > [[[droping personal statements]]], but Manoj just disagrees. And as long
> > as Policy does not specify that debhelper is to be used, it's perfectly
> > within his right to not use it.
I think you just overlooked my previous email, especially the part about
industrializing.
http://en.wikipedia.org/wiki/Not_Invented_Here <-- replace "here" by ${me}
There isn't just Manoj that work on Manoj's packages (QA team, Security
team, Derivative distro... and our users!). BTW, does Manoj own those
package?. As I wrote those lines, I wonder if some developer don't
precisely use home made stuff to say "keep out, this is my own package".
A best practice isn't a standard (or a policy), still most people follow
it.
> > As long as the result is good -- a working, policy-compliant package
> -- how he gets that result is not your business.
Isn't Debian an organisation (with 1000+ developers)?
> > If you think otherwise, you should first get Policy changed, and then
> > complain to Manoj.
That's an easy move... (anyone who disagrees has to turn his proposal
into a policy!)
> Also, as a general rule of thumb, Policy should be about standardizing
> interfaces, not about standardizing tools. What matters from a Policy
> perspective is what ends up on the system, what ends up in the package,
> and how the packages interoperate for the end-user, not how you create
> them. So from that direction, I'm not sure it would ever make sense for
> Policy to require debhelper.
>
> To the extent that Policy already does this in a few places, I think it's
> a bug, since among other things it makes it much harder to figure out
> what's really going on and it makes it harder for subsequent tool authors.
I agree, the policy should not mandate a tool (because it would be
impossible to experiment *new* and *better* alternatives).
> If someone thought there was some much better design for how debhelper
> does things and wanted to start from scracth writing a new helper, they
> should be able to find documentation explaining what interfaces they need
> to satisfy, ideally.
debhelper has a standard interface quite documented in the manpages
(especially when using flat files as input). Anyone could provide an
alternative tool.
And this is a great feature. (anyone trying to do QA on the source will
agree).
> The major exception to this right now is that Policy assumes dpkg and the
> core dpkg tools
By standardizing more tools, we would be more efficient.
Those tools should be described by their interface, as you mentioned.
> (not the dpkg-dev tools necessarily) like dpkg-divert. I
> personally think this is a bug and I'd like to see the low-level
> documentation of the exact deb format, for instance, in Policy, but it's a
> very low priority compared to lots of other Policy work.
> Now of course if one orphans one's package or can't maintain it properly
> (lots of RC bugs, etc.), then I think redoing the packaging design is fair
> game once QA comes into play. Were Manoj to orphan a package, I suspect
> it's quite likely that whoever picked it up would convert it to debhelper,
> and that's fine. If I adopted a package maintained in bzr, one of the
> first things I'd do is convert the VCS repository to Git. But as long as
> the package is staying with its current maintainer and that maintainer is
> doing a good job, I think the obligation of that maintainer is to satisfy
> the interfaces, and what tools they use to do that is their business.
What about Debian users who need to modify a package for special needs?
What about peer review of the packages?
What about other teams in Debian? (nmu, porters...)
What about derivatives?
What about upstream review of his packages? (there isn't just patches).
Debian project raise it's expectation every year (cool). How do we face
the challenge to do more every year? (of course, you could do like the
[French] administration and require more civil servants)
Regards,
Franklin
Reply to: