Steve Raeburn wrote:
Bottom line is that this is the way Apache works and it's not going to
change.
Of course not.
Especially when, even when your practices fail, you can convince people
like the Webwork guys to give you code and mask your failure.
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.
I think it's much harder to become active in Struts than other open
source projects. Struts has also fallen further and further behind
technically in its space. (This has what has led to the Webwork merger
so that the "Struts umbrella" could offer something reasonably up-to-date.)
There is not absolute proof that there is causality between the above 2
things, the difficulty in getting involved, and the technical
stagnation, but I strongly suspect there is.
In any case, it is not a subject of legitimate debate at this point that
progress on the Struts framework stagnated. If you guys were doing
everything right, then what is your explanation for that?
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
FreeMarker group blog, http://freemarker.blogspot.com/
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]
