Am 19.06.2006 um 23:30 schrieb Vlad Seryakov:
Stephen,
I understand you have the "right" vision how to do things but after
long
period of time just removing Tcl API functions (cache set/get) is not
very polite.
It breaks a lot of Tcl code and i am not sure why do you think they
are
racey and i need to emulate them in Tcl instead of C.
Very frustrating.
I might add couple of words to the above...
Normally, the CVS HEAD is not meant to be used for any production work.
Having said that, I must admit that we do exactly the opposite, i.e.
we take the HEAD and splice it into our product, as-is. This is not a
very good idea as this places extreme (stability) burden for new
developments and things to try out. So I guess we should be doing
tags/minor releases or whatever more frequently. This way we can leave
the HEAD volatile and stick to last known workable state.
A "positive" side effect of using HEAD for production is that we get
much
better "testing" but this is also not very good, i.e. to test the code
on the customer sites... Therefore the test-suite should be more
elaborate
and we are adding more and more there, so I believe this is the right
way
to go.
Over the time I tried to maintain RFE->Discussion->Implementation
path where one would first inform everybody about what one is going to
do, and why (the RFE), then go see if there are any voices against or
if there are some better ideas, especially if the existing API is being
changed (the Discussion) and finally go implement what is agreed upon
(the Implementation).
Now, I understand that this is a kind of buerocracy but it really
*helps* resolve
such issues. In later time I could observe that we all neglected the
RFE/Discussion
part (myself included) which then obviously leads to collisions. So I
would suggest
that we take the RFE's seriously and start to work on some
implementation when we
all come to some reasonable consensus. This will save lots of our
time and efforts.
The *last* thing I would like to do is to discourage people adding
new things and
ideas to the code by placing excessive organizational burden to it!
OTOH, adding an RFE allows for others to adjust and comment before
the code
gets comminted and maintained which will be helpful on the mid/long
term.
So, afer all this prose, lets see how we will proceed in this
particular case...
I have no problem in changing our code to adopt to new (better) API.
I might have
problems if I will have to do that every now and then OR if the API
does less than
we're used to w/o offering acceptable workarounds.
Cheers,
Zoran
