Frank W. Zammetti wrote:
Welcome Jonathan! Better late than never :)
Jonathan Revusky wrote:
I think here we have to agree to disagree. I see there being a
responsibility involved that you don't. It isn't like anyone can
just come along and contribute, contrary to what we might want people
to believe, because there is a barrier to entry, namely those already
involved. AND THAT IS FINE. In fact, it *has* to be that way
because the alternative is just opening up commit privileges to SVN
to anyone and everyone, and clearly *that* isn't a good idea :)
You say this as if it is the most obvious thing in the world. But is
it? I am quite skeptical. You take as a given that commit privileges
have to be closely guarded, like a high priesthood guards the inner
sanctum.
Yes, I do think it has to be guarded. I can think of two good reasons:
outright malice and bad code.
I think outright malice is quite rare. In fact, so rare as to be almost
a non-problem. Have you actually run across this?
As for bad code, this is more likely. However, bad code that actually
does something can be refactored into something better. At least it's a
starting point. If it's so bad that nothing of value can be salvaged,
you can always just roll it back.
I mean, this is a basic difference between software and other fields. If
you just let anybody work on a construction project, and people did bad
work, well, it can range from difficult to impossible to revert to the
original state that the project was in before that work was done. In
software, you have something completely malleable, and you can always
just revert to some known state of the code at a given point in time.
So how much damage can anybody really do?
I am inclined to believe there are some people who would actively try to
corrupt the code in some way simply because they have an axe to grind
with the project.
Well, we should be empirical about this. If we're trading notes about
how to run open source projects, it should be based on actual
experiences, not just idly speculating on what could happen, right? How
many cases of outright malice have you run into?
This could be very subtle, maybe introducing pieces
of license-incompatible code. I don't imagine this would be
wide-spread, I think the majority of people would behave themselves just
fine, but to ignore the bad parts of human nature would be folly, and I
think given the opportunity to add anything they wanted, the bad part
would surface at some point.
There could also be innocent mistakes made, like committing things that
you think are license-compatible that really aren't. This could happen
at any time obviously, but if you guard the commit rights, my hope is
that you only grant the rights to people you believe understand how to
avoid these mistakes more times than not.
Well, I have to admit that I was thinking in terms of being pretty open
about letting people commit code to the repository, but I meant *their*
code. I don't think the problem of somebody saying: "Hey, I wrote these
classes that do X over the weekend." and it not being true, that they
actually plagiarized them from somewhere else, that this is very
frequent. But again, this would be a case of bad faith that one would
class along with the malice issue, right?
And again, I don't think bad faith or malice on the part of people is
that common a problem.
Also, I think there has to be some check on the quality of the code
coming in. Especially when your talking about something like Struts
that a lot of people base big, important projects on, I don't think it
would be wise to let any Java beginner commit code without it being
scrutinized.
I never said that the code people commit should not be scrutinized! Most
certainly it should be.
There are better places to "get your legs" than something
like Struts. And plus, it is important to me at least that any
committer on any project have a basic understanding of the overall code
base, not just a small part to be sure the committed code fits with the
overall code base.
Well, you can always review what they did. Your comments almost would
lead a casual observer to think that you are unaware that any changes
people make can be backed out. And quite easily.
I am not talking about an individual who makes a
targeted contribution here or there, I'm talking about a permanent
committer who can commit whatever they want at any time (subject to veto
by other committers).
There is a third reason too actually: does the code at least somewhat
jive with where the project is going? This was part of the debate all
along... there has to be a balance between being open-minded and
accepting new ideas, and just accepting anything that comes along. A
good example is the SetupItems contribution I offered last year. While
it doesn't represent a major paradigm shift or anything like that, the
fact is that with Struts 1.3 in the pipeline, and chain being arguably a
better solution to the same problem, it was, I feel, reasonable to say
that the contribution maybe shouldn't have come in. I thought it was a
good contribution, I in fact know a fair number of people took it and
incorporated it on their own, but it was kind of superfluous with the
chain refactoring coming, and so in a sense didn't jive with where
Struts was going.
What is the basis for really believing this? The idea, AFAICS (you can
clarify) is that if you let "anyone and everyone" commit code, they
will commit all kinds of low-quality stuff willy-nilly.
Yes, I believe this is part of the risk.
Frank, I do not know all the answers, but here is what I suspect. If you
just give commit access to anybody who asks for it -- as revolutionary
an idea as that may sound to you -- most likely the sky will *not* fall in.
That the person who wants the commit access actually does malicious
things -- I suspect this will just about never happen. That, when you
review some of the code, you have objections to it, this can happen, but
is not the end of the world.
You have the pros and the cons. Lowering the barrier to entry has the
pros that you have a much better chance of getting fresh blood in the
project. Keeping barriers high leads to what we observe around here.
I suspect the latter is the greater danger.
> My own experience
running open-source projects has been that the vast majority of times
that you give somebody commit rights to the code repository, they
simply do nothing -- good or bad.
In fact, my own experience would echo that. But I'm not sure that says
giving commit privileges is inherently safe...
Crossing the street is not inherently safe. OTOH, that, when crossing
the street some homicidal maniac decides to run you over just for the
hell of it -- this could happen, but quite rarely.
I say the malice thing is just not going to happen that much. Consider
this. Despite your being a wonderful guy (I'm sure) somebody has a
grudge against you. Is that person going to: (i) do nothing, 'cause he's
got a life (ii) get on your mailing list and write an email entitled
"Frank is an asshole" or (iii) dissimulate his grudge against you,
pretend he's on your side and ask for CVS access all nice and then do
malicious things.
I conjecture that (i) is 100 times more likely than (ii) which is in
turn 100 times more likely than (iii)
What do you think?
maybe it just says people
tend to get a little gun-shy when they are given extra power :)
> When they do something, they are typically
quite conservative initially since they are aware that they are new
kids on the block and the others are watching closely.
I agree, that is generally true. But would it be a good idea to open up
the repository to just *anyone*?
Well, this is an empirical question. I have stated publicly that our
policy with FreeMarker is basically to give commit access to anybody who
asks for it. (YOu may note that there aren't that many developers on our
project, which would seem to contradict this, but the thing is that I
tend to remove people who, after a 6 months or more, haven't done
anything, simply because I think the list should reflect people who
actually have done something.
That's what I was talking about.
Certainly some people wouldn't be conservative at first, they would jump
right in, and without some sort of vetting process you can't be sure
what will get in. Sure, you could always back it out if you had to, but
that seems like cleaning up a nuclear meltdown rather than having safety
regulations before-hand to avoid it in the first place :) (Sorry, just
watched The West Wing)
I do not seriously see how restoring the code repository to some known
state in the past is comparable to cleaning up a nuclear meltdown.
But it's an empirical question anyway, subject to an empirical test.
Give commit privileges to anybody who wants them and see if the sky
falls in. My conjecture is that it won't.
BTW, as regards the overall topic of discussion, I don't know whether
JSF will be the next big thing or not. I have not the foggiest idea.
OTOH, I do have an opinion about the Action/Shale cohabitation. My
opinion, looking at the Struts community and website and the rest with
newbie eyes is that this is disastrous. I think that any project has
to have some coherent message and a person who visits your website and
starts looking at the mail archive and so on has to be able to figure
out quite quickly "WTF is struts" and to have such an incoherent
message due to this Action/Shale bifurcation seems very negative. It
just seems complicated and confused.
I think it is fair to say you are not alone in that opinion. What can
be done about it, other than voicing the concern, I don't know. And
heck, those that hold that opinion *could* be wrong.
Yes, that is always a possibility. But somehow I doubt it.
Besides, it's unlikely. The last time I was wrong about something was in
the late 1980's. :-)
Well, to put it another way, if I were assigned the task of evaluating
different things in this space, and Struts was one of them, it is very
unlikely that I would settle on it. I would almost certainly end up
opting for a non-schizophrenic alternative.
I don't know how other people see things. This is just my honest
reaction. I have no vested interest in this.
I think it is fair to say that some people see no problem, others see a
potentially big problem. Aside from that, I'm not sure any conclusion
can be drawn :)
Well, that's not true, Frank. A conclusion can be drawn since it's an
empirically resolvable question. You can replicate (roughly) the same
experiment enough times to draw a pretty definitive conclusion. I don't
say my own experience is enough to be definitive. But so far, my
experience suggests that the fears you express about letting people
commit code are not very well founded. In particular, the malice issue
is pretty much an ersatz problem, I think. Also, that people start
committing oodles of low quality code all of a sudden doesn't seem to
happen either.
Jonathan Revusky
--
lead developer, FreeMarker project http://freemarker.org/
FreeMarker group blog, http://freemarker.blogspot.com/
Regards,
Jonathan Revusky
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
