Dave Newton wrote:
Jonathan Revusky wrote:
I already am spending too much time on this [...]
Agreed.
2. I know that there is significant animosity towards me here [...]
My animosity towards you is from years ago, actually;
I remember that vaguely, yes. Still feeling animosity over that, eh?
You think I wronged you in some way then, I guess. What precisely is
your grievance, Dave? I guess I could go look it up. I have no
recollection of having wronged you in any specific way.
But anyway, you brought it up. What precisely is your grievance against
me from back when? I'm curious, and actually, I would imagine that other
people reading this are mildly curious too.
I won't speak for
anybody else.
Well, you seem to have learned your lesson on that then. :-)
From whence???? From whence???? Is the Shakespearean festival nigh?
Ooo! A zinger! Forsooth!
It's just mind-boggling to be trying to answer this kind of question
really....
I imagine that it is, for you... trying to imagine how an open-source
project that was developed for somebody else's use might not be
obligated to listen to anybody else.
Well, maybe not. But if that is the case it would also seem to mean that
all this stuff about "building community" that Ted Husted keeps pointing
to is a bunch of empty posturing.
It appears as though you believe that if someone is willing and able to
pitch in that they should have commit rights, which is not really the
same thing.
As a practical matter, it basically means giving people commit rights.
Trying to let people work on stuff while keeping them at arm's length
just is unlikely to work for long. If you're going to let someone do
some work, yeah, you have to open the door and let them in.
I really don't believe we're so far apart on this: I think the bar for
commiting to Struts is too high as well. At the same time, I would
definitely _not_ give commit rights to anybody that asked for them, and
the project would be better off for it.
How do you know for sure? Has this hypothesis ever been tested?
Even in the limited scope of this mailing list I have seen some pretty
frightening code--I would _not_ want the authors of said code to be able
to inject similar code into the project, and I would _not_ want to have
to surf the repository regularly to remove or fix it.
You don't have to regularly "surf" the repository. There is a
disposition that all these projects use where people on the dev list get
email notifications of commits. If you are a more established team
member person who has kind of "taken ownership" of a certain part of the
code and some new kid on the block commits some change there, you would
tend to review it carefully.
There is no need to be continually surfing the repository on a regular
basis to check for whether bad code was committed meanwhile. You get
these commit notifications and you can look through them.
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
At the moment, I think it is mostly because this whole dysfunctional
scene exerts a morbid fascination on me. It's actually funny in a very
dark humor sort of way, you know.
On this we are in perfect agreement :)
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
