Re: [ANN] New Struts Committers: Musachy Barroso, Philip Luppens, Tom Schneider, Henri Yandell
Unfortunately, I dropped out of my education in the second year as a monk in the order of the crippled mantis. But I'll invite Tom and Musachy, and as soon as our myspace page is set up, we'll post an announcement with a link to the video. Thanks, Phil On 2/19/07, Tom Schneider <[EMAIL PROTECTED]> wrote: I went to an engineering school, we didn't have a school song. :-) Musachy Barroso wrote: > bring it on Tom :) > > musachy > > On 2/18/07, Paul Benedict <[EMAIL PROTECTED]> wrote: >> >> All new committers must sing their alma mater. Who wants to be first? >> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- iDTV System Engineer "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." - John F. Woods - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: s1 - 1.x "Future" Issues
To make sure everything is reviewed, I look for the tickets without a fix version set (which maps to "unknown"), and then set the ticket to an upcoming milestone or a release series, or to Future. I don't consider Future the horizon, but beyond the horizon. The horizon is the numbered versions. If something is set to unknown (no fix version), then I know the ticket hasn't been reviewed. On 2/18/07, Paul Benedict <[EMAIL PROTECTED]> wrote: JIRA does not take the synonym to heart. JIRA provides an actual "Unknown" version which can be assigned to issues. If they are assigned to anything else, they appear on the road map. That's why it's better to put them to Unknown than Future, to indicate a horizon versus yonder. Paul Ted Husted wrote: > I wouldn't characterize "future" as meaning on the horizon for > implementation. We've been using it as a synonym for unknown. > > -Ted. > > On 2/16/07, Paul Benedict <[EMAIL PROTECTED]> wrote: >> There are 30 issues sitting under "Future", and I believe this is >> incorrect because it means they are on the horizon for implementation. >> Instead, I will probably go through and change them to version "Unknown" >> unless there is a really good chance someone will be addressing them. >> I'll wait until Sunday for feedback. Thanks. >> >> Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Users guide
Would a layout like Groovy make what we have more accessible? * http://groovy.codehaus.org/ On 2/14/07, Philip Luppens <[EMAIL PROTECTED]> wrote: Ok, sounds fine to me. Then we'll drop the User Guide, and start writing on those missing chapters. Btw, the crud tutorial: should we make a part II where we use a real database (in combination with Spring and Hibernate) ? I've updated it and verified it to work on S2, but WW-1711 is used in the tutorial, so I'm not closing the Jira issue yet. Cheers, Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Struts 2.0.6 Quality
The Struts 2.0.6 test build is now available. Release notes: * http://struts.apache.org/2.x/docs/release-notes-206.html Distribution: * http://people.apache.org/builds/struts/2.0.6/ Maven 2 staging repository: * http://people.apache.org/builds/struts/2.0.6/m2-staging-repository/ Once you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. The vote will remain open for at least 72 hours, longer upon request. A vote can be amended at any time to upgrade or downgrade the quality of the release based on future experience. If an initial vote designates the build as "Beta", the release will be submitted for mirroring and announced to the user list. Once released as a public beta, subsequent quality votes on a build may be held on the user list. As always, the act of voting carries certain obligations. A binding vote not only states an opinion, but means that the voter is agreeing to help do the work. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.6 Quality
+1 for GA - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=65672&messageID=125490#125490 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: s1 - 1.x "Future" Issues
On 2/19/07, Ted Husted <[EMAIL PROTECTED]> wrote: To make sure everything is reviewed, I look for the tickets without a fix version set (which maps to "unknown"), and then set the ticket to an upcoming milestone or a release series, or to Future. I don't consider Future the horizon, but beyond the horizon. The horizon is the numbered versions. If something is set to unknown (no fix version), then I know the ticket hasn't been reviewed. Right. And in fact that was the basis upon which the version values in JIRA were created, when we moved from Bugzilla. There's a fairly lengthy discussion of this in the archives, for anyone who cares to delve into the rationale more deeply. -- Martin Cooper On 2/18/07, Paul Benedict <[EMAIL PROTECTED]> wrote: > JIRA does not take the synonym to heart. JIRA provides an actual > "Unknown" version which can be assigned to issues. If they are assigned > to anything else, they appear on the road map. That's why it's better to > put them to Unknown than Future, to indicate a horizon versus yonder. > > Paul > > Ted Husted wrote: > > I wouldn't characterize "future" as meaning on the horizon for > > implementation. We've been using it as a synonym for unknown. > > > > -Ted. > > > > On 2/16/07, Paul Benedict <[EMAIL PROTECTED]> wrote: > >> There are 30 issues sitting under "Future", and I believe this is > >> incorrect because it means they are on the horizon for implementation. > >> Instead, I will probably go through and change them to version "Unknown" > >> unless there is a really good chance someone will be addressing them. > >> I'll wait until Sunday for feedback. Thanks. > >> > >> Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.6 Quality
[ ] Leave at test build [ ] Alpha [ ] Beta [X] General Availability (GA) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.6 Quality
--- Ted Husted <[EMAIL PROTECTED]> wrote: > [ X ] General Availability (GA) So you get at least one user vote :) Dave Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: s1 - 1.x "Future" Issues
Ted, I was hoping that it would be obvious that version 1.x or whatever is sooner than Future :-) So when I talk about Future being on the horizon, yes, the issues have been reviewed and the ticket is viable, but it's not slated for the near future. However, what about tickets that are reviewed but there's no current interest in addressing them? That's the main problem here. Because as long as the bug isn't invalid, we could suck all the issues into Future. However, that totally defeats the purpose of the road map if there are 400 issues being listed as "Future". I am looking for direction here: If it is is up to me, I am re-reviewing the 30-some Future tickets and re-assigning them back to Unknown if there's no good chance they are going to be addressed in this or the next major release. They've been siting around for a very long time. So I'd like to know what SHOULD be done? You know my preference. Paul
Re: s1 - 1.x "Future" Issues
Perhaps instead of using a 1.x category, it might be more useful to tag issues 1.4.x or 1.5.x categories, and then "Future" for anything else.. So perhaps the 1.x issues that are not on the front-burner for 1.4.x should be marked Future, and the 1.x category retired. There may not be current interest among today's committers in pursuing an issue, but there may still be interest among future committers. -Ted. On 2/19/07, Paul Benedict <[EMAIL PROTECTED]> wrote: Ted, I was hoping that it would be obvious that version 1.x or whatever is sooner than Future :-) So when I talk about Future being on the horizon, yes, the issues have been reviewed and the ticket is viable, but it's not slated for the near future. However, what about tickets that are reviewed but there's no current interest in addressing them? That's the main problem here. Because as long as the bug isn't invalid, we could suck all the issues into Future. However, that totally defeats the purpose of the road map if there are 400 issues being listed as "Future". I am looking for direction here: If it is is up to me, I am re-reviewing the 30-some Future tickets and re-assigning them back to Unknown if there's no good chance they are going to be addressed in this or the next major release. They've been siting around for a very long time. So I'd like to know what SHOULD be done? You know my preference. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: s1 - 1.x "Future" Issues
On 2/19/07, Paul Benedict <[EMAIL PROTECTED]> wrote: Ted, I was hoping that it would be obvious that version 1.x or whatever is sooner than Future :-) So when I talk about Future being on the horizon, yes, the issues have been reviewed and the ticket is viable, but it's not slated for the near future. However, what about tickets that are reviewed but there's no current interest in addressing them? That's the main problem here. Because as long as the bug isn't invalid, we could suck all the issues into Future. However, that totally defeats the purpose of the road map if there are 400 issues being listed as "Future". Why does it defeat the purpose of the roadmap? The "Future" tag means "valid issue but not yet assigned to a specific release". Once someone elects to fix an issue, then it should be assigned a specific release label instead of Future. Paul, all this is in the archives from when this process was defined, about a year and a half ago. -- Martin Cooper I am looking for direction here: If it is is up to me, I am re-reviewing the 30-some Future tickets and re-assigning them back to Unknown if there's no good chance they are going to be addressed in this or the next major release. They've been siting around for a very long time. So I'd like to know what SHOULD be done? You know my preference. Paul
Re: s1 - 1.x "Future" Issues
The purpose of the Road Map is to assign issues to a release. Since "Future" is not a version or a release -- but just a grouping of issues for the "future" -- it has little use, and the way we use it tells me we're using the Road Map wrongly. Now, I believe that's the case, but I am not going to fight this issue too strongly because it is not critical to anything. I'll go back and look at the archives, but there's nothing wrong with re-examining past decisions. I haven't seen other JIRA projects slating things into a "Future" version -- and probably because it's not a version. Paul
Re: s1 - 1.x "Future" Issues
On 2/19/07, Paul Benedict <[EMAIL PROTECTED]> wrote: The purpose of the Road Map is to assign issues to a release. Since "Future" is not a version or a release -- but just a grouping of issues for the "future" -- it has little use, and the way we use it tells me we're using the Road Map wrongly. Now, I believe that's the case, but I am not going to fight this issue too strongly because it is not critical to anything. I'll go back and look at the archives, but there's nothing wrong with re-examining past decisions. I haven't seen other JIRA projects slating things into a "Future" version -- and probably because it's not a version. Paul For what it's worth, we're using a "TBD" version identifier in Shale for the same concept that "Future" seems intended for in Struts ... to track things that are real issues (either bugs or RFEs), but for which no one has yet stepped up and said "I want to deal with this for a particular release". This is different from "Unscheduled" (the default state when a new issue is created), because it has to be looked at and assigned, instead of being closed as "Will Not Fix" or "Not A Problem" immediately. An issue tracking system should (IMHO) be useful for more than just roadmaps and release notes. Let's say you hear from an enthusiastic user who wants to contribute to the project, but doesn't have a specific idea on where to start. Where do you send him or her to get some ideas? For Shale, I've got a simple answer[1]. Wouldn't Struts like to have the same ability? Craig [1] https://issues.apache.org/struts/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10130&fixfor=21773 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: s1 - 1.x "Future" Issues
On 2/19/07, Paul Benedict <[EMAIL PROTECTED]> wrote: The purpose of the Road Map is to assign issues to a release. Since "Future" is not a version or a release -- but just a grouping of issues for the "future" -- it has little use, and the way we use it tells me we're using the Road Map wrongly. So you don't think there's value in a category that says "yes, this has been examined and determined to be a valid issue that should be fixed in a future version"? That is what "Future" is. The "Unknown" category is where issues live before they have been verified. Once someone signs up to fix an issue, it gets assigned to a specific version. The reason they're not assigned to specific releases before that is because, without someone specifically signing up for them, there is no assurance that they _will_ be fixed in a specific release. That is the problem we had with Bugzilla - issues assigned to release versions but without anyone having signed up to actually fix them, and that is meaningless. Maybe it's just the label "Future" you don't like? Would "Accepted" or "Verified" or something feel better to you? -- Martin Cooper Now, I believe that's the case, but I am not going to fight this issue too strongly because it is not critical to anything. I'll go back and look at the archives, but there's nothing wrong with re-examining past decisions. I haven't seen other JIRA projects slating things into a "Future" version -- and probably because it's not a version. Paul
Re: s1 - 1.x "Future" Issues
From that perspective, the underlying problem is that JIRA puts every "release" on the "roadmap" whether we want it to or not. It's not that we are using JIRA wrongly, only that JIRA, like any off-the-shelf product, is imperfect. We are mapping what we want to do to the JIRA system, the best way we know how. Leaving issues at unknown is not workable, since as Craig and Martin pointed out, we want a "job jar" of issues that have been reviewed and found joyful, but have not been assigned to a specific milestone or release series. On 2/19/07, Paul Benedict <[EMAIL PROTECTED]> wrote: The purpose of the Road Map is to assign issues to a release. Since "Future" is not a version or a release -- but just a grouping of issues for the "future" -- it has little use, and the way we use it tells me we're using the Road Map wrongly. Now, I believe that's the case, but I am not going to fight this issue too strongly because it is not critical to anything. I'll go back and look at the archives, but there's nothing wrong with re-examining past decisions. I haven't seen other JIRA projects slating things into a "Future" version -- and probably because it's not a version. Paul -- HTH, Ted. * http://www.husted.com/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: s1 - 1.x "Future" Issues
Thank you for everyone's input. I do see the reason behind why having a TBD/Future is preferred by many people. I also find value in quickly determining which issues have been reviewed vs. new issues. Thus, I shall lay down my gauntlet!
Re: [s2] [VOTE] Struts 2.0.6 Quality
husted wrote: > > [X] General Availability (GA) > Tested with AppFuse 2.x (JDK 6, Maven 2.0.5, Tomcat 5.5.17 on OS X) and all tests pass. Matt -- View this message in context: http://www.nabble.com/-VOTE--Struts-2.0.6-Quality-tf3253694.html#a9054691 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
