Jonathan Revusky wrote: > First of all, pPeople seem to be addressing things I never said. For > example, I don't think I ever said that people should be allowed to > commit _anonymously_. I simply said that I believed you could > be quite > liberal about granting commit privileges to people and the > sky would not > fall in. > > Now, here you seem to be suggesting that I see no need for > code review > on new code that is committed. > > No, I certainly don't believe that. Of course, code that is committed > should be reviewed carefully. However, I don't know if this is such a > problem as regards this kind of situation. If you imagine a > situationin > which a new guy is given commit access, I think it's totally > normal that > the established developers will be quite carefully reviewing > the things > this guy does. > > So basically, I don't think your above point 3 is such an objection.
I never said that the sky would fall in. I just said that committing code from a wide range of producers prior to review by a small group of people deeply immersed in the project would reduce the trust in the project. You may have no objection to this, but you cannot make that decision for others. There are many companies using Struts for far more important things than simple websites. I believe that many of these companies would be unwilling to trust Struts for these uses if the project were to greatly open up the commit privileges. > Also, there is a countervailing point here: in terms of subtle errors > and so on, simply getting more people involved may well reduce the > number of such subtle errors for the basic principle of more > eyeballs. > So this works both ways. Effectiveness of code review depends on the depth of that code review, not merely the number of people who have reviewed it. While broad review, which any open-source project may have, can bring a benefit in reducing errors, I have generally found it better for catching coding errors than design errors. In many cases, it weakens the review because it dilutes the sense of responsibility. > > Consider the C2 Wiki and Wikipedia as analogies. Yes, it's easy to > > delete obviously false information. It's just as easy to > reintroduce > > it. Keeping the worst of the cruft out is pretty much a > full-time job > > for volunteers who take on the task, and there's not even agreement > > between them which is the cruft. Subtle or infrequently viewed > > incorrect information can, and does, remain for long > periods of time. > > Spectacular failures occur that make headlines in the mass > news media. > > Just to be clear: are you speculating in the above, or are > you speaking > from direct experience maintaining such resources? I was using this as an example, and don't wish to debate the question of open Wikis. For the record, I have given up on maintaining the C2 Wiki (after many years of contributing) because the cruft is added faster than it can be cleaned, and it's no longer worth my time to work on it. I rarely refer to it for reference, either, for the same reason. > > I, for one, would never recommend to any business > enterprise that they > > use Struts for important applications if the source was not > vetted and > > controlled by a small, trusted committee. Your needs may not have > > such requirements for trustworthiness. > > Do you have objective proof that Struts is more "trustworthy" -- i.e. > lack of subtle security holes and so on -- than other > comparable projects? You have an objective measurement of trustworthiness? I thought that trust was a human (or perhaps animate) value. > George, I'm rather unconvinced by your arguments. That's OK with me. I'm rather unconvinced by your arguments. I'm just stating the case that, as it is, Struts is rather widely trusted for enterprise systems. I believe that much of that trust is due to the empirical track record of the small team controlling changes to the code. I believe that much of that trust by those businesses would be lost were this model of control to be radically altered. > But I reiterate: the idea that a more open collaborative > model is going > to produce software with more bugs or more security holes is an > empirical question that cannot be resolved by a priori reasoning. I'm not saying that it would have more bugs. I'm saying it would be less trusted. It's harder for me to trust a large group than a small one. > But to summarize: the basic idea that you need to closely guard commit > privileges should not be a dogma. It is a hypothesis that should stand > and fall based on empirical evidence. All I see here is people arguing > that this is a bad idea based on a priori reasoning. Has anybody jumped > up and said something like: "Oh, we tried that and it was a disaster. > This happened and the other thing happened and we had to revert to a > less open approach." > > With my kind of empirical mind-set, this is the kind of thing more > likely to convince me I'm wrong, or at least cause me to doubt. I think you're mis-reading the discussion. I don't hear any dogma here. I hear the Struts team saying, "We don't want to do that." They're perfectly willing to let you run a project with whatever commit criteria you want. They're even willing to let you start with their code base. Knock yourself out. Personally, as a Struts user, I'm pretty comfortable with the project, as is. On a take-it-or-leave-it basis, I'll take it. What I see is people arguing that they're wrong for feeling that way. I hear people saying that the Struts team should change their behavior and that we will know, empirically and in the future, if it was a good or bad change. And I don't blame them for dismissing those arguments. There is an infinite number of ways to run a project. There is no "one best way." Empirical evidence shows that the Apache way has been successful by a number of measurements. It might not be the way that I would run a project or that you would run a project, but neither of us has any right to tell them it's the wrong way. Oh, we can tell them, but they have no obligation to listen. Therefore, if you want to influence the way they run the project, you need to present that influence in ways in which it may be more likely to be favorably received. Empirical evidence shows that saying "you're doing it wrong" is not a terribly effective way of influencing someone. Your mileage may vary. - George Dinwiddie http://www.idiacomputing.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
