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.
