Serge Knystautas wrote:
On 2/27/06, Jonathan Revusky <[EMAIL PROTECTED]> wrote:
Let's suppose that, contrary to fact, the release you mention had a
corresponding CVS tag. Do you think that the people (if there really are
any) relying on DVSL would be in a _significantly_ better position?
Yes. Think of this like insurance.
Not having a tag in this instance is not like not having insurance. It's
more like you have taken out insurance (you have a code repository after
all) but you have bad filing procedures, so that when you need a copy of
the insurance policy, you have to tear your office apart to find it.
(Though you eventually do find it.)
The point I'm making though is not over whether it's good to have good
process. Of course it's better not to be sloppy about these things.
The point I'm making has to do with something that everybody with a
grain of common sense knows or at least intuits: there are first-order
and second-order problems and if you don't address the first-order
problems, the second-order ones are basically irrelevant.
As an example, let's say that, on a doctor's visit, I am informed of 2
things.
1. I have an advanced cancer that is usually terminal. Certainly,
without aggressive treatment, I will be dead in a matter of months.
2. I have high cholesterol.
Let's suppose my physician concentrates on the second problem and
ignores the first one. He spends the entire visit outlining a low fat
diet that I should follow.
This doesn't make any sense, right? If I'm not going to get any
treatment for the cancer, I may as well eat all the fatty foods I feel
like in the limited time I have remaining, right? The more generalized
point is that the the presence of the first-order problem of the
advanced cancer basically renders the second-order problem, the
cholesterol, irrelevant.
Similarly, a business that has no customers, because they do not have a
product or service anybody wants to buy, has a first order problem. They
may also have some issues with somewhat sloppy accounting procedures.
However, even introducing the best accounting procedures will not
resolve their first order problem. Similarly to the doctor in the
previous case, a business consultant who is obsessed with correct
accounting procedures might only concentrate on that, and not even
mention the first-order problem, which is that nobody is buying the
company's products. And that problem will inevitably lead to bankruptcy
irrespectively of how good the company's accounting procedures are.
This whole DVSL situation suffers from a major A-1-A first order problem
and that is its complete abandonment in a totally half-baked state. (Did
anybody miss the fact that Geir dodged Robert Koberg's question about
namespaces? AFAICS, DVSL simply punts on namespaces. I guess Geir was
reluctant to answer that question forthrightly since it reflects
terribly on the thing.)
Well, it's not just that DVSL is unmaintained and unsupported, it's that
there is a lack of clarity there about this. If you really do want to
encourage somebody to pick up the project and do something with it,
maybe the web page should say something like: "Hi, I'm an abandoned
project looking to be adopted. If you are interested, here is what
should you do." However, the main DVSL page does not forthrightly
disclose the state of the project, but rather, even suggests to the
reader that there is some active development going on. That strikes me
as quite problematic.
You are correct to reason that it
is *much* better to be healthy or to not crash your car. And I agree
with you that most people do believe that the ASF projects don't crash
their cars as often as SF projects.
But when they crash, that insurance of a CVS tag was pretty darn
useful and puts you well ahead of the person without the insurance...
I would dispute the "well ahead" part. With a completely unmaintained
abandoned product, if there is nobody to whom I can even to ask any
questions about the code, it is not typically going to be very practical
to do much with it. It would make much more sense just to opt for some
actively maintained and supported alternative.
Now, for example, in the case of FreeMarker, anybody can include a
freemarker.jar file with their product if they want. They may or may not
be clear about which version this is; we have no control over that.
However, we do have a disposition now where there is a main() method you
can run from the command-line like:
java -jar freemarker.jar
and it outputs the version of the library. If it tells you that this is
version 2.2.3, say, you could go download that off sourceforge. And then
you'll have the exact source corresponding to that .jar. (Unless this is
a kind of "rogue" .jar file that somebody put up with some of their own
custom changes, and, though not likely, that's within the range of the
possible, but again, we don't really have control over this...) And yes,
we also have a tag in CVS corresponding to the release.
But actually, my own willingness to answer questions and have dialogue
about the FreeMarker 2.2.x code would be fairly limited. (We're about to
release version 2.3.5 BTW.) I would pretty much encourage anybody to
grab the latest code and we could continue a dialogue from there.
But really, surely you see that being an abandoned project with some
extra CVS tags is not going to be a great improvement. It's like being
somebody in the last stages of a terminal cancer who has a very good
blood cholesterol level. It's really a big "so what!"
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
blog http://freemarker.blogspot.com/
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
