On Mar 06, 2011, at 08:55 PM, Arto Jantunen wrote: >I used to choose tools based on the language they are implemented in, I >justified it with the old "it needs to be in a language I know/like in >case I need to modify it or fix bugs in it" excuse. Since then I learned >my lesson and, unless I'm specifically planning to modify a certain >component, the language it is implemented in does not matter (except for >cases where I have a fanatical aversion to the language, but I really >can't recommend adopting this mental ilness as a policy).
I rarely intend to go modifying most of the packages I do dabble in, but it often turns out that way anyway. That's the beauty of open source. And even though I *can* hack in many languages, doesn't mean I *want* to :). >In the specific case of a project implementing a programming language I >can understand the PR advantages of being able to claim to be "self >hosting" by using a VCS implemented in that language. As I understand >it, this was a major concern for upstream Python, but I don't think that >point concerns the Debian python team. > >> One reason could be that git is the de-facto standard for Debian. I guess >> choice of dVCS is the editor-wars of the 2010s, and probably just as silly. > >The difference of course being that the editor a person uses does not >concern anyone else in any way (text written in emacs works just fine in >vim), but the VCS a person/team uses concerns a lot of people in a lot >of ways. Most VCS client tools can't deal with the repo formats used by >the other tools (and even in those cases where they can there are always >limitations). Nobody wants to waste time learning the quirks of every >possible VCS client. The reality is, if you're going to interact with lots of upstreams, you pretty much have to know svn, cvs, git, bzr, and hg -- or at least be proficient enough to do the basics. -Barry
signature.asc
Description: PGP signature
