The documentation refactorings are going well, but I'd like to set that aside for now and hop over to the Applications subproject, which is mentioned from time to time on the other docs.
If anyone wants to jump in on the docs, please feel free. There's enough done now to set the direction for the rest. Contributions from non-committers are also welcome. Patches work just as well against XML as they do against Java source :) -Ted. On 7/30/05, Ted Husted <[EMAIL PROTECTED]> wrote: > Basically, all we need to do is > > * address any outstanding problem reports, > * update the release notes, > * test, > * tag, > * roll, > * post, and > * vote. > > If the release is voted past test build, then we can sign it and link > it from the website. > > If the release makes GA, or will be widely distributed, then we can > enter into the mirroring system. > > Of course, the more often we release, the easier this guantlet > becomes. If the volunteers had time, and there were changes to > distribute, we've often said that we'd like to release every few > weeks, > > But, first things first, we should resolve the problem reports and roll 1.3.0. > > I went through the short list last night and pruned a couple that were > resolved or redundant. > > The rest seem to have patches or coding advice that we could follow. > Off hand, I don't see any problem with applying the rest of the > tickets, so we should start doing that as we have time. > > When you are ready to code, just post a comment to the ticket that you > are applying the fix now, and have at it. I won't get back to this > myself until early Monday morning, but then I can devote some time > each weekday morning. (It would be a great Monday morning surprise to > come back and find everything resolved!) > > For the 1.3.0 release, I think addressing the problem tickets is > enough. But, for 1.3.1, we should also take a look at any enhancement > reports with patches. > > At some point, we should reduce the enhancement reports *without* > patches to a omnibus "wish list" or "idea jar", so we can see the > forest for the trees. Of course, anyone with a Bugzilla and a Wiki > account could help with something like this. Once upon a time, I > started an idea jar page here: > > * http://wiki.apache.org/struts/StrutsIdeaJar > > But, IMHO, focussing first on tickets with patches is vital. The > primary role of the committers and PMC is to help the community create > and maintain Struts. The community does this by supplying patches, and > Job One of the PMC should be to ensure that all patches are applied or > declined with cause. > > An Apache project is not about a few shining stars, it's about a > thousand points of light, and those lights speak to us through patches > :) > > Aside from the problem tickets, we have another twenty-odd enhancement > tickets with patches, which could be the focus of 1.3.1. There are > several Bugzilla query links on the Roadmap page. > > * http://struts.apache.org/roadmap.html > > But, again, for 1.3.0, let's resolve the problems that can be > resolved, and get something out on the floor :) > > -Ted. > -- HTH, Ted. http://www.husted.com/poe/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
