I agree! I stated this frustration earlier this week in an unrelated thread. I recently posted a suggestion to improve the MessagesTag to struts-dev and asked for comments. I received 0. I have submitted patches for documentation that have gone completely uncommitted and uncommented on. If my patches are terrible then at least say why in bugzilla.
I want to contribute more documentation but don't want to take the risk of them not being seen. I'm not blaming anyone and, like Eddie, respect all of the committers. I would like to see this issue addressed though. Thanks, Dave >From: Eddie Bush <[EMAIL PROTECTED]> >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]> >To: Struts Developers List <[EMAIL PROTECTED]> >Subject: Applying patches >Date: Thu, 03 Oct 2002 14:27:13 -0500 > >I'm sure there's some protocol for applying patches that fits into the >Struts development cycle, but I'm not aware of what it is. I have to admit >it's somewhat annoying to find a bug, patch it, build a patch file, and >submit it, only to have it seemingly ignored. I honestly don't believe >they are intentionally ignored, and I do realize that the commiters have >other things they have to do than just examine/commit proposed fixes to >bugs, but I would also like to state that it's somewhat aggrevating to see >developed/tested patches sit idle (without explaination) when there are >likely folks out there that may be hitting on problems the patch addresses >- some of which, being unsure of themselves (because they are new, >perhaps), are absolutely beating their head against the wall to try to get >Struts to behave as it rightly should - only to find they "still don't get >it" (through no fault of their own - the behavior is broken and they could >not make it work no matter how hard they try). > ><emote:standingOnSoapBox> >I'm not trying to step on any toes - the last thing I want is to offend >anyone here. Each of you is highly respected by me. However :-) I feel >that patches that address glaring bugs which inhibit a person from making >proper use of important (!) functionality of the framework should be >examined and applied quickly - they should have a high priority. > >Sub-Applications (the ability to bust your configuration file into as many >different files as your application has functional areas) is one of the >most significant features introduced in Struts 1.1 over Struts 1.0. Their >arrival is a "good thing" - but they do not work properly. > >The most glaring way in which they do not properly function is in >selection. The current selection algorithm is to iterate over the set of >known prefixes of the sub-apps and see if the requested URI starts with one >of the prefixes. This just really isn't acceptable, and here's why: > >/foo.do >/foo/bar.do > >Suppose you have the scenario setup by the above two actions. What >*should* happen when you invoke /foo.do? Obviously, the controller should >select the default application and execute "foo.do" from that module. What >*does* happen when you invoke /foo.do? Well, you switch to sub-app foo >because of the "startsWith()" criteria being used to select the sub-app. >Another example: > >/foo/index.do >/foo/bar/index.do (where /foo/bar is a sub-app name) > >Suppose you have this scenario. Again, you can see (I think) that you >won't necessarily select the proper application. Ok - point made: it's >definitely broke. > >What I'm getting at, I suppose, is that it's disheartening and discouraging >to see fixes having been submitted for this bug continue to not be applied. > Why would a person, acting with a sense of urgency to fix something that >is broken, act with that same sense of urgency to actually contribute their >changes back to the project, when their patch will not be applied (assuming >it does in fact fix the behavior to be as it should) with that same sense >of urgency? It's in everyone's best interest that each of us act with as >much of a sense of urgency as is practical for us (each individual will >have different constraints placed upon their ability to execute and the >timeline they are able to do so on) to address important issues as we find >them - is it not? ></emote:standingOnSoapBox> > >I've previously stated that it was irrelevant to me whether my patches were >used - and I meant that sincerely. I do believe, when provided with a >patch, it should be examined for merit and applied accordingly. Should the >commiter have some reason why a given patch is unacceptable, it would >really be nice for them to add a comment to the bug report itself stating >why they found the patch inappropriate (doesn't fully address the issue - >fixes one problem but creates another - whatever). > >I just hate to see folks turning away from sub-applications because their >implementation is (partially, at least) broke - and I know for a fact some >are. I also hate to think of the possibility where someone might choose >another framework over Struts because this gives them the mistaken >impression that it's not worthy of their use. Maybe I just take too much >pride in Struts. It's not like I have any "ownership" here - but I feel >like I do. > >Is there anything I can do, beyond submitting a patch (and doing so in a >format that makes it easily applied - ie diff -u), to get a bug fixed in a >timely manner? It makes me sad to think of the nightly builds which could >have already incorporated this fix ... and the people suffering from it >having not been incorporated. > >Kindest Regards, > >Eddie > >-- >Eddie Bush > > > > >-- >To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
