Craig, I read somewhere that you got involved in opensource development because you where tired of waiting for fixes never being done? I think that is the way Eddie, Taylor, Jason and others (including myself) are starting to feel. After all Struts1.1 has been taking quite a long time now.
Although our patches are minor, there should be some way of responding to them without having to post entire "alternative nightly builds". These patches are, after all just small patches. I dont think there is an "attitude" here, just a genuine interest in STRUTS and its development process. Suggestion: If committers have to "take ownership" it might not be addressed by anyone. Could there be a process where a request Manager could delegate ownership (if not taken) and committers could choose to accept this or not? -- Joachim Craig R. McClanahan wrote: >Are you ready to do my job for me (60 hours a week lately), including my >travel schedule (such as Tokyo last week for JavaOne Japan), so I can >work on Struts? Or, better yet, pay me enough so I can work on it full >time? If you're not, then I find your attitude pretty presumptuous. > >All of Struts was, and is, done by volunteers on their own time. We do >this because we enjoy it -- the fact that *you* find it useful as well is >icing on the cake. When people have time to analyze the patches and apply >them (and take ownership for any problems that the patch causes), they >will -- but not until. > >If you feel strongly about it, start posting alternative nightly builds >that contain your patches applied. Who knows, if it's clear you know what >you are doing, you might get yourself nominated to be a committer, and >then *you* can see what it is like first hand :-). > >Craig > > >On Thu, 3 Oct 2002, Eddie Bush wrote: > > > >>Date: Thu, 03 Oct 2002 14:27:13 -0500 >>From: Eddie Bush <[EMAIL PROTECTED]> >>Reply-To: Struts Developers List <[EMAIL PROTECTED]> >>To: Struts Developers List <[EMAIL PROTECTED]> >>Subject: Applying patches >> >>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]> >> >> >> >> > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
