From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 26 Dec 2008 23:40:57 -0800 From: Roman Shaposhnik In-reply-to: <2a6f6b679d06acf2c280c4887d231330@quanstro.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-id: MIME-version: 1.0 Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <2a6f6b679d06acf2c280c4887d231330@quanstro.net> Subject: Re: [9fans] Changelogs & Patches? Topicbox-Message-UUID: 71d95bd6-ead4-11e9-9d60-3106f5b1d025 On Dec 25, 2008, at 6:37 AM, erik quanstrom wrote: >> > despite the season, and typical attitudes, i don't think that > development practices are a spiritual or moral decision. > they are a practical one. Absolutely! Agreed 100%. My original question was not at all aimed at "saving" Plan9 development practices from the fiery inferno. Far from it. I simply wanted to figure out whether the things that really help me follow the development of other open source projects are available under Plan9. It is ok for them to be different (e.g. not based on traditional SCMs) and it is even ok for them not to be available at all. > and what they have done at the labs appears to be working to me. It surely does work in a sense that Plan9 is very much alive and kicking. But there are also some things that make following Plan9 development and doing software archeology more difficult that, lets say, plan9port. It very well may be just my own ignorance (in which case, please educate me on these subjects) but my current impression is that sources.cs.bell-labs.com is the de-facto SCM for Plan9. In fact, it is the only way to get new source into the official tree, yet still have some ability to track the old stuff via main/archive. This model, however well suited for the closely-knitted inner circle of developers, makes it difficult for me to follow the project. Why? Well, here's my top reason: Plan9 development history is not "quantized" in atomic changesets, but rather in 24hour periods. Even if a developer wanted to record the fact that a particular state of the tree corresponds to a bug fix or a feature implementation the only way to do that would be not to allow any other changes in within the 24h window. This seem rather awkward. Two less severe problems are the lack of easy tracking of change ownership and code migration through time and space. Both are quite important when one tries to figure out how (and why!) did we get from /n/sourcesdump/2002/* to /n/sourcesdump/2008/* > in my own experience, i've found scum always to cost time. > but my big objection is the automatic merge. automatic merges > make it way to easy to merge bad code without reviewing the diffs. > > while a descriptive history is good, it takes a lot of extra work > to generate. just because it's part of the scum process doesn't > make it free. Agreed. As much as there's price to pay when one tries to write clean code, there's a price to pay when one tries to maintain a clean history(*). In both cases, however, I, personally, would gladly pay that price. Otherwise I simply risk insanity if the project gets over a couple thousand lines of code or a more than a year old. Thanks, Roman. (*) My definition of a clean history is a set of smallest self-reliant changesets.