Re: Release Process thoughts (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
On 5/16/06, Ted Husted [EMAIL PROTECTED] wrote: I won't cast a quality vote on anything but a tagged and rolled, downloadable distribution. Many of the problems we've had in the past (not just this time, but with other series too) appear in the final product and are not evident in a checkout. That is certainly not true for the current Maven 2 build. Anyone can very easily run the two maven commands to generate a release build, as there is no special thing the release manager does. In fact, I'd argue by only testing point releases is a cop-out, as every Struts PMC member should be confortable running the release build. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Process thoughts (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
On 5/16/06, Don Brown [EMAIL PROTECTED] wrote: I think the solution is to: 1. Make betas publicly available and widely known like our 1.1 betas were +1. Based on this and other comments, I'd like to add the following to the release guidelines [1]: * Versions with significant changes, especially new major or minor versions, should first be released and distributed as Alpha or Beta quality, then later upgraded to GA if it is warranted. The entire release process should be as easy and clear as possible. Right now there are a couple of points where it's not easy for someone new to the process (or me, at least,) to figure out what to do next, or how. I've been working on the how part with Maven, [2] but we're missing some of the what in the guidelines. 2. Do all testing and even the vote _before_ a code freeze and subsequent release. IMO the advance testing should already be happening with snapshots or nightly builds. I agree with Ted and Paul that we should only vote on the actual signed distribution that's going to be uploaded. It's easy to imagine accidentally introduce a problem when you're building the final distribution. I wouldn't be comfortable uploading anything to dist/ unless it had been looked at by others. [1] http://struts.apache.org/releases.html [2] http://wiki.apache.org/struts/StrutsMavenRelease -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Process thoughts (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
On 5/17/06, Wendy Smoak [EMAIL PROTECTED] wrote: I agree with Ted and Paul that we should only vote on the actual signed distribution that's going to be uploaded. It's easy to imagine accidentally introduce a problem when you're building the final distribution. I wouldn't be comfortable uploading anything to dist/ unless it had been looked at by others. I'd guess 90+% of other open source projects seem to do just fine doing all the testing and voting before the release. I understand the concern of screwing things up from a release manager standpoint, but that tells me we need better tests, a more automatic Maven build, etc. We don't require reviews after every commits because we trust the committer. Releases should be braindead easy. If they were, and everyone had tested the code beforehand and given their thumbs up, a release should be basically automatic, something we can trust to another committer without looking over their shoulder. Ok, so if you don't think this is the answer to the backwards release then test problem, what is? Don [1] http://struts.apache.org/releases.html [2] http://wiki.apache.org/struts/StrutsMavenRelease -- Wendy - 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]
Re: Release Process thoughts (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
On 5/17/06, Don Brown [EMAIL PROTECTED] wrote: Ok, so if you don't think this is the answer to the backwards release then test problem, what is? I don't know. Earlier 1.x releases had the benefit of the entire team focused on them, and more people using nightly builds. That's no longer the case. How many people have 1.3-based apps in active development? I do, but only for about six more weeks. After that, it will be a lot more trouble for me to test 1.3. (Besides checking the example apps, I like to see it working in a real application.) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Process thoughts (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
On 5/17/06, Don Brown [EMAIL PROTECTED] wrote: I'd guess 90+% of other open source projects seem to do just fine doing all the testing and voting before the release. I'm not aware of any project, open or closed source, that only issues stable or GA releases without issuing any type of beta or release-candidate first. The process is suppose to be that we release the distribution as an Alpha or Beta Release first, and then, based on feedback from the rest of the users, decide whether to promote it to GA. In this particular case, we are not distributing the 1.3.4 Beta because of the DTD issue. Otherwise, it would already be mirrored, announced, and linked on the downloads page, just like the Shale Alpha. We do *not* need a GA designation to announce and distribute a release. I understand the concern of screwing things up from a release manager standpoint, but that tells me we need better tests, a more automatic Maven build, etc. We don't require reviews after every commits because we trust the committer. Releases should be braindead easy. If they were, and everyone had tested the code beforehand and given their thumbs up, a release should be basically automatic, something we can trust to another committer without looking over their shoulder. Ok, so if you don't think this is the answer to the backwards release then test problem, what is? The release process isn't backward. It's the same process that Tomcat, HTTPD, MySQL, and many other teams uses. We issue a milestone and then decide if it's an Alpha or a Beta. We let the rest of the world test it, and if it gets the thumbs up, we promote it to GA, without re-rolling or re-naming the distribution. No fuss, no muss. If the codebase is stable, as it has been with Struts 1.2 lately, then we might skip straight to GA, but only because we already have other releases under our belt. Struts 1.2.x went through had both a test build and a Beta before we hit GA in 1.2.2. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Process thoughts (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
On 5/16/06, Ted Husted [EMAIL PROTECTED] wrote: On 5/16/06, Don Brown [EMAIL PROTECTED] wrote: I think the solution is to: 1. Make betas publicly available and widely known like our 1.1 betas were +1 I think the notion that we can't announce and mirrors Betas is a misunderstanding. We can mirror an announce *any* release, even an Alpha. Announce and mirror are two different things. IIRC, Apache's general guidelines on mirror are GA releases only (although we've probably been among the folks that bypassed that policy on occasion). Sorry not to have time (here at JavaOne this week) to do the historical research to back this up, hence the disclaimer that this might be my foggy memory. Craig
Re: Release Process thoughts (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
On 5/17/06, Craig McClanahan [EMAIL PROTECTED] wrote: Announce and mirror are two different things. IIRC, Apache's general guidelines on mirror are GA releases only (although we've probably been among the folks that bypassed that policy on occasion). The FAQ suggest that all releases be announced and goes on to say that for some very popular distributions, the volumes of downloads for unstable releases may require that they are mirrored. In this case, they should be located in the same directory structure as current stable releases. * http://www.apache.org/dev/release.html For a Struts Action Beta that we expect might go GA, mirroring would seem to be appropriate. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug/change in interpretation of ActionMapping with CRP (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
At 1:07 PM -0500 5/16/06, Joe Germuska wrote: I've uncovered a couple of things in porting an old Struts 1.1 application to 1.3; I know they probably need to go in Jira, but I wanted to get a little discussion about them before filing them. Actually, now I think i'll send them separately with different subject lines to help manage the various conversations that might arise... One thing we found was that the action mapping below worked in Struts 1.1 but not in Struts 1.3: action path=/Homepage type=org.apache.struts.actions.ForwardAction forward=HOMEPAGE / Apparently, Struts 1.1 favored the forward over the type so that this was forwarded to HOMEPAGE before ForwardAction was executed. In Struts 1.3, the type is favored, so that the ForwardAction was executed, triggering an exception because no parameter attribute was defined. (The mapping above, then, is simply misguided, but the developer who used it saw the desired results and never looked back.) In Struts 1.3, it had to be changed to this: action path=/Homepage type=org.apache.struts.actions.ForwardAction parameter=HOMEPAGE / which has the same net effect. I don't understand why we even have a ForwardAction when you can achieve the same with the forward attribute. This would be equivalent to both of the above: action path=/Homepage forward=HOMEPAGE / So, then, we have the question of whether this difference in behavior constitutes a bug in Struts 1.3, or simply something which should be documented in migration notes and kept in our collective answer-boxes should the question come up on struts-user. (We could also consider deprecating ForwardAction, unless someone can explain its use to me; I'm guessing it's just five years old and was a good idea at the time) For this one, my vote is should be documented; I don't think there's any one-true-way to handle conflicting configuration and I don't think it was ever documented anywhere before that forward trumps type. If anyone would like to take a stab at documenting this, I'm way behind after all the time I had to spend debugging this and some other issues related to making this move (including using third party libraries with dependencies on things removed and no source code to be found, oy!) Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new. -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Various Module bugs in Struts 1.3.x (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
At 1:07 PM -0500 5/16/06, Joe Germuska wrote: I've uncovered a couple of things in porting an old Struts 1.1 application to 1.3; I know they probably need to go in Jira, but I wanted to get a little discussion about them before filing them. Actually, now I think i'll send them separately with different subject lines to help manage the various conversations that might arise... This bug has taken a pretty long time to surface, I think mostly because modules are relatively infrequently used, but I think it constitutes a bug which should be fixed. I'll describe and get some feedback before posting to JIRA or changing. In Struts 1.1, the TilesRequestProcessor derived the base URI (usually a JSP) from a given tiles definition and asked Struts to forward or include. See http://svn.apache.org/viewcvs.cgi/struts/action/tags/STRUTS_1_1/src/share/org/apache/struts/tiles/TilesRequestProcessor.java?view=markup, particularly processTilesDefinition and doForward In Struts 1.3, the TilesPreProcessor tries to do the same thing by changing the ActionForward in the context before deferring to other commands in the chain: http://struts.apache.org/struts-action/struts-tiles/xref/org/apache/struts/tiles/commands/TilesPreProcessor.html#218 Thus, the TilesRequestProcessor causes a forward to happen directly to the derived path, while PerformForward prepends the ActionContext's moduleConfig's prefix to the tiles base path. In tracking the code a little further, I think that PerformForward may also be handling modules incorrectly. It always uses the context's moduleConfig if the ForwardConfig's path begins with /, so even if a ForwardConfig has its module property set, that property will be ignored. http://struts.apache.org/struts-action/struts-core/xref/org/apache/struts/chain/commands/servlet/PerformForward.html#69 PerformForward should be consulting the module property of the ForwardConfig and using it to select (if appropriate) a module, more like SwitchAction (which actually probably doesn't work either, since its call [1] to ModuleUtils.getInstance().selectModule(...)[2] doesn't actually change the ActionContext!) (and now I'm beginning to realize why I've advised my team not to use modules in new development! I certainly don't understand the details; does anyone consider themselves expert in using modules?)... [1] http://struts.apache.org/struts-action/struts-extras/xref/org/apache/struts/actions/SwitchAction.html#95 [2] http://struts.apache.org/struts-action/struts-core/xref/org/apache/struts/util/ModuleUtils.html#235 So, the following classes are probably broken: TilesPreProcessor PerformForward SwitchAction I'm not sure I see the best way to straighten these things out -- I could hack things up, but maybe someone who is more fond of modules could consult? Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new. -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Process thoughts (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
What I dislike is spending untold personal hours fixing all known issues and putting out a release, only to have it continually shot down, not available to anyone. Specifically: 1. Our release plan states we only make GA's available on the mirrors and from the download page, so anything less is hidden from view and unavailable for users 2. The betas we do put out are poorly tested by the PMC 3. The fact that all this testing happens after the release. This is completely backward! After every release, you will find issues with it down the road. By holding the voting and testing till after the release is rolled, chances are you will find something you don't like resulting in a failed vote. This is very discouraging for the Release Manager who put hours into creating the release. The icing on the cake is out of all the complaints of the DTD bug, none of the people who took the time to write detailed explanations bothered to lift a finger to fix it (Wendy finally did), much less roll another release. I think the solution is to: 1. Make betas publicly available and widely known like our 1.1 betas were 2. Do all testing and even the vote _before_ a code freeze and subsequent release. I personally won't waste my time doing a release if people will only test it after the fact. Don On 5/16/06, Joe Germuska [EMAIL PROTECTED] wrote: I hadn't made a point of responding since the vote was already closed, but I've come to agree that the problems identified with the 1.3.4 build are sufficient to make it a beta, and further, I've just identified one or two other things that are worth nothing that probably further justify that. Before listing them, I'll note that I now agree that it is wrong to call a vote on a release's quality offering the choices of alpha, beta, or GA. Rather, we should have straight yes/no votes for each of these in turn, perhaps at a prescribed interim. I would be willing to forego always requiring an alpha vote, but it seems like we should never vote a release GA that hasn't had a decent period of use as a beta release. Some of us who have been using Struts 1.3 are confident in it, but we don't constitute a big enough population to be the only beta testers. I understand Don's frustration at the lack of people participating in testing, but I think that we would get more people testing if we put something out and called it a beta than simply expecting them to test nightly builds and test builds. Committers should be checking test builds and finding the kinds of packaging things that were uncovered with Struts 1.3.3, but it takes more time to uncover other things, and more testers. I've uncovered a couple of things in porting an old Struts 1.1 application to 1.3; I know they probably need to go in Jira, but I wanted to get a little discussion about them before filing them. Actually, now I think i'll send them separately with different subject lines to help manage the various conversations that might arise... Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new. -- Robert Moog - 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]
Re: Release Process thoughts (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
On 5/16/06, Don Brown [EMAIL PROTECTED] wrote: I think the solution is to: 1. Make betas publicly available and widely known like our 1.1 betas were +1 I think the notion that we can't announce and mirrors Betas is a misunderstanding. We can mirror an announce *any* release, even an Alpha. After distribution as an Alpha or a Beta, we can upgrade the release quality to GA, if appropriate. When a release series is very mature, like 1.2.x is now, we might go straight to GA, but that's not realistic for a new minor series. 2. Do all testing and even the vote _before_ a code freeze and subsequent release. I personally won't waste my time doing a release if people will only test it after the fact. -1 I won't cast a quality vote on anything but a tagged and rolled, downloadable distribution. Many of the problems we've had in the past (not just this time, but with other series too) appear in the final product and are not evident in a checkout. The nature of the beast is that it takes anywhere from three to five Betas before we hit a GA release. That's not just Apache Struts, but all the ASF projects I've ever followed. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Process thoughts (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
I am +2 with Don's idea. Quite frankly, my favorite Apache projects besides Struts are Tapestry and Tomcat, and those PUT OUT BETA versions on their website. The versions are specifically listed as beta, and then they change the website to list it as GA if a vote changes it. -- Paul --- Don Brown [EMAIL PROTECTED] wrote: What I dislike is spending untold personal hours fixing all known issues and putting out a release, only to have it continually shot down, not available to anyone. Specifically: 1. Our release plan states we only make GA's available on the mirrors and from the download page, so anything less is hidden from view and unavailable for users 2. The betas we do put out are poorly tested by the PMC 3. The fact that all this testing happens after the release. This is completely backward! After every release, you will find issues with it down the road. By holding the voting and testing till after the release is rolled, chances are you will find something you don't like resulting in a failed vote. This is very discouraging for the Release Manager who put hours into creating the release. The icing on the cake is out of all the complaints of the DTD bug, none of the people who took the time to write detailed explanations bothered to lift a finger to fix it (Wendy finally did), much less roll another release. I think the solution is to: 1. Make betas publicly available and widely known like our 1.1 betas were 2. Do all testing and even the vote _before_ a code freeze and subsequent release. I personally won't waste my time doing a release if people will only test it after the fact. Don On 5/16/06, Joe Germuska [EMAIL PROTECTED] wrote: I hadn't made a point of responding since the vote was already closed, but I've come to agree that the problems identified with the 1.3.4 build are sufficient to make it a beta, and further, I've just identified one or two other things that are worth nothing that probably further justify that. Before listing them, I'll note that I now agree that it is wrong to call a vote on a release's quality offering the choices of alpha, beta, or GA. Rather, we should have straight yes/no votes for each of these in turn, perhaps at a prescribed interim. I would be willing to forego always requiring an alpha vote, but it seems like we should never vote a release GA that hasn't had a decent period of use as a beta release. Some of us who have been using Struts 1.3 are confident in it, but we don't constitute a big enough population to be the only beta testers. I understand Don's frustration at the lack of people participating in testing, but I think that we would get more people testing if we put something out and called it a beta than simply expecting them to test nightly builds and test builds. Committers should be checking test builds and finding the kinds of packaging things that were uncovered with Struts 1.3.3, but it takes more time to uncover other things, and more testers. I've uncovered a couple of things in porting an old Struts 1.1 application to 1.3; I know they probably need to go in Jira, but I wanted to get a little discussion about them before filing them. Actually, now I think i'll send them separately with different subject lines to help manage the various conversations that might arise... Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new. -- Robert Moog - 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] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Process thoughts (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
I am also -1 because on #2 that's not how I understand the voting process to work. It's cut a version, publish it out as beta for developers to use, vote later on it. I model my thoughts after what I've seen on Tomcat. -- Paul --- Ted Husted [EMAIL PROTECTED] wrote: On 5/16/06, Don Brown [EMAIL PROTECTED] wrote: I think the solution is to: 1. Make betas publicly available and widely known like our 1.1 betas were +1 I think the notion that we can't announce and mirrors Betas is a misunderstanding. We can mirror an announce *any* release, even an Alpha. After distribution as an Alpha or a Beta, we can upgrade the release quality to GA, if appropriate. When a release series is very mature, like 1.2.x is now, we might go straight to GA, but that's not realistic for a new minor series. 2. Do all testing and even the vote _before_ a code freeze and subsequent release. I personally won't waste my time doing a release if people will only test it after the fact. -1 I won't cast a quality vote on anything but a tagged and rolled, downloadable distribution. Many of the problems we've had in the past (not just this time, but with other series too) appear in the final product and are not evident in a checkout. The nature of the beast is that it takes anywhere from three to five Betas before we hit a GA release. That's not just Apache Struts, but all the ASF projects I've ever followed. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts release process is broken (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
Don, Then, once the release is out, people nitpick through it finding issues to shoot it down (and yes, a beta is as good as a killed release because it doesn't get out to the users in an public, accessible location). I must be one of the folk guilty of nit-picking :) But honestly, I thought I found some legtimate issues, but that's only because the release managers asked people to find issues with it. I mean, the nit-picking has to be after a release because who wants to test something that's constantly in-flux? There needs to be a pretty stable baseline, and that's what I believe the release is for. So many changes go in and out of SVN, it's difficult to tell when things are published or not (like the site) in a distribution. But as for the problem with 1.3.4, it is bigger than Struts itself: it's an infrastructure issue, so I am told. Therefore, let's call this an exception. -- Paul --- Don Brown [EMAIL PROTECTED] wrote: Craig McClanahan wrote: However, I would be unhappy with all of us other committers if we stopped testing 1.3.4 at all, until 1.3.5became available, and we surface yet another two line change next week. This is exactly why I think this release process, or least least the Struts PMC implementation of it, is broken. A few Struts committers work their butts off to push out a release, clearing all known issues and repeatedly asking for help but getting none. Then, once the release is out, people nitpick through it finding issues to shoot it down (and yes, a beta is as good as a killed release because it doesn't get out to the users in an public, accessible location). Ok, we go back, fix the issues, and roll another release, only to have the same process happen again and again. Honestly, this is very discouraging and kills any momentum we get. Personally, I give up. I previously believed Struts moved so slowly because of a lack of effort, but I'm wondering if the problem isn't more profound. If, in six months with 100% dedicated committers willing to do whatever it takes and a codebase that is stable and proven, we can't push out a GA release, we have a serious problem. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts release process is broken (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
On 5/14/06, Don Brown [EMAIL PROTECTED] wrote: If, in six months with 100% dedicated committers willing to do whatever it takes and a codebase that is stable and proven, we can't push out a GA release, we have a serious problem. First, six months of effort would be a record. Typically, the process has taken 18 to 24 months. Whether the process is fast or slow, the process has been successful. We all have a lot of very stable applications in production. What grassroots engineers say over and over again is that Struts Action 1 works just fine for them, and what we all want most in SAF1 is more stable, problem-free releases. Second, the 1.3.4 build is broken. Leaving the DTD unregistered could cause problems for any developer without a live internet connection. It will also put undue stress on intranets, and even on our own infrastructure. It's a technical error that should be corrected. Third, I'm not a fan of this notion that we should be able to push out a GA release at will. There has not even been a public Beta of 1.3 yet. Why are we so eager to publish a GA, when we have not even circulated a Beta for wider field-testing? It's cool that Struts Action 1.3 works for us. But, most days, the nightly builds work for us too. A GA should mean that we *know* it works for the wider user community too. Most ASF projects seem to go through an average three or four betas between GA's. How can we say anything is ready for GA when we haven't even published a Beta yet? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts release process is broken (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
On 5/14/06, Don Brown [EMAIL PROTECTED] wrote: yes, a beta is as good as a killed release because it doesn't get out to the users in an public, accessible location). Ummm, we can submit a Beta for general circulation and mirroring. Right now, today, we're doing that with the Shale *Alpha*. * http://struts.apache.org/downloads.html The GA mark isn't about how we distribute the build, it's about whether we think the build is ready for primetime. The idea is that first we circulate the build to a wider set of users, and then, based on feedback (or the lack thereof), we decide whether to upgrade the Beta to GA. Since the build is already in the mirroring system, if we do upgrade a distribution to GA, then all we have to do is update the website. No fuss, no muss. If it helps, I'd say we could we could even announce the next distribution as * Stuts Action 1.3.5 Beta (release candidate). (Given the votes, of course.) I think the only thing that's broken is the notion that a Beta is not a Release Candidate, and that a Beta can't be announced and mirrored. It is, and it can. :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts release process is broken (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
On 5/14/06, Ted Husted [EMAIL PROTECTED] wrote: If it helps, I'd say we could we could even announce the next distribution as * Stuts Action 1.3.5 Beta (release candidate). (Given the votes, of course.) I think the only thing that's broken is the notion that a Beta is not a Release Candidate, and that a Beta can't be announced and mirrored. It is, and it can. :) I'd rather not re-introduce the term release candidate at this point, especially not in combination with 'Beta'. Under our current guidelines, a Beta *is* a release. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
Wendy, the only reason I bring this up (and the only reason), is because I believe the Tiles DTD that has plagued 1.3.4 is a symptom of the decision. Listen to this logic: By making branding Tiles a 1.3.x version, we are directly tying the product to struts. That implies it is only for Struts, and that's not true. It really is its own product, BUT, if our goal is to tie it forever to Struts, then I am okay. I am just bringing it up because we have very much aligned Tiles to Struts with upgrading the Tiles DTD, and when Struts 1.4 comes out, I expect Tiles 1.4 DTD too. I don't have a problem with this, but it needs to be explicilty said that Tiles is a Struts component. If that's what we want, then I am good -- I just want it stated. -- paul --- Wendy Smoak [EMAIL PROTECTED] wrote: On 5/13/06, Paul Benedict [EMAIL PROTECTED] wrote: For this reason, I believe tiles and scripting should not belong with the struts distribution. I've tried to view them as part of the core product (which the examples and taglib align to), but I can't force myself to believe they are really 1.3 - they are 1.0.1 and 1.3. I recommend we remove them from the distribution and allow them to downloaded separately. Or, give them their real version numbers back. The moves of both Scripting and Tiles were discussed on the dev list before they happened. No objections were raised to folding Scripting into Struts Action. Struts Tiles was also brought back into Struts Action on the theory that even after Standalone Tiles is released, there will still need to be some glue code between it and Struts Action, so there will always be a 'struts-tiles' jar. I'd recommend reviewing the archived messages if you haven't already, and then starting another [proposal] thread if you still feel strongly about it. I'm not in favor of splitting any part of the current Struts Action distribution back out into a separate subproject. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/14/06, Paul Benedict [EMAIL PROTECTED] wrote: Listen to this logic: By making branding Tiles a 1.3.x version, we are directly tying the product to struts. That implies it is only for Struts, and that's not true. Struts Tiles *is* tied directly to Struts Action -- look at the dependency in action/tiles/pom.xml. This is not Standalone Tiles we're talking about. That's in the sandbox and doesn't depend on Struts. I am just bringing it up because we have very much aligned Tiles to Struts with upgrading the Tiles DTD, and when Struts 1.4 comes out, I expect Tiles 1.4 DTD too. Yes. But then, I always thought it was strange that there was no Tiles 1.2 DTD. And yes, this means that once a Struts Action 1.3 release is voted GA, that DTD, along with all the others, the TLDs and the public API, is set. A proposal (or at least a poll) might be in order to see whether we want to keep the Tiles 1.3 DTD or just have 1.1 since it has not changed. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
Wendy, +1 on picking apart my argument :) Thanks for clearing things up for me; I apologize for missing the obvious fact that this isn't Standalone Tiles. I got lost in my philosophy! Thanks again :) --- Wendy Smoak [EMAIL PROTECTED] wrote: On 5/14/06, Paul Benedict [EMAIL PROTECTED] wrote: Listen to this logic: By making branding Tiles a 1.3.x version, we are directly tying the product to struts. That implies it is only for Struts, and that's not true. Struts Tiles *is* tied directly to Struts Action -- look at the dependency in action/tiles/pom.xml. This is not Standalone Tiles we're talking about. That's in the sandbox and doesn't depend on Struts. I am just bringing it up because we have very much aligned Tiles to Struts with upgrading the Tiles DTD, and when Struts 1.4 comes out, I expect Tiles 1.4 DTD too. Yes. But then, I always thought it was strange that there was no Tiles 1.2 DTD. And yes, this means that once a Struts Action 1.3 release is voted GA, that DTD, along with all the others, the TLDs and the public API, is set. A proposal (or at least a poll) might be in order to see whether we want to keep the Tiles 1.3 DTD or just have 1.1 since it has not changed. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts release process is broken (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
On 5/14/06, Wendy Smoak [EMAIL PROTECTED] wrote: I'd rather not re-introduce the term release candidate at this point, especially not in combination with 'Beta'. Under our current guidelines, a Beta *is* a release. And, so is an Alpha. And we can distribute any release - Alpha, Beta, or GA -- as hard and wide as we like. Then, after distributing the release as a Beta, if no significant issues turn up, we can mark the same distribution as GA. In effect, every release is a release candidate, because every release could be upgraded to GA, should circumstances warrant. But, we should *not* even be thinking about marking a distribution GA until it has been distributed as a public Beta first. That's the part of the process that's been broken lately. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts release process is broken (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
Unless I'm mistaken, the votes I've always seen come up have three choices: mark a release alpha, beta or GA. This would seem to be the cause of the problem with the process to me because it in effect allows the process to be short circuited, i.e., a newly-rolled release could be marked GA immediately if that's what the vote result was. This is, I think, what your saying Ted. I think the fix is to simply have a number of separate votes in sequence, and to make this a known sequence that each release follows. For instance, we start with a 1.3.0 to begin with, and it is marked alpha (not sure if that needs to be voted on). At some point in time after that, someone decides that they think it's good enough to be beta now, so a vote is called and the choices are (a) beta or (b) stay at alpha. Likewise, when someone thinks a beta is good enough for GA, a similar vote is called with only two choices, GA or stay beta. None of these votes can be called unless the previous one was done. It's conceivable you could go from alpha to GA in a few days with this procedure, so it really isn't adding any extra impediment to GA I think. Each release can be distributed as far and wide as you want, and in fact should be, to get as many people testing as possible. Frank Ted Husted wrote: On 5/14/06, Wendy Smoak [EMAIL PROTECTED] wrote: I'd rather not re-introduce the term release candidate at this point, especially not in combination with 'Beta'. Under our current guidelines, a Beta *is* a release. And, so is an Alpha. And we can distribute any release - Alpha, Beta, or GA -- as hard and wide as we like. Then, after distributing the release as a Beta, if no significant issues turn up, we can mark the same distribution as GA. In effect, every release is a release candidate, because every release could be upgraded to GA, should circumstances warrant. But, we should *not* even be thinking about marking a distribution GA until it has been distributed as a public Beta first. That's the part of the process that's been broken lately. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts release process is broken (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
On 5/14/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Each release can be distributed as far and wide as you want, and in fact should be, to get as many people testing as possible. Yes. The reason we stopped putting qualifiers like beta and rc in the distribution names, was so we could start a distribution out as an alpha or beta, and then upgrade it later, based on actual feedback from the rest of the user community. We get all the benefits of one more beta, without the extra work. It's hubris for us to say Hey, this is GA, without ever offering the bits up as a Beta to the general public. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/14/06, Wendy Smoak [EMAIL PROTECTED] wrote: And yes, this means that once a Struts Action 1.3 release is voted GA, that DTD, along with all the others, the TLDs and the public API, is set. Oh, we've managed to make significant changes to the public APIs over the years. Most often, it's just a matter of introducing an alternative, deprecating the unfavored member, and then removing it in a subsequent release. In Struts 1.0, the Action perform method threw ServletException, in Struts 1.1 we changed that to an execute method that throws Exception. Come Struts 1.2, perform is removed for good. And here we are talking about *the* most visible member in the Action API. More recently, between 1.2.8 and 1.2.9 we just plain broke the API for the Cancel button -- because we felt resolving a security issue was more important than introducing a sudden change. Anything in any API can be changed. If something in 1.3 doesn't work well, or something better comes along, we can bring out 1.4 on any day of the week. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/11/06, Don Brown [EMAIL PROTECTED] wrote: Niall Pemberton wrote: To summarise then my vote is beta because I believe I think we're introducing an uncessaey PITA for users upgrading and it will increase questions on the user list and put additional load on the Apache Servers. I absolutely disagree. To be GA quality, it doesn't have to be perfect as we'll always keep finding issues. This should be something that is ticketed and marked against the next release, hopefully GA as well. Furthermore, this is such a small issue to pull back an entire release is way overkill. I absolutely disagree. ;-) This is a significant issue that will cause us to incur the wrath of the infrastructure team, and cause application startup issues for our users. I do agree that it doesn't have to be perfect, but this issue is much bigger than a minor bug in the code base. I think it would be irresponsible for the Struts team to release 1.3.4 as GA. -- Martin Cooper I think we should adjust any documentation to only mention the 1.1 DTD, and perhaps add the 1.3 DTD information as an errata. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: Once you have had a chance to review this test build, please respond with a vote on its quality: [ ] Alpha [X] Beta [ ] General Availability (GA) Sorry for the late response - I've been at The Ajax Experience conference for the last couple of days. I'm afraid that the Tiles DTD issue is enough for me to vote (strongly, in fact) against GA. If this release went GA, it would be our first 1.3 GA release, and thus has the potential for being downloaded and used by thousands of Struts developers. To have all of those developers' applications hitting ASF infrastructure every time they start their apps is not tenable. The infrastructure people are already very irritated indeed by all the hits coming from Java applications looking for DTDs, and some have suggested removing the use of DTDs completely if the applications cannot be prevented from hitting ASF infrastructure to verify them. IIRC, 6% of all minotaur traffic is for DTDs, and Struts is already the worst offender, by a significant margin. For us to consciously vote to release 1.3.4 as GA, and thus significantly exacerbate this problem - well, let's just say that if I could veto a 1.3.4 GA release, I would. I understand that there is a great desire to get a GA release out so that it can be announced at JavaOne. I too think this would be great - we really do need to see a 1.3 GA release out the door. But it needs to be GA quality, not just labelled GA in the interest of the timing of the announcement. Unfortunately, while I was out at TAE, my illustrious team managed to break the build of our primary 1.3-based app, so I haven't been able to evaluate 1.3.4 functionally at this point. I'll try to provide further feedback if I can get that resolved first. -- Martin Cooper
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: [ ] Alpha [X] Beta [ ] General Availability (GA) I would prefer that we resolve the DTD issue before marking a distribution ready for primetime. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
I know it is against our best practices, but can you just fix 1.3.4 with the correct DTD and then retag it? Do we need a new version (1.3.5) just for this? I am okay either which way. -- Paul --- Martin Cooper [EMAIL PROTECTED] wrote: On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: Once you have had a chance to review this test build, please respond with a vote on its quality: [ ] Alpha [X] Beta [ ] General Availability (GA) Sorry for the late response - I've been at The Ajax Experience conference for the last couple of days. I'm afraid that the Tiles DTD issue is enough for me to vote (strongly, in fact) against GA. If this release went GA, it would be our first 1.3 GA release, and thus has the potential for being downloaded and used by thousands of Struts developers. To have all of those developers' applications hitting ASF infrastructure every time they start their apps is not tenable. The infrastructure people are already very irritated indeed by all the hits coming from Java applications looking for DTDs, and some have suggested removing the use of DTDs completely if the applications cannot be prevented from hitting ASF infrastructure to verify them. IIRC, 6% of all minotaur traffic is for DTDs, and Struts is already the worst offender, by a significant margin. For us to consciously vote to release 1.3.4 as GA, and thus significantly exacerbate this problem - well, let's just say that if I could veto a 1.3.4 GA release, I would. I understand that there is a great desire to get a GA release out so that it can be announced at JavaOne. I too think this would be great - we really do need to see a 1.3 GA release out the door. But it needs to be GA quality, not just labelled GA in the interest of the timing of the announcement. Unfortunately, while I was out at TAE, my illustrious team managed to break the build of our primary 1.3-based app, so I haven't been able to evaluate 1.3.4 functionally at this point. I'll try to provide further feedback if I can get that resolved first. -- Martin Cooper __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/13/06, Paul Benedict [EMAIL PROTECTED] wrote: I know it is against our best practices, but can you just fix 1.3.4 with the correct DTD and then retag it? No. If we did that, (a) anyone who had run a Maven build against the 1.3.4that's up there now would still be using the old 1.3.4, because Maven would not pick up the new 1.3.4 since there is already a 1.3.4 in their local repo, and (b) when someone has problems, we'd end up having to ask are you using the original 1.3.4 or the hacked one?, and if the user was building with Maven, they wouldn't necessarily know, or have an easy way of finding out. Do we need a new version (1.3.5) just for this? Unfortunately, yes. It's the only reliable way. -- Martin Cooper I am okay either which way. -- Paul --- Martin Cooper [EMAIL PROTECTED] wrote: On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: Once you have had a chance to review this test build, please respond with a vote on its quality: [ ] Alpha [X] Beta [ ] General Availability (GA) Sorry for the late response - I've been at The Ajax Experience conference for the last couple of days. I'm afraid that the Tiles DTD issue is enough for me to vote (strongly, in fact) against GA. If this release went GA, it would be our first 1.3 GA release, and thus has the potential for being downloaded and used by thousands of Struts developers. To have all of those developers' applications hitting ASF infrastructure every time they start their apps is not tenable. The infrastructure people are already very irritated indeed by all the hits coming from Java applications looking for DTDs, and some have suggested removing the use of DTDs completely if the applications cannot be prevented from hitting ASF infrastructure to verify them. IIRC, 6% of all minotaur traffic is for DTDs, and Struts is already the worst offender, by a significant margin. For us to consciously vote to release 1.3.4 as GA, and thus significantly exacerbate this problem - well, let's just say that if I could veto a 1.3.4 GA release, I would. I understand that there is a great desire to get a GA release out so that it can be announced at JavaOne. I too think this would be great - we really do need to see a 1.3 GA release out the door. But it needs to be GA quality, not just labelled GA in the interest of the timing of the announcement. Unfortunately, while I was out at TAE, my illustrious team managed to break the build of our primary 1.3-based app, so I haven't been able to evaluate 1.3.4 functionally at this point. I'll try to provide further feedback if I can get that resolved first. -- Martin Cooper __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/13/06, Martin Cooper [EMAIL PROTECTED] wrote: Do we need a new version (1.3.5) just for this? Unfortunately, yes. It's the only reliable way. It also would not be any more work that hacking the 1.3.4 build. We'd have to do all the same things either way. Once the DTD issue is resolved, it's just a matter of tagging, and rolling, and posting. The only overhead is the release plan, which can be renamed or copied. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: The Struts Action Framework 1.3.4 Test Build is available to evaluate for release quality. The release plan is available on the wiki: http://wiki.apache.org/struts/StrutsActionRelease134 The test build, including checksums and signatures, has been deployed to: http://svn.apache.org/dist/struts/action/v1.3.4 Due to the concerns raised about the missing Tiles DTD registration, I'm changing my vote to Beta quality. The vote currently stands at 4 for Beta quality: Niall, Martin, Ted, Wendy 2 for GA quality: Don, Joe Therefore, Struts Action 1.3.4 will be designated Beta quality. Issue STR-2876 is open for the missing Tiles 1.1 DTD registration, and I'll start a release plan for version 1.3.5. (Would anyone like to volunteer as release manager?) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/13/06, Ted Husted [EMAIL PROTECTED] wrote: On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: [ ] Alpha [X] Beta [ ] General Availability (GA) I would prefer that we resolve the DTD issue before marking a distribution ready for primetime. I agree ... and vote for beta as well. But we should spend some more time testing to see if there are any other lurking ghosts before we send Wendy off on yet another cycle through the release plan process. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
I recommend we withdrawl the availablity of 1.3.4 from the download servers. Because this problem affects infrastructure, I do not believe it should remain as a version to be downloaded. Sometimes a distribution should just be killed off completely. --- Wendy Smoak [EMAIL PROTECTED] wrote: On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: The Struts Action Framework 1.3.4 Test Build is available to evaluate for release quality. The release plan is available on the wiki: http://wiki.apache.org/struts/StrutsActionRelease134 The test build, including checksums and signatures, has been deployed to: http://svn.apache.org/dist/struts/action/v1.3.4 Due to the concerns raised about the missing Tiles DTD registration, I'm changing my vote to Beta quality. The vote currently stands at 4 for Beta quality: Niall, Martin, Ted, Wendy 2 for GA quality: Don, Joe Therefore, Struts Action 1.3.4 will be designated Beta quality. Issue STR-2876 is open for the missing Tiles 1.1 DTD registration, and I'll start a release plan for version 1.3.5. (Would anyone like to volunteer as release manager?) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
I am uneasy with the way that Struts Scripting and Struts Tiles is being released under the 1.3.4 moniker. It doesn't make any sense to me. The reason I say this is because they are, in a kind of way, a different product. Tiles is 1.1 despite the new 1.3.4 name. It is not in its 3rd version, even if it is part of the Struts 1.3 release. It's almost like lying :-) How can we justify why there is a 1.3 DTD that looks identical to 1.1? Where are the new features that deserve its increment of versions? For this reason, I believe tiles and scripting should not belong with the struts distribution. I've tried to view them as part of the core product (which the examples and taglib align to), but I can't force myself to believe they are really 1.3 - they are 1.0.1 and 1.3. I recommend we remove them from the distribution and allow them to downloaded separately. Or, give them their real version numbers back. -- Paul --- Wendy Smoak [EMAIL PROTECTED] wrote: On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: The Struts Action Framework 1.3.4 Test Build is available to evaluate for release quality. The release plan is available on the wiki: http://wiki.apache.org/struts/StrutsActionRelease134 The test build, including checksums and signatures, has been deployed to: http://svn.apache.org/dist/struts/action/v1.3.4 Due to the concerns raised about the missing Tiles DTD registration, I'm changing my vote to Beta quality. The vote currently stands at 4 for Beta quality: Niall, Martin, Ted, Wendy 2 for GA quality: Don, Joe Therefore, Struts Action 1.3.4 will be designated Beta quality. Issue STR-2876 is open for the missing Tiles 1.1 DTD registration, and I'll start a release plan for version 1.3.5. (Would anyone like to volunteer as release manager?) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/13/06, Ted Husted [EMAIL PROTECTED] wrote: I would prefer that we resolve the DTD issue before marking a distribution ready for primetime. I agree ... and vote for beta as well. But we should spend some more time testing to see if there are any other lurking ghosts before we send Wendy off on yet another cycle through the release plan process. I see two choices. Make the two-line change to XmlParser and roll 1.3.5 immediately with *only* that change, or wait a while and see if anything else comes up. I'm trying to find the motivation for Plan A. Because if we do that, and no one objects to calling the vote immediately... we could count the vote in time for Don's talk on Wednesday. Plan B assumes that people are going to continue to test 1.3.4, and I don't know how likely that really is. Right now I just feel like I'm going to make someone unhappy, no matter what I do. Or don't do, as the case may be. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/13/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 5/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/13/06, Ted Husted [EMAIL PROTECTED] wrote: I would prefer that we resolve the DTD issue before marking a distribution ready for primetime. I agree ... and vote for beta as well. But we should spend some more time testing to see if there are any other lurking ghosts before we send Wendy off on yet another cycle through the release plan process. I see two choices. Make the two-line change to XmlParser and roll 1.3.5 immediately with *only* that change, or wait a while and see if anything else comes up. I'm trying to find the motivation for Plan A. Because if we do that, and no one objects to calling the vote immediately... we could count the vote in time for Don's talk on Wednesday. Plan B assumes that people are going to continue to test 1.3.4, and I don't know how likely that really is. Right now I just feel like I'm going to make someone unhappy, no matter what I do. Or don't do, as the case may be. I hope that I wasn't implying I would be unhappy if you were *willing* to roll 1.3.5 immediately ... that'd be fine. However, I would be unhappy with all of us other committers if we stopped testing 1.3.4 at all, until 1.3.5became available, and we surface yet another two line change next week. Where, by the way, I suspect you'll be pretty busy :-). But if you want to go for it, I'm game -- can do a small bit of testing on Monday. -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts release process is broken (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
Craig McClanahan wrote: However, I would be unhappy with all of us other committers if we stopped testing 1.3.4 at all, until 1.3.5became available, and we surface yet another two line change next week. This is exactly why I think this release process, or least least the Struts PMC implementation of it, is broken. A few Struts committers work their butts off to push out a release, clearing all known issues and repeatedly asking for help but getting none. Then, once the release is out, people nitpick through it finding issues to shoot it down (and yes, a beta is as good as a killed release because it doesn't get out to the users in an public, accessible location). Ok, we go back, fix the issues, and roll another release, only to have the same process happen again and again. Honestly, this is very discouraging and kills any momentum we get. Personally, I give up. I previously believed Struts moved so slowly because of a lack of effort, but I'm wondering if the problem isn't more profound. If, in six months with 100% dedicated committers willing to do whatever it takes and a codebase that is stable and proven, we can't push out a GA release, we have a serious problem. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: The Struts Action Framework 1.3.4 Test Build is available to evaluate for release quality. ... The test build, including checksums and signatures, has been deployed to: http://svn.apache.org/dist/struts/action/v1.3.4 Late tonight, the vote will have been open for 72 hours. Right now, I'm planning to count votes on Saturday afternoon and (assuming it has passed, which looks likely at this point,) move it over to 'dist' and onto the mirrors. Is there anyone who has plans to evaluate 1.3.4 in the near future who needs more time, or who has any other concerns about this build? I'm happy to wait longer to tally the initial vote if anyone would like me to. I could still use help with the release announcement. :) http://wiki.apache.org/struts/StrutsActionRelease134 Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/10/06, Don Brown [EMAIL PROTECTED] wrote: For the next significant release, I'm fine with waiting the extra week. As mentioned elsewhere, quality votes are not meant to be a permanent judgment. If problems are found, we can recast our votes and re-qualify the quality of the release. There's no harm in calling for a vote early, but we do have to keep in mind that if we announce too quickly, and more binding votes roll in later, we might have to issue a second announcement that the quality has been downgraded. Looking over my schedule, I won't have the opportunity to review the latest build myself this month, and so I will have to abstrain for now. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: Niall, does Monday give you enough time? Calling the vote immediately was intended to encourage testing and evaluation, not to lock people out of the process by rushing it through. As mentioned elsewhere, a release is a process that is never locked. There is no sunset clause on a quality vote. The only danger is announcing too soon. If more votes come in after the announcement, we may need to requalify the release. Likewise, if issues are discovered after the announcement, some of us might choose to change our votes. We're not creating legislation, we're making a judgment-call based on the best information available to us. If new information comes to light, our judgments may change accordingly. It is *never* too late to vote on a release. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/10/06, Don Brown [EMAIL PROTECTED] wrote: We can always recall a release We can reclassify the quality of a release, but once it hits the mirrors, it hits the mirrors, so we can't recall it per se. or throw out a new one if a major issue has been found, We can roll another 1.x release, and, hopefully, we will. But, throw out seems cavalier. I'm also concerned about language like good enough for GA. Is there something better than GA? I'm all in favor of release often and release early, especially when it comes to milestones. But, GA needs to mean as good as it gets and ready for primetime, not just good enough for JavaOne. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: I remember being involved -- it had to do with the version numbers not matching. It seems odd to use Struts Tiles 1.3 with a version 1.1 DTD. +1 There's a general expectation that the DTD release number match the product release number. If we don't keep these numbers in synch, we'll get even more questions about what happened to the 1.3 DTD. There was discussion in the Action 1.2.8 release series about making changes that would affect the struts-config DTD, and whether we could change the DTD version in a milestone release. We decided to keep the DTD version in synch with the milestone series and utilized a workaround for 1.2. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On May 10, 2006, at 10:02 PM, Wendy Smoak wrote: On 5/10/06, Niall Pemberton [EMAIL PROTECTED] wrote: I missed the discussion where the 1.3 dtd was added - seems like its actually identical to the 1.1 dtd - which IMO serves no purpose. I would rather it was removed. I remember being involved -- it had to do with the version numbers not matching. It seems odd to use Struts Tiles 1.3 with a version 1.1 DTD. Here's the commit message. The registration was changed instead of a new one being added. I see no reason not to add it back. http://marc.theaimsgroup.com/?l=struts-devm=113098757610401w=2 Looks like I'm the one who did that. For the life of me I can't remember exactly why. It seems like it had something to do with complaints about the load on apache servers b/c there were a lot of requests for the 1.3 dtd (or the 1.1 dtd). But I thought the end result was to *add* the 1.3 dtd not change the 1.1 dtd to 1.3. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/11/06, Ted Husted [EMAIL PROTECTED] wrote: On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: Niall, does Monday give you enough time? Calling the vote immediately was intended to encourage testing and evaluation, not to lock people out of the process by rushing it through. As mentioned elsewhere, a release is a process that is never locked. There is no sunset clause on a quality vote. The only danger is announcing too soon. If more votes come in after the announcement, we may need to requalify the release. Likewise, if issues are discovered after the announcement, some of us might choose to change our votes. We're not creating legislation, we're making a judgment-call based on the best information available to us. If new information comes to light, our judgments may change accordingly. It is *never* too late to vote on a release. It was a poor choice of words. I was responding to this: Niall wrote: I don't have much time available at the moment, but I was hoping to try and check out this version by the weekend. Whether I'll get round to that I'm not sure, but it looks pretty academic since it'll have probably been voted GA by then :-( While it's true you can always change or add a vote, the perception is that it's done once the vote is tallied and the announcement is made. There was no deadline in the call for a vote on 1.3.4. I don't want to announce this before everyone who wants to test it has done so. In addition to Niall, I'm really hoping Martin and Craig will have time to take a look. We can roll another 1.x release, and, hopefully, we will. But, throw out seems cavalier. While Maven 2 makes it easier than ever to roll a release, I was up until after 1 AM both Monday night for the new snapshot and Tuesday night for the 1.3.4 test build. These are _not_ just tossed out there to see if they work or not. I'm also concerned about language like good enough for GA. Is there something better than GA? Well, yes. The *next* GA release should be better than the first one. I'm all in favor of release often and release early, especially when it comes to milestones. But, GA needs to mean as good as it gets and ready for primetime, not just good enough for JavaOne. So far, the only issues I know of are the missing Tiles DTD registration, and some problems with Struts Faces and its example apps. (And I'm still unhappy that we've lost the taglib Cactus tests.) It's never going to be perfect. I checked and rechecked everything I could think of or 1.3.3... and missed the problems with the jar file manifests and the Tiles jar. I did the same thing for 1.3.4, and never tested it with an old Tiles DTD. And I'm sure that as soon as the users get ahold of it, they'll find some things that none of us noticed. Having a goal to announce at JavaOne helped drive the process forward, but we've been working towards a GA release of 1.3 for a long time now. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/11/06, Ted Husted [EMAIL PROTECTED] wrote: On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: I remember being involved -- it had to do with the version numbers not matching. It seems odd to use Struts Tiles 1.3 with a version 1.1 DTD. +1 There's a general expectation that the DTD release number match the product release number. If we don't keep these numbers in synch, we'll get even more questions about what happened to the 1.3 DTD. Well we haven't had a 1.2 DTD for tiles and I can't recall it ever being raised on the user list as an issue. People seem to have quite happily upgraded to Struts 1.2 and continued used the Tiles 1.1 DTD. However we do frequently get questions about offline DTD's - AFAIK this is always when someone has an incorrect !DOCTYPE declaration. Not having the Tiles 1.1 DTD registered I believe will increase these types of questions on the user list. Add to that the fact that it will increase the load on Apache servers for people who don't upgrade to the 1.3 DTD, which isn't going to make infrastructure happy, I think we should fix this. There was discussion in the Action 1.2.8 release series about making changes that would affect the struts-config DTD, and whether we could change the DTD version in a milestone release. We decided to keep the DTD version in synch with the milestone series and utilized a workaround for 1.2. Having a 1.3 DTD thats identical to the 1.1 DTD means (IMO) that the tiles DTD is now locked down for the 1.3 series. If someone wants to change the Tiles 1.3 DTD for some enhancement then this will be an issue. If we don't have a 1.3 DTD at the moment, then it leaves scope to add it with some changes later in the 1.3.x series. So I think this is an argument for getting rid of the 1.3 Tiles DTD. To summarise then my vote is beta because I believe I think we're introducing an uncessaey PITA for users upgrading and it will increase questions on the user list and put additional load on the Apache Servers. My preference to fix this is to removed the 1.3 DTD and correct the registraiton back to the 1.1 DTD. I have taken some time to check out the 1.3.4 version today - upgrading my webapp to this version (was on 1.2.9) and the only other issue(s) I came up with is that we used to distribute things like the validator-rules.xml config and taglib tlds in the lib directory. I releaize that these are now all packaged in the jar and the distro does include the source - but I expect quite a few people will still have these manually configured and will have difficulty finding them in the distro. Also the new chain-config.xml - which any tiles user (like myself) needs to be readily available so that the tiles commands can be added. Again its difficult to find the chain-config.xml and it seems that the *commented out* tiles commands have been removed. We should make it easy to find the chain-config.xml and easy to configure for tiles (by adding back the commented commands). Niall -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
Niall Pemberton wrote: To summarise then my vote is beta because I believe I think we're introducing an uncessaey PITA for users upgrading and it will increase questions on the user list and put additional load on the Apache Servers. I absolutely disagree. To be GA quality, it doesn't have to be perfect as we'll always keep finding issues. This should be something that is ticketed and marked against the next release, hopefully GA as well. Furthermore, this is such a small issue to pull back an entire release is way overkill. I think we should adjust any documentation to only mention the 1.1 DTD, and perhaps add the 1.3 DTD information as an errata. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/11/06, Don Brown [EMAIL PROTECTED] wrote: Furthermore, this is such a small issue to pull back an entire release is way overkill. A release can't be vetoed. As long as there are more binding GAs than binding something-elses, it's GA. We each have earned the right to express our own opinions as to the build quality, good, bad, or indifferent. There are already 3 binding GA votes, so, at this point in time, v1.3.4 is already GA. It's just a matter of when the release managers choose to announce the status of the vote. (Which could always change later, if wider usage exposes an issue that causes people to change their vote.) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/11/06, Don Brown [EMAIL PROTECTED] wrote: Niall Pemberton wrote: To summarise then my vote is beta because I believe I think we're introducing an uncessaey PITA for users upgrading and it will increase questions on the user list and put additional load on the Apache Servers. I absolutely disagree. To be GA quality, it doesn't have to be perfect as we'll always keep finding issues. This should be something that is ticketed and marked against the next release, hopefully GA as well. Furthermore, this is such a small issue to pull back an entire release is way overkill. I agree it doesn't have to be perfect, but I also think its not just about code. Something that might cause alot of user questions and add uncessary infrastructure burden are valid points IMO. Also my argument is against having a 1.3 DTD - once its in a GA release we can't take it back. Historically GA releases are a long time out there and IMO this is worth rolling another version. One of the reasons 1.3.3 was only voted beta was because of missing DTD's - I don't see this as much different to that - since if its not registered, then its as good as missing. Anyway, I put forward my arguments for beta - but I see nothing to change my mind on that since this is trivial doesn't persuade me to think differently. Niall I think we should adjust any documentation to only mention the 1.1 DTD, and perhaps add the 1.3 DTD information as an errata. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/11/06, Ted Husted [EMAIL PROTECTED] wrote: On 5/11/06, Don Brown [EMAIL PROTECTED] wrote: Furthermore, this is such a small issue to pull back an entire release is way overkill. A release can't be vetoed. As long as there are more binding GAs than binding something-elses, it's GA. We each have earned the right to express our own opinions as to the build quality, good, bad, or indifferent. There are already 3 binding GA votes, so, at this point in time, v1.3.4 is already GA. It's just a matter of when the release managers choose to announce the status of the vote. (Which could always change later, if wider usage exposes an issue that causes people to change their vote.) Actually its not since the vote is only one day old - I assume we're at least sticking to the +72 hours convention - even when no time has been given between publishing the version and calling the vote. Niall -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
I have taken some time to check out the 1.3.4 version today - upgrading my webapp to this version (was on 1.2.9) and the only other issue(s) I came up with is that we used to distribute things like the validator-rules.xml config and taglib tlds in the lib directory. I releaize that these are now all packaged in the jar and the distro does include the source - but I expect quite a few people will still have these manually configured and will have difficulty finding them in the distro. I'm mixed about this; I find them cluttery. I guess if we've never warned people before, then you're probably right, but I'm inclined to try to deprecate them and steer people towards not expecting them in the WEB-INF dir. Not something I feel very strongly about, but it's my taste... Also the new chain-config.xml - which any tiles user (like myself) needs to be readily available so that the tiles commands can be added. Again its difficult to find the chain-config.xml and it seems that the *commented out* tiles commands have been removed. We should make it easy to find the chain-config.xml and easy to configure for tiles (by adding back the commented commands). I had been thinking that the preferred strategy was to steer people to change their config to read org/apache/struts/tiles/chain-config.xml from the classpath (included in struts-tiles-1.3.4.jar). I admit to ambivalence about this vs. the uncomment these lines strategy, but since by default most people wouldn't have removed the chain-config.xml from the ZIP, I think it's easier to say change this in web.xml than unpack this thing from web.xml and then edit it. Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new. -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
Joe Germuska wrote: I have taken some time to check out the 1.3.4 version today - upgrading my webapp to this version (was on 1.2.9) and the only other issue(s) I came up with is that we used to distribute things like the validator-rules.xml config and taglib tlds in the lib directory. I releaize that these are now all packaged in the jar and the distro does include the source - but I expect quite a few people will still have these manually configured and will have difficulty finding them in the distro. I'm mixed about this; I find them cluttery. I guess if we've never warned people before, then you're probably right, but I'm inclined to try to deprecate them and steer people towards not expecting them in the WEB-INF dir. Not something I feel very strongly about, but it's my taste... I agree completely. We need to continue to push to make Struts easier, which includes less configuration files to know about/edit. Since the example applications are targeted towards new users, it is especially important to show a minimal footprint to encourage simple development practices. Making simple things easy and the difficult things possible comes to mind :) Personally, I want to see us require _no_ XML configuration, eventually embedding a heavily wildcarded struts-config.xml in the jar to cover most basic cases, but that's another discussion... :) Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/11/06, Niall Pemberton [EMAIL PROTECTED] wrote: I have taken some time to check out the 1.3.4 version today - upgrading my webapp to this version (was on 1.2.9) and the only other issue(s) I came up with is that we used to distribute things like the validator-rules.xml config and taglib tlds in the lib directory. I releaize that these are now all packaged in the jar and the distro does include the source - but I expect quite a few people will still have these manually configured and will have difficulty finding them in the distro. First, thank you for taking the time to review 1.3.4. I really appreciate it. I thought about including those resources, and decided against it. They were not in the 1.3.0 'lib' distribution, either. I'm willing to answer the questions on the user list, and I think we should encourage people to configure their apps to use the latest versions of the resources that we've provided in the jar files. Since we now require Servlet 2.3, there's little reason to configure tlds in web.xml, and there's no reason to keep a copy of validator-rules.xml in WEB-INF when it can be loaded from struts-core.jar. We can include them in 'lib' in the next distribution if more people disagree. (But as you pointed out, they are included with the source.) Also the new chain-config.xml - which any tiles user (like myself) needs to be readily available so that the tiles commands can be added. ... Again its difficult to find the chain-config.xml and it seems that the *commented out* tiles commands have been removed. We should make it easy to find the chain-config.xml and easy to configure for tiles (by adding back the commented commands). The easiest way to configure for Tiles is to use the chain config file that we provide in struts-tiles.jar. I don't think users should be encouraged to edit the default chain config file to add Tiles commands, but we could add a comment with an example of configuring oas/tiles/chain-config.xml. It's on the upgrade Wiki page (section 4.1). Does it need to be more prominent? * http://wiki.apache.org/struts/StrutsUpgradeNotes12to13 My guess is that most Tiles users will still have the old TilesRequestProcessor configured, I know it took me a while to figure out why the ComposableRequestProcessor wasn't being used! Don wrote: I think we should adjust any documentation to only mention the 1.1 DTD, and perhaps add the 1.3 DTD information as an errata. It's the other way around: only the Struts Tiles 1.3 DTD is registered, so it's the one that should be documented. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/11/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 5/11/06, Niall Pemberton [EMAIL PROTECTED] wrote: I have taken some time to check out the 1.3.4 version today - upgrading my webapp to this version (was on 1.2.9) and the only other issue(s) I came up with is that we used to distribute things like the validator-rules.xml config and taglib tlds in the lib directory. I releaize that these are now all packaged in the jar and the distro does include the source - but I expect quite a few people will still have these manually configured and will have difficulty finding them in the distro. First, thank you for taking the time to review 1.3.4. I really appreciate it. No problem, its a minor contribution compared to your efforts to get a 1.3.x version out - thanks for that. Apologies if you think I'm being a PITA. I thought about including those resources, and decided against it. They were not in the 1.3.0 'lib' distribution, either. I'm willing to answer the questions on the user list, and I think we should encourage people to configure their apps to use the latest versions of the resources that we've provided in the jar files. Since we now require Servlet 2.3, there's little reason to configure tlds in web.xml, and there's no reason to keep a copy of validator-rules.xml in WEB-INF when it can be loaded from struts-core.jar. We can include them in 'lib' in the next distribution if more people disagree. (But as you pointed out, they are included with the source.) No, I'm persuaded by yours, Joe's and Don's argument on this that we should be pushing users to not configure these manually. Also the new chain-config.xml - which any tiles user (like myself) needs to be readily available so that the tiles commands can be added. ... Again its difficult to find the chain-config.xml and it seems that the *commented out* tiles commands have been removed. We should make it easy to find the chain-config.xml and easy to configure for tiles (by adding back the commented commands). The easiest way to configure for Tiles is to use the chain config file that we provide in struts-tiles.jar. I don't think users should be encouraged to edit the default chain config file to add Tiles commands, but we could add a comment with an example of configuring oas/tiles/chain-config.xml. I agree - sorry I didn't realize there was a tiles version of the chain-config.xml It's on the upgrade Wiki page (section 4.1). Does it need to be more prominent? * http://wiki.apache.org/struts/StrutsUpgradeNotes12to13 I don't think so - I just didn't read them :-( My guess is that most Tiles users will still have the old TilesRequestProcessor configured, I know it took me a while to figure out why the ComposableRequestProcessor wasn't being used! Don wrote: I think we should adjust any documentation to only mention the 1.1 DTD, and perhaps add the 1.3 DTD information as an errata. It's the other way around: only the Struts Tiles 1.3 DTD is registered, so it's the one that should be documented. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/11/06, Wendy Smoak [EMAIL PROTECTED] wrote: Since we now require Servlet 2.3, there's little reason to configure tlds in web.xml, and there's no reason to keep a copy of validator-rules.xml in WEB-INF when it can be loaded from struts-core.jar. We can include them in 'lib' in the next distribution if more people disagree. (But as you pointed out, they are included with the source.) I think it is much cleaner to have DTDs and other default XML files in the JAR, but sometimes it might not work. The hosting that I use for the samples, uses Tomcat 4.x, which supposedly should support SRV 2.3 and therefore it should be able to pull DTDs from classpath. Yet, this does not work, I don't know exactly why. But if I put DTD files into lib directory and configure them in web.xml then everything works fine. The bottom line, it is better to hide DTDs in the JAR, but in case it does not work a readily available HOW-TO should be provided. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/11/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 5/11/06, Niall Pemberton [EMAIL PROTECTED] wrote: I have taken some time to check out the 1.3.4 version today - upgrading my webapp to this version (was on 1.2.9) and the only other issue(s) I came up with is that we used to distribute things like the validator-rules.xml config and taglib tlds in the lib directory. I releaize that these are now all packaged in the jar and the distro does include the source - but I expect quite a few people will still have these manually configured and will have difficulty finding them in the distro. First, thank you for taking the time to review 1.3.4. I really appreciate it. I thought about including those resources, and decided against it. They were not in the 1.3.0 'lib' distribution, either. I'm willing to answer the questions on the user list, and I think we should encourage people to configure their apps to use the latest versions of the resources that we've provided in the jar files. +1 on the recommended configuration approach (use the canonical URLs instead of references to explicit resources in WEB-INF). Since we now require Servlet 2.3, there's little reason to configure tlds in web.xml, and there's no reason to keep a copy of validator-rules.xml in WEB-INF when it can be loaded from struts-core.jar. We can include them in 'lib' in the next distribution if more people disagree. (But as you pointed out, they are included with the source.) I think we should include the DTDs in some convenient place like lib in the distro in *addition* to the previous comments on recommended configuration practices. There's lots of documentation about valid options in the DTD documents themselves that is not reproduced anywhere else. It should be as easy as possible to get to these files for *reading* them, not just for using them in an app. Craig
[OT] reading resources from nested JARs (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
At 10:50 AM -0700 5/11/06, Michael Jouravlev wrote: I think it is much cleaner to have DTDs and other default XML files in the JAR, but sometimes it might not work. The hosting that I use for the samples, uses Tomcat 4.x, which supposedly should support SRV 2.3 and therefore it should be able to pull DTDs from classpath. Yet, this does not work, I don't know exactly why. But if I put DTD files into lib directory and configure them in web.xml then everything works fine. Do you deploy your webapps as WARs? We often find ourselves bumping up against something when we need to read classpath resources from a JAR within another JAR; in fact, this is why we don't deploy webapps as WARs, and we've also had similar problems with the classworlds uberjar mechanism which makes JARs for standalone execution along a model similar to WARs. Has anyone ever seen formal documentation of this issue? We've always just worked around it. The bottom line, it is better to hide DTDs in the JAR, but in case it does not work a readily available HOW-TO should be provided. Indeed. -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new. -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] reading resources from nested JARs (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
On 5/11/06, Joe Germuska [EMAIL PROTECTED] wrote: At 10:50 AM -0700 5/11/06, Michael Jouravlev wrote: I think it is much cleaner to have DTDs and other default XML files in the JAR, but sometimes it might not work. The hosting that I use for the samples, uses Tomcat 4.x, which supposedly should support SRV 2.3 and therefore it should be able to pull DTDs from classpath. Yet, this does not work, I don't know exactly why. But if I put DTD files into lib directory and configure them in web.xml then everything works fine. Do you deploy your webapps as WARs? We often find ourselves bumping up against something when we need to read classpath resources from a JAR within another JAR; in fact, this is why we don't deploy webapps as WARs, and we've also had similar problems with the classworlds uberjar mechanism which makes JARs for standalone execution along a model similar to WARs. Has anyone ever seen formal documentation of this issue? We've always just worked around it. The particular version of Tomcat used by this hosting provider is broken ( i.e. it has bugs) with reference to this issue -- it is supposed to work. And I know from experience it works correctly on 5.0.x versions. Craig The bottom line, it is better to hide DTDs in the JAR, but in case it does not work a readily available HOW-TO should be provided. Indeed. -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new. -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/11/06, Craig McClanahan [EMAIL PROTECTED] wrote: I think we should include the DTDs in some convenient place like lib in the distro in *addition* to the previous comments on recommended configuration practices. There's lots of documentation about valid options in the DTD documents themselves that is not reproduced anywhere else. It should be as easy as possible to get to these files for *reading* them, not just for using them in an app. I think that's an argument for adding them to the included website docs. We do have the DTDs (and LiveDTD docs) on the main site, but not under s.a.o/struts-action, which is what we include in the distribution. A Maven plugin for DTDDoc would be nice: http://dtddoc.sourceforge.net/ Prior to that we could just copy them into struts-action/target/site/dtds during the website build and link to them. (That will duplicate them on the published site, which we could probably eliminate with some mod_rewrite magic.) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/11/06, Niall Pemberton [EMAIL PROTECTED] wrote: No problem, its a minor contribution compared to your efforts to get a 1.3.x version out - thanks for that. Apologies if you think I'm being a PITA. I don't think that at all. We may differ on whether a particular issue is reason enough to withhold GA status from a build, but I really do want to know if you find anything of concern.I'd much rather hear about it now than from a user after an announcement. Since minotaur has been periodically unavailable, here's the link again in case anyone wasn't able to download the test build the first time: * http://svn.apache.org/dist/struts/action/v1.3.4 Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
GA - This looks really good Wendy, thanks again for the hard work! Don Wendy Smoak wrote: The Struts Action Framework 1.3.4 Test Build is available to evaluate for release quality. The release plan is available on the wiki: http://wiki.apache.org/struts/StrutsActionRelease134 The test build, including checksums and signatures, has been deployed to: http://svn.apache.org/dist/struts/action/v1.3.4 In addition, all jars, webapps, sources and javadocs are available in Apache's Maven snapshot repository under groupId 'org.apache.struts.action'. http://cvs.apache.org/maven-snapshot-repository Since 1.3.3, the following issues have been resolved: * [STR-2795] - Postback Forms - Caching and Modules * [STR-2866] - Struts Tiles jar is missing dtd, tld and chain config files * [STR-2867] - Dependency problems in faces-example2 sample app (using Tiles) * [STR-2870] - The Specification-Title in the jar file manifests is corrupted * [STR-2872] - Section 4.3.3 Map-backed ActionForms of User's Manual contains a dead link * [STR-2871] - Rename the release notes so that the filename contains a single period Known issues in 1.3.4: * struts-faces-example2 deploys but the links do not work Once you have had a chance to review this test build, please respond with a vote on its quality: [ ] Alpha [ ] Beta [ ] General Availability (GA) We welcome votes from all community members, however, only the votes of Struts PMC members are binding. My vote is for GA quality. I've had 1.3 in production for eight months with no problems, and I believe we've resolved all of the packaging issues discovered since converting to Maven 2 and reorganizing the project. -- Wendy Smoak - 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]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
This seems like the smallest of things, but the distribution includes struts-core-1.3.4.jar and not struts-action-1.3.4.jar. I thought we'd decided to change that? The upgrade notes wiki page refers to struts-action: http://wiki.apache.org/struts/StrutsUpgradeNotes12to13 Like Wendy, I've had 1.3 based code in production for months, so I'm GA on the code -- as for whether the above is an important packaging problem or just something that needs to be updated in docs, I'll defer. Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new. -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
I didn't know we decided to change that, as it has repercussions all throughout the Maven build. I'm fine with us changing it for the next release, but I certainly don't think it should stand in the way of this one. Don Joe Germuska wrote: This seems like the smallest of things, but the distribution includes struts-core-1.3.4.jar and not struts-action-1.3.4.jar. I thought we'd decided to change that? The upgrade notes wiki page refers to struts-action: http://wiki.apache.org/struts/StrutsUpgradeNotes12to13 Like Wendy, I've had 1.3 based code in production for months, so I'm GA on the code -- as for whether the above is an important packaging problem or just something that needs to be updated in docs, I'll defer. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/10/06, Joe Germuska [EMAIL PROTECTED] wrote: This seems like the smallest of things, but the distribution includes struts-core-1.3.4.jar and not struts-action-1.3.4.jar. I thought we'd decided to change that? The upgrade notes wiki page refers to struts-action: http://wiki.apache.org/struts/StrutsUpgradeNotes12to13 We decided to call the entire subproject Struts Action (rather than Struts Core or Struts Classic). That individual artifactId was changed back to struts-core during the Maven reorganization. I'm fairly sure I mentioned it on the list, but I'm having trouble finding messages that talk about struts-core and struts-action among all the commit messages in the archives. In summary, struts-core.jar contains the core of the Action framework. Eventually, I would like to have a 'struts-action.jar' that contains the _entire_ framework, the equivalent of 'struts.jar' from the 1.2 branch, or the Spring framework's full 'spring.jar'. Like Wendy, I've had 1.3 based code in production for months, so I'm GA on the code -- as for whether the above is an important packaging problem or just something that needs to be updated in docs, I'll defer. IMO we just need to fix the upgrade notes. Can I count you as +1, or does this need further discussion? Don, I think the Maven build is fine; the artifactId has been struts-core for quite a while. I'd say how long, but minotaur seems to be down again so I can't check the svn log. :( Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
At 11:21 AM -0700 5/10/06, Wendy Smoak wrote: On 5/10/06, Joe Germuska [EMAIL PROTECTED] wrote: This seems like the smallest of things, but the distribution includes struts-core-1.3.4.jar and not struts-action-1.3.4.jar. I thought we'd decided to change that? The upgrade notes wiki page refers to struts-action: http://wiki.apache.org/struts/StrutsUpgradeNotes12to13 We decided to call the entire subproject Struts Action (rather than Struts Core or Struts Classic). That individual artifactId was changed back to struts-core during the Maven reorganization. I'm fairly sure I mentioned it on the list, but I'm having trouble finding messages that talk about struts-core and struts-action among all the commit messages in the archives. In summary, struts-core.jar contains the core of the Action framework. Eventually, I would like to have a 'struts-action.jar' that contains the _entire_ framework, the equivalent of 'struts.jar' from the 1.2 branch, or the Spring framework's full 'spring.jar'. I'm fine on this -- in fact, I think that struts-action implies what you described, and it's better to keep what's now known as struts-core from usurping that name! Can I count you as +1, or does this need further discussion? +1 GA But I just noticed something else; for some reason the registration of the Tiles 1.1 DTD was removed, even though I don't know of anything that makes Tiles unable to function if one has a valid-according-to-that-DTD tiles-definitions.xml. Given that at this moment we appear to be having systems problems with apache.org machines, this is annoying; is there any reason not to restore that registration? The 1.1 DTD is included in the JAR; it's just not registered in XmlParser. I don't think this qualifies as a reason not to grant GA status. Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new. -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/10/06, Joe Germuska [EMAIL PROTECTED] wrote: At 11:21 AM -0700 5/10/06, Wendy Smoak wrote: On 5/10/06, Joe Germuska [EMAIL PROTECTED] wrote: This seems like the smallest of things, but the distribution includes struts-core-1.3.4.jar and not struts-action-1.3.4.jar. I thought we'd decided to change that? The upgrade notes wiki page refers to struts-action: http://wiki.apache.org/struts/StrutsUpgradeNotes12to13 We decided to call the entire subproject Struts Action (rather than Struts Core or Struts Classic). That individual artifactId was changed back to struts-core during the Maven reorganization. I'm fairly sure I mentioned it on the list, but I'm having trouble finding messages that talk about struts-core and struts-action among all the commit messages in the archives. In summary, struts-core.jar contains the core of the Action framework. Eventually, I would like to have a 'struts-action.jar' that contains the _entire_ framework, the equivalent of 'struts.jar' from the 1.2 branch, or the Spring framework's full 'spring.jar'. I'm fine on this -- in fact, I think that struts-action implies what you described, and it's better to keep what's now known as struts-core from usurping that name! Can I count you as +1, or does this need further discussion? +1 GA But I just noticed something else; for some reason the registration of the Tiles 1.1 DTD was removed, even though I don't know of anything that makes Tiles unable to function if one has a valid-according-to-that-DTD tiles-definitions.xml. I missed the discussion where the 1.3 dtd was added - seems like its actually identical to the 1.1 dtd - which IMO serves no purpose. I would rather it was removed. Given that at this moment we appear to be having systems problems with apache.org machines, this is annoying; is there any reason not to restore that registration? The 1.1 DTD is included in the JAR; it's just not registered in XmlParser. Since only the new identical 1.3 dtd is registered, looks like were going to force any tiles users whose apps don't have www access into an unecessary upgrade. For those with www access who don't upgrade, its going to mean more load on the Apache servers. I don't think this qualifies as a reason not to grant GA status. Maybe not, but it doesn't make us look v.smart when we explain that ...there isn't anything new/changed in the 1.3 dtd, but you should upgrade, otherwise it won't use the local copy in the jar. Niall Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
In the past we've made a new version available for people to check out for a period of time (my preference is at least a week) before calling a vote. I'm against this process of publishing and calling a vote immediately as I believe it increases the chance of a build with problems being voted GA. I don't have much time available at the moment, but I was hoping to try and check out this version by the weekend. Whether I'll get round to that I'm not sure, but it looks pretty academic since it'll have probably been voted GA by then :-( Niall On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: The Struts Action Framework 1.3.4 Test Build is available to evaluate for release quality. The release plan is available on the wiki: http://wiki.apache.org/struts/StrutsActionRelease134 The test build, including checksums and signatures, has been deployed to: http://svn.apache.org/dist/struts/action/v1.3.4 In addition, all jars, webapps, sources and javadocs are available in Apache's Maven snapshot repository under groupId 'org.apache.struts.action'. http://cvs.apache.org/maven-snapshot-repository Since 1.3.3, the following issues have been resolved: * [STR-2795] - Postback Forms - Caching and Modules * [STR-2866] - Struts Tiles jar is missing dtd, tld and chain config files * [STR-2867] - Dependency problems in faces-example2 sample app (using Tiles) * [STR-2870] - The Specification-Title in the jar file manifests is corrupted * [STR-2872] - Section 4.3.3 Map-backed ActionForms of User's Manual contains a dead link * [STR-2871] - Rename the release notes so that the filename contains a single period Known issues in 1.3.4: * struts-faces-example2 deploys but the links do not work Once you have had a chance to review this test build, please respond with a vote on its quality: [ ] Alpha [ ] Beta [ ] General Availability (GA) We welcome votes from all community members, however, only the votes of Struts PMC members are binding. My vote is for GA quality. I've had 1.3 in production for eight months with no problems, and I believe we've resolved all of the packaging issues discovered since converting to Maven 2 and reorganizing the project. -- Wendy Smoak - 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]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
Normally, I'd agree with you but: a) This is the latest in a succession of very recent releases so little has changed (last one was Sunday) b) Theoretically people test during that week, but in practice few do. Seems people don't pay attention until a vote is called We can always recall a release or throw out a new one if a major issue has been found, but as I've said, this is the same code that has been there for months and yes, I dare say years. We've been spending all our time (way too much porportionally, IMO) on the build and site, but the code has been very stable. For the next significant release, I'm fine with waiting the extra week. Don Niall Pemberton wrote: In the past we've made a new version available for people to check out for a period of time (my preference is at least a week) before calling a vote. I'm against this process of publishing and calling a vote immediately as I believe it increases the chance of a build with problems being voted GA. I don't have much time available at the moment, but I was hoping to try and check out this version by the weekend. Whether I'll get round to that I'm not sure, but it looks pretty academic since it'll have probably been voted GA by then :-( Niall On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: The Struts Action Framework 1.3.4 Test Build is available to evaluate for release quality. The release plan is available on the wiki: http://wiki.apache.org/struts/StrutsActionRelease134 The test build, including checksums and signatures, has been deployed to: http://svn.apache.org/dist/struts/action/v1.3.4 In addition, all jars, webapps, sources and javadocs are available in Apache's Maven snapshot repository under groupId 'org.apache.struts.action'. http://cvs.apache.org/maven-snapshot-repository Since 1.3.3, the following issues have been resolved: * [STR-2795] - Postback Forms - Caching and Modules * [STR-2866] - Struts Tiles jar is missing dtd, tld and chain config files * [STR-2867] - Dependency problems in faces-example2 sample app (using Tiles) * [STR-2870] - The Specification-Title in the jar file manifests is corrupted * [STR-2872] - Section 4.3.3 Map-backed ActionForms of User's Manual contains a dead link * [STR-2871] - Rename the release notes so that the filename contains a single period Known issues in 1.3.4: * struts-faces-example2 deploys but the links do not work Once you have had a chance to review this test build, please respond with a vote on its quality: [ ] Alpha [ ] Beta [ ] General Availability (GA) We welcome votes from all community members, however, only the votes of Struts PMC members are binding. My vote is for GA quality. I've had 1.3 in production for eight months with no problems, and I believe we've resolved all of the packaging issues discovered since converting to Maven 2 and reorganizing the project. -- Wendy Smoak - 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]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/10/06, Niall Pemberton [EMAIL PROTECTED] wrote: I missed the discussion where the 1.3 dtd was added - seems like its actually identical to the 1.1 dtd - which IMO serves no purpose. I would rather it was removed. I remember being involved -- it had to do with the version numbers not matching. It seems odd to use Struts Tiles 1.3 with a version 1.1 DTD. Here's the commit message. The registration was changed instead of a new one being added. I see no reason not to add it back. http://marc.theaimsgroup.com/?l=struts-devm=113098757610401w=2 I don't have much time available at the moment, but I was hoping to try and check out this version by the weekend. Whether I'll get round to that I'm not sure, but it looks pretty academic since it'll have probably been voted GA by then :-( Especially with minotaur being down (so no one can download the test build) I'm fine with holding the vote open longer. In fact I was going to ask if there was anyone who _does_ intend to test it but needs more time. I doubt this build is perfect. Based on my testing, I think it's good enough for GA. However, the *last* thing I want to do is have to recall a release, so I'd rather wait until everyone has had a chance to test it. Assuming the vote is successful, I think Don would like to announce it at JavaOne. I'm not sure what kind of access I'll have from there, so if we let the vote go past the weekend, I might need help getting the distribution moved over to www.apache.org/dist and the download page updated. I definitely need help with the release announcement. And we still have to figure out how to get the jars from the snapshot and test build Maven repo over to www.apache.org/dist/maven-repository. (It's not as simple as copying them over, and I'm uncomfortable with the idea of re-building them, which Maven would do if I changed the repository in the pom and re-'mvn deploy'ed them.) Niall, does Monday give you enough time? Calling the vote immediately was intended to encourage testing and evaluation, not to lock people out of the process by rushing it through. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
