I agree overall, RFE would help especially in case of large API/internal
changes so everybody would be prepared of what to expect. On the other
hand, as we talked a year ago, whoever introduces a feature and nobody
object in the reasonable time(i remember we agreed on 1 week) feature
remains in the code until something new/better comes up but that will
need discussion why to remove it because somebody may use it already
once introduced. We all added a lot of things that everyone of us need
and that was one of the reasons of this fork, we needed features and we
added them.
As for CVS HEAD using in the production, i am comfortable with it and
that is the reason i am adding new things, i have it running on
pre-production first, and once the feature stable and working it moves
to production, because i needed it in the production in the first place
so i added it.
Of course it does not excuse bad decisions which happen from time to
time but we have mailing list or RFE or CVS to keep the architecture and
structure sane.
Zoran Vasiljevic wrote:
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
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
--
Vlad Seryakov
571 262-8608 office
[EMAIL PROTECTED]
http://www.crystalballinc.com/vlad/
