Bottom line is that this is the way Apache works and it's not going to
change.
I guess you *could* continue to argue that this method has been a
failure for both Struts and Apache (and most other significant open
source projects), but I think the evidence suggests otherwise.
Steve
Jonathan Revusky wrote:
Steve Raeburn wrote:
I have an idea. Why don't we publish the source code to Struts so
that absolutely anyone can contribute to the project. You are right
that we'll need a review process for all those contributions. So why
don't we require all incoming code to be reviewed by at least one
experienced developer before it is added to the code base. After a
while, developers will earn a level of trust and we can relax the
review requirement to only happen after the code is updated.
The problem with that proposal is that it sounds like your current
practice. The current practice has already been tested and not
produced good results. You have fallen further and further behind
other competing projects and that is why it became necessary to bring
in Webwork (heretofore a competitor) so that you could have something
reasonably up-to-date to offer people.
To continue with the same practices and expect radically different
results does not seem rational. It is encouraging that you seem to see
that there is a problem and are making a proposal. However, I think
your proposal would have to actually involve a change of some sort.
The one I suggested was drastically lowering the barriers to letting
people directly commit code to the repository. To many people, this
sounds very radical. People have suggested that this would lead to all
kinds of problems. However, that can be put to an empirical test.
Given the failure of your current policies, it is not as if you have
so much to lose.
Thanks for the advice. We should implement this new process right away.
Tell me, does the same old wine in a new bottle taste any different?
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
FreeMarker group blog, http://freemarker.blogspot.com/
Steve
Jonathan Revusky wrote:
Dave Newton wrote:
Dakota Jack wrote:
I flat don't believe this. Who, what, where, when, etc?
This isn't me (although I did fix an essentially identical bug in an
internal webapp at Morgan Stanley (who), an Action instance variable
(what), in Morristown (where), spring 2004 (when), because they
paid me
(why), by putting the data into a synchronized map (how) although I
believe eventually they changed the structure of the app to eliminate
the need for that (it was a quick fix for an emergency problem: "this
works almost all the time, but under load we occasionally get
corrupted
data"-a-thon).
http://www.thedailywtf.com/
Today's is "the cost of static."
I just visited the above link and read the article and I don't see
how this can be presented as evidence against a more open
collaborative model. Basically it's the story of a bug. Somebody
made a mistake. People will make mistakes regardless. Also, the bug
occurred, as far as I can see, in a closed source commercial
codebase, so it's not clear to me how this is relevant at all.
I have said repeatedly at this point that I assume that code
committed by newbie committers would be reviewed. In principle, a
bug like the one described in that article would be caught at that
point. But another point about this is that having more people in
the code could decrease the mean life expectancy of such bugs
because of the phenomenon of more eyeballs.
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
Anybody who thinks anyone should have commit access... feel free to
walk
around tdwtf, marvel, and pat yourself on the back for being better
than
some of the stories there (I hope :)
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
