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 z...@{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
signature.asc
Description: Digital signature
