On Thu, Mar 25, 2010 at 11:22:36AM +0100, Raphael Hertzog wrote:
> 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).
I duly notice that this definition leaves out our Policy, which in fact
imposes practices that all package shall follow to be not considered RC
buggy. Therefore in my answer below I would not consider policy-driven
standardization (FWIW, I do think that policy-driven standardization is
good.)
> 1/ Do you believe that it's a good move to standardize our packaging tools?
I consider a good overall result to have standard tools, but the
standard must be de facto, rather than imposed.
As I wrote in my platform, I think we should diminish strong package
ownership when it clashes with package quality. A way to achieve that is
making sure that other fellow DDs will be able to work on your
packages---e.g. to fix RC bugs via NMU. Having a gazillion of different
packaging tools all around does not match that idea. IME with RCBW [1],
I'm truly glad that there are just a handful of _common_ ways to patch
packages! (and yes, I've also stumbled upon the non-common ones and I
figured them out, but it would have been way easier/faster if they were
not in the way)
Nevertheless, our constitution tells us that any developer is free to
make any technical and nontechnical choice with regard to their own work
(§3.1.1). That clearly explains that the freedom of being different in
tool choice is inherent in our way of working, and I agree with that.
> 2/ If yes, what would be the next thing that it would be good to try to
> standardize/uniformize?
> 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.)?
I don't think we---as a *project*---should "try" to standardize any
specific tool; at the project level it should just happen.
At a smaller scale, there are a lot of factors that influence whether a
given tool will become a de facto standard or not (see, on this, the
interesting work done by Martin Krafft in his Ph.D. thesis [1]). Some of
those factors include stuff like talking with fellow developers about
what they use, (perceived) technical superiority of one tool over
another, and of course advertisement (e.g. blog posts) of one tool by
its authors. This latter way of "trying to standardize" happens
naturally, it is not something the project has to pursue as a whole.
It is interesting to note here that, on the contrary, policy-driven
standardization is something the project is concerned as a whole and
that is way it has its own mechanisms.
If you really want some guesswork, according to the current trends it is
likely that in Debian the following tools will become de facto standards
in, say, 5 years: Git, quilt, dh7.
[1] http://phd.martin-krafft.net/
> 4/ Organizing changes that have an impact on (a large part of|all) the
> archive is very difficult:
This is a quite different matter than tool standardization.
I think at "tool standardization" when what it counts is a result
(e.g. patching a package at build time), but to achieve it there are
alternative tools that maintainers are free to use (e.g. quilt, dpatch,
...). I think at "high impact change" when there is an aut-aut choice
(e.g. either introduce a new non backward compatible feature or stay put
without that feature) and one of its branches impacts on a lot of other
project areas.
> How can we change our processes so that doing/organizing such changes
> is less of a burden?
I think that the right helper to coordinate high impact changes is the
DEP process [2]. DEPs do not give any hammer to force a choice upon
other, they just record the rationale of a proposed change and its
current status. In particular, DEPs do not relieve the proposers from
the duty of making a decision (by reaching consensus or even voting, if
necessary) before going forward with a given change.
[2] http://dep.debian.net
> 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?
In part I do share this feeling, but I also feel that it is quite a bit
of a "constructed" feeling by looking only at some project areas which
happen to be the main selling point of others distros (which are often
better than us at marketing their achievements).
> What shall we do to make that change?
This is an interesting topic that I agree deserves its own thread. In
short, I believe that the main reason for innovating less is just a
general decrease of enthusiastic manpower.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
Attachment:
signature.asc
Description: Digital signature