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 anyone. 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 them. > 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.)? No. > 4/ Organizing changes that have an impact on (a large part of|all) the > archive is very difficult: Indeed. 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. http://www.schneier.com/blog/archives/2009/01/biometrics.html
Attachment:
signature.asc
Description: Digital signature