On Mon, Sep 08, 2008 at 11:13:20AM -0700, Darren Reed wrote: > Each of the above tools solves a particular set of problems but > none of them is the perfect universal DVCS and none of the > alternatives seem to fit well into the netbsd way of life. > > So while lots of smart and intelligent people may have worked on > this problem, I'm willing to bet that none of them have come up with > a design/product that was built from the ground up to serve this > project. I've seen this kind of statement (in one form or another) a number of times. While it's undoubtedly true in a factual sense, it contains a huge assumption and dangerous fallacy, in two parts. That must be corrected if we're to get a good result out of all this. Part 1 is the assumption that there is inherently something right and good about every current aspect of 'the NetBSD way'. We need to make the distinction between concrete practices and the project objectives and philosophies behind them. Current NetBSD practices have clearly evolved and been shaped very strongly around the limitations and specific characteristics of CVS. Some of these practices are a good way of doing a good thing, with the tools we have. Other practices are more in the style of workarounds for limitations of the tool; somewhat awkward or difficult ways of doing a good thing, that we have become accustomed to and perhaps no longer recognise as so awkward. So far so good, nothing controversial here; evaluation of new tools can proceed with an assessment of how we do one or another action in the new tool, and what its features offer by way of improvement for some of the more unpleasant practices required with CVS. We look at and translate the practices and maintain the underlying objectives and philosophies. What is not so clear is that some of the objectives and philosophies of 'the NetBSD way' are also shaped very strongly around assumptions and practices derived from the tools. It's unavoidable, with such a long project history, that traditions and practices have become more entrenched than they perhaps deserve. At the very least, I expect that for most developers, it will take several iterations of making a notional list of practices vs underlying objectives and philosophies, before things are really sorted into the right columns. Only then can we really undertake the kind of new tool assessment described above. But even then, it's my belief and hope that we should go further, that we should examine and assess critically things in both columns. That requires paring back to really essential objectives and philosophies, with a few more iterations from the above to restate things as truly core values. That might get us a more concrete description of what 'the NetBSD way' is currently, and that would be a worthwhile exercise regardless. Some of those things would be worth reconsidering as to whether we want to keep them going forward, and/or whether we want to introduce anything fundamentally new, regardless of tools. The best thing about all the activity in this space recently, and the broad crop of new tools that have resulted, is the opportunity not just to do things differently and better, but to do very different and better things as software developers. The DVCS tools, and the philosophical comparisons between them, are good starting examples for those beginning to get their heads around this opportunity, just because they have such clear differences from CVS, but it is really worth looking at from a perspective aside from any particular tool. I have lots of examples in mind, but I don't want this post to get any longer, and I don't want to distract from the core conceptual point by starting arguments (or even productive discussion) about one or another example. I also (clearly) have some views on the different philosophies enabled and embodied by some of the various new tools. I'll leave both for later follow-up. The good news is that the best practical way to start down this assessment is to start playing with the various tools, keeping in mind the broader objective and looking all the time at what the comparisons and characteristics of each teach you about what it is you want to do with them. You will no doubt find your philosophies being shaped by whichever new tool you pick up first, but be aware of that in the process and it will teach you more than the tool. > Thus I think we, and the open source community, could be > well served if someone or some people sat down to design and write > such a tool that did do what we wanted. And this is Part 2 of the fallacy, even leaving aside the assumption that we know what we *really* want in the sense of the above. Such a tool would probably not be sustainable. Either our requirements are close enough that the differences are valuable information to steer the evolution of the existing tools to better support them (and well-stated and well-reasoned requirements from larger software projects are invaluable to vcs developers). or they are so alien and different that the tool we would have to develop would be useless to anyone else. I don't think the latter is the case at all, though I'm certain there's room to build on some of the current tools as a base. -- Dan.
Attachment:
pgpdRp4g_Q4Mq.pgp
Description: PGP signature