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: Wiki and User Guide
Well, there is a link to the upgraders wiki page in the Release Notes, so it's "incorporated by reference." I added a bullet to help emphasize the link. One reason the content on the updgrader pages is so useful is because it's easy for developers to update it. The other documenation is kept in XML, and if we changed the format, we'd probably reduce feedback. Likewise, if we put some of it under XML, we'd end up with two versions of the page to manage. Projects like WebWork and Geronimo, among others, have been experimenting with making wiki docs the "first-class documentation" that is bundled with the distribution. Wiki's like Confluence have some nice export capabilities, which opens the door to exporting the wiki into HTML. Geronimo is experiment with continuous automatic exports of Confluence pages, so that we can have the beneifts of a wiki and the efficiency of static HTML. WebWork/Action2 also uses a "snippet" macro to incorporate text from Javadocs and example programs directly into the wiki pages. I'm a big fan of this idea, since it will let us dual-use some of the very excellent Javadocs we already have. The big downside right now is that Confluence edits are atomic to each page. We can't make batch updates, which creates a lot of email churn when making sweeping changes. Instead of one email overviewing changes to a dozen pages, we all get a dozen individual emails :( There's also ongoing work in backing a wiki with Subversion, so that you could commit changes from the SVN CLI or TortoiseSVN, instead of plowing through the web interface. In the meantime, yes, we should continue to look for places where we can cross-reference the wiki with the static documentation and try to make sure those links are as visible as possible. But, we would want to be careful what we move from the wiki to the static pages, since the static pages are harder to maintaine. -Ted. On 5/16/06, Paul Benedict <[EMAIL PROTECTED]> wrote: I think it would be a good idea if we either linked or transfered some content from the Wiki pages to the user guide. For instance, I just read the upgrade notes on 1.2.9 on the wiki and it is fabulous. Those kind of things should be first-class documents in our website. Any thoughts about this proposal? - 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: API updates and build fix...
The name changes resolve the ambiguities that I saw in the first draft so that is a definite positive. The Messages.Severity enum and other messaging improvements are a definite positive. (They satisfy my desire for a Log4J type usage but are still distinct enough to avoid confusion.) Since the last API discussion the Attribute stuff is quite a bit more clear and I do think it is an advancement over MAP based interactions with bound data. (Session, Application, Request, etc) The only question I have is about the ThreadLocalRequestContext. With XWork I currently have a custom XML Dispatcher that allows actions and parameters to be read and executed from an XML document. When invoked from a file upload I provide an option to use the existing context or create a new one via a bit of trickery with the threadLocal and ActionContext. With the new API I'm assuming I could use ThreadLocalRequestContext to store a context in a variable, create a new one and invoke an action (or actions) with the new context, then restore the original context and return back to the original dispatcher? Assuming the above is true it would seem pretty easy to use ThreadLocalRequestContext. to serialize the data and provide a simple implementation of Continuations. Or have I steered wrong somewhere? Cheers, Eric On 5/16/06, Bob Lee <[EMAIL PROTECTED]> wrote: We've been cleaning up and reorganizing the API to make it more intuitive and user friendly. Any feedback is much appreciated. Bob On 5/16/06, Paul Benedict <[EMAIL PROTECTED]> wrote: > I don't remember an SPI being part of WW. Is this new to Action 2? > > --- Bob Lee <[EMAIL PROTECTED]> wrote: > > > I've attached a patch with the API updates we discussed last week. I > > also fixed the Maven build to correctly build the API again. > > > > The latest Javadocs are here: http://www.crazybob.org/javadoc/ > > > > Thanks, > > Bob > > > > > - > > 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] > > - 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]
