[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why the split for rcvs?

From: Noel L Yap
Subject: Re: Why the split for rcvs?
Date: Mon, 26 Mar 2001 11:25:54 -0400

address@hidden on 2001.03.24 14:18:20
>I am watching the thread of "split for rcvs" and "locking and other patches"
>and I must say that I am quite shocked.
>Why is that the requirements for sending the patches are getting more hard
>every day?

I think these preconditions have existed for a long time now.

>The conditions to accept the patches are quite too difficult to comply with
>and simply designed to discourage the people from sending those ("I'm number
>1 so why try harder" attitude?).

In a way, I agree with your statement.  OTOH, I can see where the CVS
maintainers are coming from.  I wish there was some middle ground, but I think
it would have to be gotten on a case-by-case basis.

>As a developer I would not expect that the users of my software would send
>me a complete, fully tested and documented patch or bug fix. I don't even
>want it - I know my software much better and I will certainly modify the
>patch before applying. I will write the documentation myself, based on the
>plain email description and my understanding of the system, I will make
>corrections to the sent code etc. The effect will be better than pushing the
>poor guy to write it himself or to make him exercise his skills in the areas
>he is not familiar with.

Again, I wish there was some volunteer that I can communicate with that'll
achieve the goals.  That's not the case here and I think no amount of
complaining will change that.

>I would also apply patch to the branch first, so people can try it and test
>as an "experimental" version. That allows the patch to get mature and gives
>some "battlefield-test" - always a good thing to do. When the thing is
>ready - merge it to the trunk.
>Now, back to the particular case of Noel's patches - why don't he gets the
>write access to the repo? He did show the commitment and surprising patience
>with those patches.

I appreciate the vote of confidence, but really, I'm not worthy (especially
since I'm not really using CVS now and, therefore, won't even be using my own

>Or, why his patches are not put on the branch so people can check out the
>code and build themself?
>BTW: CVS code itself seems to have a surprisingly small number of
>I don't understand why he has to re-do the patches against latest
>development version - surely you should put it on the branch that was crated
>for each release and merge with the trunk, no?

This is completely my fault.  The patches I've submitted are not modular,
meaning that you may have to install more than what you had really wanted.  This
is why I'm trying to redo the patches.

>As you can see, at least the "edit -c" patch was applied, people are using
>it for quite a while now with good results. Please note that there is no
>more admin locking - so CVS server on Windows NT is fully concurent, with
>professional solution for locking by means of Noel's patch. It seems that
>Noel is not even aware of that - and that is how it is supposed to be! He
>submits the patch and developers are picking it up and applying, testing,
>accepting or rejecting. It should not be ignored, and there should not be
>the patches "floating around" making a users chase them everywhere. Patches
>should be with the main code, that is where people shuld search and find
>Dear CVS developers, please give Noel a chance and better CVS to us all...

It's great that others are able to use my patches.  I think if I improve their
delivery, even more can enjoy them.


This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]