Dan Sandberg <[EMAIL PROTECTED]> wrote:
> I think Pier's conerns are quite reasonable.
Thank you, and coming from the interested party, that shows me we are in
agreement... :) :) :)
> Let me bring up a few points that I think are central to the debate:
I'm following...
> A. Security. This is the most important concern in allowing new
> commiters. If they purposely or accidently introduce security issues,
> this tarnishes the Tomcat name. Code review is the most important way
> of preventing this. How much does asking someone else to commit the code
> for you force them to look over it for bugs of this kind? How much
> would other people look over CVS submissions that were done directly by
> a new commiter? The ratio between these numbers is critical. If it is
> 1, then there is no harm in giving commit access easily.
I personally review every CVS commit that concerns me. For example, I don't
review commits to TC3.x because I don't use it, or to mod_jk, because I
don't understand it... I try to help out when I can on those source bases,
but I can't really do much on those trees...
I consider myself a committer of jakarta-tomcat-connectors/webapp (very
restricted scope) but I do have the ability to screw up other code as well
:) And of course, I try to participate to my best to the overall Tomcat 4.x
evolution (but time's limited nowadays).
> B. Introducing bugs. This is a concern much like A., but because the
> SSI code had glaring bugs to begin with, I don't think it is much of an
> issue in my case. If a new contributor has commit access, it makes it
> easier for her to fix any bugs they introduce, and presumably they would
> because of the pride-factor.
Most of the bugs (IMO) are introduced by veterans (such as me), because we
get stuck usually on something and we tend not to look at the wider picture,
coming from the outside, it's easier for you to see my fuckups, for
instance, because you see the code still as "a whole"...
> C. Commiter may not stay long. In my case, I explicitly said that I
> didn't want to be a commiter originally. I didn't want to spend lots of
> time on this project. As things turned out, my 3 hour change turned
> into a 3 day change, and it has become obvious to me that a few more
> commits will probably be necessary. I asked for commit access because
> 1) I want to take the load of others and 2) The latency of waiting for
> others to review/commit the code is fairly high. Nevertheless, I'll say
> this explicitly: I don't want to become a 'major' contributor to Tomcat.
> Act accoringly.
Just one question on this. Being a committer implies that you're going to
have the right (and the due, of course, like in any good democracy) to (for
example) elect PMC members, have -also- a some sort of responsibility over
what you do, and what others do, meaning code reviews, deciding on the
future of the whole tomcat project, voting on future release plans and
such... As I said, this is not only a right, but also a responsibility. As a
committer you _should_ be doing that.
Now, my question is, do you want _at_this_point_ to have that
responsibility? Are you interested? I don't want to sound bad, but hey
everything comes at a price :) :) :)
(I just want to show how committing to a particular codebase, sometimes,
might be different from "the whole kit'n'kaboodle that being a committer
involves")...
> D.Scope. Must a commiter have scope to the entire project? Can't the
> access file be changed only in the o.a.c.ssi directory and the servlet
> directory? Would this address any concerns?
Technically it would be "feasible" to implement that feature, but
administrivia would become utterly complex.
Thank you _very_much_ for taking part to all of this :) :) :)
Pier
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
