We are constantly told "make a proposal", "put it up in the Wiki" or "open a ticket with your suggestions", but the problem with that is that we are spending a lot of time doing things that can be rejected out-of-hand for any reason by any members of the PMC.
Also, we don't know what you guys are cooking up many times, as evidenced by the addition (I believe it was Martin) made a night or two ago that was along the lines of what I had done but for the 1.3 branch... it seems like my work prompted him to do something similar, and because he could simply do it and add it without any discussion, he "beats me to the punch", in essence. Plus, this was without any discussion that I saw (I apologize if I missed it) on the public lists. How is someone like me or Jack that wants to get involved supposed to do so under those conditions? Why would we *ever* put the time in without knowing (a) whether it will be accepted or not and (b) that one of the Struts team won't just go do it themselves?
As Ted correctly says, we're all volunteers, but the difference is that you guys know your contributions aren't a waste of time (mostly... I realize other members can veto your additions). We don't have the luxury of that knowledge before we put the time in.
You know, I made a proposal a week or two ago to develop a site that would track enhancements being worked on, who was doing it, etc. I offered to do the site development work and even host it. It was rejected for various reasons. I still believe something along those lines would go a long way to helping alleviate this problem, and no, I still do not agree that the Wiki and/or Bugzilla serves this purpose. I seemed to be the only one with that opinion though. The point being, whether this idea or not, I believe *something* needs to be done because there are people willing to participate that see a very high barrier to entry, one that seems to be next to impossible to get around.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Dakota Jack wrote:
<SNIP> On Fri, 11 Mar 2005 11:42:20 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
At 8:29 AM -0800 3/11/05, Dakota Jack wrote:
Thanks, Frank. I posted this code in response to Ted's suggestion that this is the way to go to establish a dialogue with the committers on code.
I would totally endorse Ted's suggestion.
</SNIP>
We will see if it works. I did that.
I have made a proposal which can be assessed at this stage. There is no question about what would need to be done to implement the code I have provided. The basis is, as I said, about 15 lines of code. The idea is what is what must be accepted or rejected. I don't have time to spin my wheels. If the idea is not acceptable no matter what, then that is okay. But, if that is the case, doing "no matter what" is spinning wheels.
<SNIP>
The best approach is to publicly document approaches and, where possible, provide extension code that can be exercised without rushing a change to the Struts core. This is how struts-chain was developed and verified as a reasonable approach before the core was changed. It also happens to be how validator and tiles evolved. In a much more modest fashion, this was the origin of the DigestingPlugIn, which I developed and published and which was adopted into Struts all before I was a committer.
</SNIP>
I am not sure what this means in terms of what I discussed and provided. I am not suggesting a change to the Struts core. I am not even suggesting something inconsistent with present practice.
<SNIP>
In fact, I know of no open source project which would add incompatible features to an older release, except in the case of a major version number change.
</SNIP>
Isn't branching common? I may misunderstand this?
</SNIP>
I don't think we've earned "Struts 2.0" with the other changes we have, although until we do a release, we could certainly debate calling the chain based processor Struts 2.0 and making room for Frank's changes in what would then be a live development version on the 1.x branch.
</SNIP>
If this is just an opening of the RequestProcessor logic, why is it
discussed so much as "chain based"? Shouldn't the interface allow for
changes in the future which are not chain based? There is so little
discussion about core changes on this list that what is happening is
impossible to tell unless you are one of the few people doing all the
work. The options from someone on the "outside" seem to be to have
ten people doing ten things on their own and then submitting it all at
one time to see who wins, rather than working together. I thought I
could work with people on a list like this. Is that not the idea? This seems to be impossible from my perspective. No matter what you
provide, it is always met with "we cannot comment on that at this time
because ...." or "no". It is frustrating, Martin.
<SNIP>
As always, remember that we're all volunteers here, and we all have to scrounge for the time we apply to Struts. Also, we have an enormous installed base, and we have to take their needs into account. If the general open source community has come to expect compatibility between minor version releases, and if we've always struck a firm stance towards providing that kind of compatibility in Struts, then we need to maintain consistency.
</SNIP>
I think we all know that. I really do. Somehow there is this idea that this basic requirement escapes people. But, I don't think it does.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
