Re: Be as a Release Manager
2011/12/19 Martin Cooper mart...@apache.org: Actually, no, not quite. A really, really long time ago, with early Struts 1 releases, we used to designate quality with the initial build. We got out of that bad habit quite a few years ago. The process I was referring to, which was used for later Struts 1 and earlier Struts 2 builds, was: - RM: Perform the (Maven) release process using next build number. - RM: Announce a new Test Build. - RM: Wait for about a week to give everyone a chance to download and test it. - All: Download, test, and provide feedback if appropriate. - RM: If no show-stoppers reported, start a vote thread for build quality designation. - All: Vote on quality - GA, Beta, Alpha, or just stay at test build. - RM: If the vote result is for an ASF release (i.e. not test build), update site, announce - RM: If the vote result is for GA, push to central Thanks Martin, I added your points to the guideline [1] [1] https://cwiki.apache.org/confluence/display/WW/Building+Struts+2+-+Normal+release#BuildingStruts2-Normalrelease-Announceavailability Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Be as a Release Manager
Thanks for clarification but I'm still not sure if I get it right ;-) So I can start a new release process as soon I want to but it can be called an Alpha/Beta/GA build only because of Vote result ? I cannot predetermine the result and say hey, lets release Beta1 ? And if during the Vote, the result is different than GA should the site and so on be published ? Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Be as a Release Manager
On Mon, 19 Dec 2011 09:35:33 +0100, Łukasz Lenart lukasz.len...@googlemail.com wrote: Thanks for clarification but I'm still not sure if I get it right ;-) So I can start a new release process as soon I want to but it can be called an Alpha/Beta/GA build only because of Vote result ? I cannot predetermine the result and say hey, lets release Beta1 ? Currently what we are doing is performing a release build - which just means releasing in terms of technical lifecycle management, thus building and releasing a non-SNAPSHOT version - and then announce it for testing/voting. From our process perspective this is a release candidate. The feedback from the vote determines what quality grade we rate it, most notably whether we see it ready for primetime or still in Beta (or less, if fundamentally broken). And if during the Vote, the result is different than GA should the site and so on be published ? If say 2.3.2 is voted for GA quality, we announce it as GA and push it to central. If on the other hand it would be rated as Beta, we basically don't push it to central. Currently we are just announcing a vote result, we *could* as well go and announce a Beta build to the lists and to http://struts.apache.org/downloads.html (which actually contains a section for that). The next possible GA release now is 2.3.3, because 2.3.2 is technically released (as a Beta) and the next shot needs a new unique version. And on it goes ... An important thing to remember is that we decided against version tags such as 2.3.2-Beta-1, since this implies having to go through the whole technical release process, including full testing, for the 2.3.2-GA version. That said, what Martin referenced as the process we used to have was basically - performing 2.3.2 release process - announce a Beta - wait - if no show-stoppers reported, cast a vote - test, if not done in the Beta phase (!!!) - if the vote result says GA, go for publishing If we feel that this is the better / cleaner process, we can document and switch to it, of course. - René - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Be as a Release Manager
2011/12/19 Łukasz Lenart lukasz.len...@googlemail.com: Thanks for clarification but I'm still not sure if I get it right ;-) So I can start a new release process as soon I want to but it can be called an Alpha/Beta/GA build only because of Vote result ? I cannot predetermine the result and say hey, lets release Beta1 ? Correct. And if during the Vote, the result is different than GA should the site and so on be published ? There was a discussion on another thread about what version the site should correspond to, so I won't address that here. If the result of the vote is a *release* (i.e. GA, Beta, Alpha) then we could choose to announce that on the site; however, if the result of the vote is *not* a release (i.e. the build remains a test build), then no, we shouldn't update the site. -- Martin Cooper Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Be as a Release Manager
On Mon, Dec 19, 2011 at 2:49 AM, Rene Gielen gie...@it-neering.net wrote: On Mon, 19 Dec 2011 09:35:33 +0100, Łukasz Lenart lukasz.len...@googlemail.com wrote: Thanks for clarification but I'm still not sure if I get it right ;-) So I can start a new release process as soon I want to but it can be called an Alpha/Beta/GA build only because of Vote result ? I cannot predetermine the result and say hey, lets release Beta1 ? Currently what we are doing is performing a release build - which just means releasing in terms of technical lifecycle management, thus building and releasing a non-SNAPSHOT version - and then announce it for testing/voting. From our process perspective this is a release candidate. The feedback from the vote determines what quality grade we rate it, most notably whether we see it ready for primetime or still in Beta (or less, if fundamentally broken). Yup. It's probably worth reiterating here that the word release is unfortunately imbued with two meanings. There is release in the Maven sense of the word, which is essentially just a way of building a package and pushing it places. And then there is release in the ASF sense of the (GA / Beta / Alpha) artifact that the Struts PMC is responsible for. The former sense does not imply the latter. We just happen to use the former for our build mechanics. And if during the Vote, the result is different than GA should the site and so on be published ? If say 2.3.2 is voted for GA quality, we announce it as GA and push it to central. If on the other hand it would be rated as Beta, we basically don't push it to central. Currently we are just announcing a vote result, we *could* as well go and announce a Beta build to the lists and to http://struts.apache.org/downloads.html (which actually contains a section for that). The next possible GA release now is 2.3.3, because 2.3.2 is technically released (as a Beta) and the next shot needs a new unique version. And on it goes ... An important thing to remember is that we decided against version tags such as 2.3.2-Beta-1, since this implies having to go through the whole technical release process, including full testing, for the 2.3.2-GA version. That said, what Martin referenced as the process we used to have was basically - performing 2.3.2 release process - announce a Beta - wait - if no show-stoppers reported, cast a vote - test, if not done in the Beta phase (!!!) - if the vote result says GA, go for publishing Actually, no, not quite. A really, really long time ago, with early Struts 1 releases, we used to designate quality with the initial build. We got out of that bad habit quite a few years ago. The process I was referring to, which was used for later Struts 1 and earlier Struts 2 builds, was: - RM: Perform the (Maven) release process using next build number. - RM: Announce a new Test Build. - RM: Wait for about a week to give everyone a chance to download and test it. - All: Download, test, and provide feedback if appropriate. - RM: If no show-stoppers reported, start a vote thread for build quality designation. - All: Vote on quality - GA, Beta, Alpha, or just stay at test build. - RM: If the vote result is for an ASF release (i.e. not test build), update site, announce - RM: If the vote result is for GA, push to central Note that the *only* difference between the process above, and what we have been doing since we changed it, is the week-long wait to allow everyone in the community enough time to test the test build before a vote is called. Otherwise the process is identical. Really! -- Martin Cooper If we feel that this is the better / cleaner process, we can document and switch to it, of course. - René - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Be as a Release Manager
I've moved the discussion to the new thread as to not mismatch two different topics 2011/12/17 Martin Cooper mart...@apache.org: As a follow up, I've added one more point to the Release guide [1], is it enough ? That looks fine, as long as everyone is in agreement. The question in my earlier message was just that - a question. The answer, after digging around in the archives, appears to be yes, we did stop doing that, quite some time ago, and somehow I never noticed until now. As far as I can tell, we didn't make a conscious decision to change; it just happened one time when somebody took on the release task. Nobody noticed, and we've kept doing it that way ever since. As for which way we do it going forward, it really depends on how quickly people - PMC members especially, but not only PMC members - feel they can test a new build. It is *very* important that people vote, and test prior to it, based on the actual bits posted by the RM; not their own build, or a recent snapshot they may have downloaded. If enough people believe they can pick up a new build immediately, incorporate it into their own environment, test it thoroughly, and then vote, all within 72 hours, then there shouldn't be a problem with continuing the way we have been. If that seems a bit tight, then we should leave some time for testing before calling the vote. I'm wondering how to proceed to release BETA1, BETA2, ..., RC1, RC2, , GA versions. With the current approach the name of packages must be specified during running mvn release:prepare command, even if we decide to call it Beta during a Vote it isn't possible to rename the artifacts, Subversion Tag and so on. And to meet the result of the Vote, a new mvn release:prepare command must be issued and a new Vote called (as we vote over the exact bits) - the whole release process must be started over. Do I miss something ? Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Be as a Release Manager
Hi, I'm both commenting on Martin's and Lukasz' mail - see inline On 18.12.11 22:35, Łukasz Lenart wrote: I've moved the discussion to the new thread as to not mismatch two different topics 2011/12/17 Martin Cooper mart...@apache.org: As a follow up, I've added one more point to the Release guide [1], is it enough ? That looks fine, as long as everyone is in agreement. The question in my earlier message was just that - a question. The answer, after digging around in the archives, appears to be yes, we did stop doing that, quite some time ago, and somehow I never noticed until now. As far as I can tell, we didn't make a conscious decision to change; it just happened one time when somebody took on the release task. Nobody noticed, and we've kept doing it that way ever since. I cannot _remember_ that being a policy either, so without further digging I am quite sure we're doing this for a long time now. I think nobody noticed since our votes tended to be very lazy. It was not unusual to have a vote casted without getting enough binding votes for three weeks or more. As for which way we do it going forward, it really depends on how quickly people - PMC members especially, but not only PMC members - feel they can test a new build. It is *very* important that people vote, and test prior to it, based on the actual bits posted by the RM; not their own build, or a recent snapshot they may have downloaded. If enough people believe they can pick up a new build immediately, incorporate it into their own environment, test it thoroughly, and then vote, all within 72 hours, then there shouldn't be a problem with continuing the way we have been. If that seems a bit tight, then we should leave some time for testing before calling the vote. I agree that taking the time for *thouroughly* testing the *actual binary bits* is essential - everybody needs to remind that. Nevertheless I would not see any improvement in splitting the process into a Asking for feedback- and a voting-phase. The voting template is designed for giving feedback on the build quality. If we however feel that 72h is not enough, we might want to extend the period. I'm wondering how to proceed to release BETA1, BETA2, ..., RC1, RC2, , GA versions. With the current approach the name of packages must be specified during running mvn release:prepare command, even if we decide to call it Beta during a Vote it isn't possible to rename the artifacts, Subversion Tag and so on. And to meet the result of the Vote, a new mvn release:prepare command must be issued and a new Vote called (as we vote over the exact bits) - the whole release process must be started over. Do I miss something ? We would in either case stick with clear and unchanged versioning and single builds, even when introducing a testing phase before casting the vote. So we would have announced 2.3.1 as test build, and if no clear objections arose, cast a vote for exactly this binary to become GA or not. So essentially, the difference for the release manager is one more mail (announcing the test build) and some more patience (before casting the vote). But again, I fail to see improvement in doing this - as long as we agree on testing seriously before voting. - René - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Be as a Release Manager
On Sun, Dec 18, 2011 at 1:58 PM, Rene Gielen rene.gie...@googlemail.com wrote: Hi, I'm both commenting on Martin's and Lukasz' mail - see inline On 18.12.11 22:35, Łukasz Lenart wrote: I've moved the discussion to the new thread as to not mismatch two different topics 2011/12/17 Martin Cooper mart...@apache.org: As a follow up, I've added one more point to the Release guide [1], is it enough ? That looks fine, as long as everyone is in agreement. The question in my earlier message was just that - a question. The answer, after digging around in the archives, appears to be yes, we did stop doing that, quite some time ago, and somehow I never noticed until now. As far as I can tell, we didn't make a conscious decision to change; it just happened one time when somebody took on the release task. Nobody noticed, and we've kept doing it that way ever since. I cannot _remember_ that being a policy either, so without further digging I am quite sure we're doing this for a long time now. I think nobody noticed since our votes tended to be very lazy. It was not unusual to have a vote casted without getting enough binding votes for three weeks or more. As for which way we do it going forward, it really depends on how quickly people - PMC members especially, but not only PMC members - feel they can test a new build. It is *very* important that people vote, and test prior to it, based on the actual bits posted by the RM; not their own build, or a recent snapshot they may have downloaded. If enough people believe they can pick up a new build immediately, incorporate it into their own environment, test it thoroughly, and then vote, all within 72 hours, then there shouldn't be a problem with continuing the way we have been. If that seems a bit tight, then we should leave some time for testing before calling the vote. I agree that taking the time for *thouroughly* testing the *actual binary bits* is essential - everybody needs to remind that. Nevertheless I would not see any improvement in splitting the process into a Asking for feedback- and a voting-phase. The voting template is designed for giving feedback on the build quality. If we however feel that 72h is not enough, we might want to extend the period. That's fine too, as long as people know what to expect, and have an opportunity to chime in. What we want to avoid is something like here's a build; vote now; done before the people who care about it have a chance to even see the start of the thread. Not everyone can drop everything to try out a new build as soon as it's announced, and not everyone can read the list every day to ensure they don't miss a chance to participate in the process and test a build prior to release. I'm wondering how to proceed to release BETA1, BETA2, ..., RC1, RC2, , GA versions. With the current approach the name of packages must be specified during running mvn release:prepare command, even if we decide to call it Beta during a Vote it isn't possible to rename the artifacts, Subversion Tag and so on. And to meet the result of the Vote, a new mvn release:prepare command must be issued and a new Vote called (as we vote over the exact bits) - the whole release process must be started over. Do I miss something ? The build you post as an RM - the build that people download, test, and vote upon - is a test build; it's not a release yet. The vote is a vote on the quality of that test build. Depending upon the result of the vote, those bits may become a GA, Beta or Alpha release, or may not become a release at all. (Note that we do not have RC releases.) Regardless of the result of the vote, the version number doesn't change; only the designation changes. We would in either case stick with clear and unchanged versioning and single builds, even when introducing a testing phase before casting the vote. So we would have announced 2.3.1 as test build, and if no clear objections arose, cast a vote for exactly this binary to become GA or not. So essentially, the difference for the release manager is one more mail (announcing the test build) and some more patience (before casting the vote). Exactly. My question was solely about the waiting period that we used to have (yes, some time ago) between announcing the availability of the test build and the start of a vote to determine the quality of that test build. But again, I fail to see improvement in doing this - as long as we agree on testing seriously before voting. Right. And as long as the process is inclusive of those who wish to participate in the testing and quality determination. -- Martin Cooper - René - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
Re: Looking for Release Manager
Perfect! Did you update the docs ? Thanks in advance -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/6 Maurizio Cucchiara mcucchi...@apache.org: Hi Lukasz, what about to: 1. login to p.a.o: ssh yourLoginName@p.a.o 2. cd /www/people.apache.org/builds/struts 3. create (if not exists) the version folder: mkdir $VERSION 4. wget -erobots=off -nv -l 1 --accept=zip,md5,sha1,asc -r --no-check-certificate -nd -nH https://repository.apache.org/content/groups/public/org/apache/struts/struts2-assembly/$VERSION/ 5 rm *.pom Launching wget directly from p.a.o is very very fast. Also notice that I removed 2 flags from your original version of wget: 1. -i --input-file=file: Read URLs from a local or external file 2. -E --adjust-extension: If a file of type application/xhtml+xml or text/html is downloaded and the URL does not end with the regexp \.[Hh][Tt][Mm][Ll]?, this option will cause the suffix .html to be appended to the local filename. Maurizio Cucchiara 2011/9/6 Łukasz Lenart lukasz.len...@googlemail.com Maurizio One more thing, the docs aren't accurate, you have to download the assemblies from Nexus, not to use created / uploaded by you as they miss control sums. I've been using the script below to do that: #!/bin/bash for f in struts*.* do rm $f done wget -erobots=off -nv -i -E -l 1 --accept=zip,md5,sha1,asc -r --no-check-certificate -nd -nH https://repository.apache.org/content/groups/public/org/apache/struts/struts2-assembly/$VERSION for f in *2-assembly*.zip* do mv $f `echo $f | sed s/2-assembly//g` done for f in struts2-assembly-*.pom* do rm $f done Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara maurizio.cucchi...@gmail.com: Hi René, it makes a lot of sense to me. So if there is no objections, I would rename the 2.2.3.1 branch to 2.2.3.x. In this way, it makes also sense to allow the maven release plugin to increment the version in order to prepare for next development iteration. Thank you for your suggestion. Maurizio Cucchiara On 5 September 2011 16:40, Rene Gielen rene.gie...@googlemail.com wrote: Maurizio, great, thanks for jumping in! You've earned your Release Manager Badge the hard way, as it is mostly always for the first time :) While reading your posts and checking [1] I stumbled upon the branch name to use. Actually we should adjust When a serious security issue arises, we should try to create a #.#.#.1 branch from the last GA release, and apply to that branch only the security patch. - the branch to create would be 2.2.3.x and not 2.2.3.1 - the latter one will be the tag for the version to release. If we would have to roll out another patch release, the patch would be applied against 2.2.3.x branch and the tagged as 2.2.3.2. So I'd suggest to exchange the cited #.#.#.1 with #.#.#.x. Does this make sense to you guys? - René [1] https://cwiki.apache.org/confluence/display/WW/Creating+and+Signing+a+Struts+2.2.x+Distribution#CreatingandSigningaStruts2.2.xDistribution-FastTrackinganImportantSecurityRelease Am 05.09.11 17:58, schrieb Maurizio Cucchiara: It looks like it works now, thank you Lukasz. Maurizio Cucchiara 2011/9/5 Łukasz Lenart lukasz.len...@googlemail.com: I've messed up everything, I was thinking about JIRA but checked on Confluence :/ Anyway, please check now. Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org: Hi Lukasz, I don't know if it will help, but looking at JIRA I realized that on the OGNL project (so would you) I have the admin rights which we are talking about. Maurizio Cucchiara 2011/9/5 Łukasz Lenart lukasz.len...@googlemail.com: I've asked INFRA if they can create such a group - struts-release-manager I have rights to do it, but I don't know how :/ Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org: Hi Wendy, I was talking about the 6,7,8 steps listed on http://s.apache.org/hb and generally everything related to JIIRA, since I have no JIIRA admin rights. Maurizio Cucchiara On 5 September 2011 01:59, Wendy Smoak wsm...@gmail.com wrote: On Sun, Sep 4, 2011 at 4:17 PM, Maurizio Cucchiara mcucchi...@apache.org wrote: Lukasz, I am afraid I am not able to perform the 6,7,8 tasks illustrated on http://s.apache.org/rel, since I have no enough karma. Which steps do you mean? Any committer should be able to stage a release and call a vote
Re: Looking for Release Manager
Not yet, but I'm going to do. Needless to say that any help will be appreciated :) Maurizio Cucchiara 2011/9/7 Łukasz Lenart lukasz.len...@googlemail.com: Perfect! Did you update the docs ? Thanks in advance -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/6 Maurizio Cucchiara mcucchi...@apache.org: Hi Lukasz, what about to: 1. login to p.a.o: ssh yourLoginName@p.a.o 2. cd /www/people.apache.org/builds/struts 3. create (if not exists) the version folder: mkdir $VERSION 4. wget -erobots=off -nv -l 1 --accept=zip,md5,sha1,asc -r --no-check-certificate -nd -nH https://repository.apache.org/content/groups/public/org/apache/struts/struts2-assembly/$VERSION/ 5 rm *.pom Launching wget directly from p.a.o is very very fast. Also notice that I removed 2 flags from your original version of wget: 1. -i --input-file=file: Read URLs from a local or external file 2. -E --adjust-extension: If a file of type application/xhtml+xml or text/html is downloaded and the URL does not end with the regexp \.[Hh][Tt][Mm][Ll]?, this option will cause the suffix .html to be appended to the local filename. Maurizio Cucchiara 2011/9/6 Łukasz Lenart lukasz.len...@googlemail.com Maurizio One more thing, the docs aren't accurate, you have to download the assemblies from Nexus, not to use created / uploaded by you as they miss control sums. I've been using the script below to do that: #!/bin/bash for f in struts*.* do rm $f done wget -erobots=off -nv -i -E -l 1 --accept=zip,md5,sha1,asc -r --no-check-certificate -nd -nH https://repository.apache.org/content/groups/public/org/apache/struts/struts2-assembly/$VERSION for f in *2-assembly*.zip* do mv $f `echo $f | sed s/2-assembly//g` done for f in struts2-assembly-*.pom* do rm $f done Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara maurizio.cucchi...@gmail.com: Hi René, it makes a lot of sense to me. So if there is no objections, I would rename the 2.2.3.1 branch to 2.2.3.x. In this way, it makes also sense to allow the maven release plugin to increment the version in order to prepare for next development iteration. Thank you for your suggestion. Maurizio Cucchiara On 5 September 2011 16:40, Rene Gielen rene.gie...@googlemail.com wrote: Maurizio, great, thanks for jumping in! You've earned your Release Manager Badge the hard way, as it is mostly always for the first time :) While reading your posts and checking [1] I stumbled upon the branch name to use. Actually we should adjust When a serious security issue arises, we should try to create a #.#.#.1 branch from the last GA release, and apply to that branch only the security patch. - the branch to create would be 2.2.3.x and not 2.2.3.1 - the latter one will be the tag for the version to release. If we would have to roll out another patch release, the patch would be applied against 2.2.3.x branch and the tagged as 2.2.3.2. So I'd suggest to exchange the cited #.#.#.1 with #.#.#.x. Does this make sense to you guys? - René [1] https://cwiki.apache.org/confluence/display/WW/Creating+and+Signing+a+Struts+2.2.x+Distribution#CreatingandSigningaStruts2.2.xDistribution-FastTrackinganImportantSecurityRelease Am 05.09.11 17:58, schrieb Maurizio Cucchiara: It looks like it works now, thank you Lukasz. Maurizio Cucchiara 2011/9/5 Łukasz Lenart lukasz.len...@googlemail.com: I've messed up everything, I was thinking about JIRA but checked on Confluence :/ Anyway, please check now. Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org: Hi Lukasz, I don't know if it will help, but looking at JIRA I realized that on the OGNL project (so would you) I have the admin rights which we are talking about. Maurizio Cucchiara 2011/9/5 Łukasz Lenart lukasz.len...@googlemail.com: I've asked INFRA if they can create such a group - struts-release-manager I have rights to do it, but I don't know how :/ Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org: Hi Wendy, I was talking about the 6,7,8 steps listed on http://s.apache.org/hb and generally everything related to JIIRA, since I have no JIIRA admin rights. Maurizio Cucchiara On 5 September 2011 01:59, Wendy Smoak wsm...@gmail.com wrote: On Sun, Sep 4, 2011 at 4:17 PM, Maurizio Cucchiara mcucchi...@apache.org wrote: Lukasz, I am afraid I am not able to perform the 6,7,8 tasks
Re: Looking for Release Manager
Could you confirm please that, after I created a pgp key (http://s.apache.org/N30), I have to copy it on /www/www.apache.org/dist/struts/KEYS Maurizio Cucchiara On 7 September 2011 09:17, Maurizio Cucchiara mcucchi...@apache.org wrote: Not yet, but I'm going to do. Needless to say that any help will be appreciated :) Maurizio Cucchiara 2011/9/7 Łukasz Lenart lukasz.len...@googlemail.com: Perfect! Did you update the docs ? Thanks in advance -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/6 Maurizio Cucchiara mcucchi...@apache.org: Hi Lukasz, what about to: 1. login to p.a.o: ssh yourLoginName@p.a.o 2. cd /www/people.apache.org/builds/struts 3. create (if not exists) the version folder: mkdir $VERSION 4. wget -erobots=off -nv -l 1 --accept=zip,md5,sha1,asc -r --no-check-certificate -nd -nH https://repository.apache.org/content/groups/public/org/apache/struts/struts2-assembly/$VERSION/ 5 rm *.pom Launching wget directly from p.a.o is very very fast. Also notice that I removed 2 flags from your original version of wget: 1. -i --input-file=file: Read URLs from a local or external file 2. -E --adjust-extension: If a file of type application/xhtml+xml or text/html is downloaded and the URL does not end with the regexp \.[Hh][Tt][Mm][Ll]?, this option will cause the suffix .html to be appended to the local filename. Maurizio Cucchiara 2011/9/6 Łukasz Lenart lukasz.len...@googlemail.com Maurizio One more thing, the docs aren't accurate, you have to download the assemblies from Nexus, not to use created / uploaded by you as they miss control sums. I've been using the script below to do that: #!/bin/bash for f in struts*.* do rm $f done wget -erobots=off -nv -i -E -l 1 --accept=zip,md5,sha1,asc -r --no-check-certificate -nd -nH https://repository.apache.org/content/groups/public/org/apache/struts/struts2-assembly/$VERSION for f in *2-assembly*.zip* do mv $f `echo $f | sed s/2-assembly//g` done for f in struts2-assembly-*.pom* do rm $f done Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara maurizio.cucchi...@gmail.com: Hi René, it makes a lot of sense to me. So if there is no objections, I would rename the 2.2.3.1 branch to 2.2.3.x. In this way, it makes also sense to allow the maven release plugin to increment the version in order to prepare for next development iteration. Thank you for your suggestion. Maurizio Cucchiara On 5 September 2011 16:40, Rene Gielen rene.gie...@googlemail.com wrote: Maurizio, great, thanks for jumping in! You've earned your Release Manager Badge the hard way, as it is mostly always for the first time :) While reading your posts and checking [1] I stumbled upon the branch name to use. Actually we should adjust When a serious security issue arises, we should try to create a #.#.#.1 branch from the last GA release, and apply to that branch only the security patch. - the branch to create would be 2.2.3.x and not 2.2.3.1 - the latter one will be the tag for the version to release. If we would have to roll out another patch release, the patch would be applied against 2.2.3.x branch and the tagged as 2.2.3.2. So I'd suggest to exchange the cited #.#.#.1 with #.#.#.x. Does this make sense to you guys? - René [1] https://cwiki.apache.org/confluence/display/WW/Creating+and+Signing+a+Struts+2.2.x+Distribution#CreatingandSigningaStruts2.2.xDistribution-FastTrackinganImportantSecurityRelease Am 05.09.11 17:58, schrieb Maurizio Cucchiara: It looks like it works now, thank you Lukasz. Maurizio Cucchiara 2011/9/5 Łukasz Lenart lukasz.len...@googlemail.com: I've messed up everything, I was thinking about JIRA but checked on Confluence :/ Anyway, please check now. Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org: Hi Lukasz, I don't know if it will help, but looking at JIRA I realized that on the OGNL project (so would you) I have the admin rights which we are talking about. Maurizio Cucchiara 2011/9/5 Łukasz Lenart lukasz.len...@googlemail.com: I've asked INFRA if they can create such a group - struts-release-manager I have rights to do it, but I don't know how :/ Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org: Hi Wendy, I was talking about the 6,7,8 steps listed on http://s.apache.org/hb and generally everything related to JIIRA, since I have no JIIRA admin rights
Re: Looking for Release Manager
Please forget my last question, I have just realized it is documented. Maurizio Cucchiara On 7 September 2011 10:02, Maurizio Cucchiara maurizio.cucchi...@gmail.com wrote: Could you confirm please that, after I created a pgp key (http://s.apache.org/N30), I have to copy it on /www/www.apache.org/dist/struts/KEYS Maurizio Cucchiara On 7 September 2011 09:17, Maurizio Cucchiara mcucchi...@apache.org wrote: Not yet, but I'm going to do. Needless to say that any help will be appreciated :) Maurizio Cucchiara 2011/9/7 Łukasz Lenart lukasz.len...@googlemail.com: Perfect! Did you update the docs ? Thanks in advance -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/6 Maurizio Cucchiara mcucchi...@apache.org: Hi Lukasz, what about to: 1. login to p.a.o: ssh yourLoginName@p.a.o 2. cd /www/people.apache.org/builds/struts 3. create (if not exists) the version folder: mkdir $VERSION 4. wget -erobots=off -nv -l 1 --accept=zip,md5,sha1,asc -r --no-check-certificate -nd -nH https://repository.apache.org/content/groups/public/org/apache/struts/struts2-assembly/$VERSION/ 5 rm *.pom Launching wget directly from p.a.o is very very fast. Also notice that I removed 2 flags from your original version of wget: 1. -i --input-file=file: Read URLs from a local or external file 2. -E --adjust-extension: If a file of type application/xhtml+xml or text/html is downloaded and the URL does not end with the regexp \.[Hh][Tt][Mm][Ll]?, this option will cause the suffix .html to be appended to the local filename. Maurizio Cucchiara 2011/9/6 Łukasz Lenart lukasz.len...@googlemail.com Maurizio One more thing, the docs aren't accurate, you have to download the assemblies from Nexus, not to use created / uploaded by you as they miss control sums. I've been using the script below to do that: #!/bin/bash for f in struts*.* do rm $f done wget -erobots=off -nv -i -E -l 1 --accept=zip,md5,sha1,asc -r --no-check-certificate -nd -nH https://repository.apache.org/content/groups/public/org/apache/struts/struts2-assembly/$VERSION for f in *2-assembly*.zip* do mv $f `echo $f | sed s/2-assembly//g` done for f in struts2-assembly-*.pom* do rm $f done Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara maurizio.cucchi...@gmail.com: Hi René, it makes a lot of sense to me. So if there is no objections, I would rename the 2.2.3.1 branch to 2.2.3.x. In this way, it makes also sense to allow the maven release plugin to increment the version in order to prepare for next development iteration. Thank you for your suggestion. Maurizio Cucchiara On 5 September 2011 16:40, Rene Gielen rene.gie...@googlemail.com wrote: Maurizio, great, thanks for jumping in! You've earned your Release Manager Badge the hard way, as it is mostly always for the first time :) While reading your posts and checking [1] I stumbled upon the branch name to use. Actually we should adjust When a serious security issue arises, we should try to create a #.#.#.1 branch from the last GA release, and apply to that branch only the security patch. - the branch to create would be 2.2.3.x and not 2.2.3.1 - the latter one will be the tag for the version to release. If we would have to roll out another patch release, the patch would be applied against 2.2.3.x branch and the tagged as 2.2.3.2. So I'd suggest to exchange the cited #.#.#.1 with #.#.#.x. Does this make sense to you guys? - René [1] https://cwiki.apache.org/confluence/display/WW/Creating+and+Signing+a+Struts+2.2.x+Distribution#CreatingandSigningaStruts2.2.xDistribution-FastTrackinganImportantSecurityRelease Am 05.09.11 17:58, schrieb Maurizio Cucchiara: It looks like it works now, thank you Lukasz. Maurizio Cucchiara 2011/9/5 Łukasz Lenart lukasz.len...@googlemail.com: I've messed up everything, I was thinking about JIRA but checked on Confluence :/ Anyway, please check now. Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org: Hi Lukasz, I don't know if it will help, but looking at JIRA I realized that on the OGNL project (so would you) I have the admin rights which we are talking about. Maurizio Cucchiara 2011/9/5 Łukasz Lenart lukasz.len...@googlemail.com: I've asked INFRA if they can create such a group - struts-release-manager I have rights to do it, but I don't know how :/ Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org
Re: Looking for Release Manager
2011/9/7 Maurizio Cucchiara mcucchi...@apache.org: Not yet, but I'm going to do. Needless to say that any help will be appreciated :) Just change the points in the doc that were different from what you did ;-) Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Looking for Release Manager
Hi Lukasz, what about to: 1. login to p.a.o: ssh yourLoginName@p.a.o 2. cd /www/people.apache.org/builds/struts 3. create (if not exists) the version folder: mkdir $VERSION 4. wget -erobots=off -nv -l 1 --accept=zip,md5,sha1,asc -r --no-check-certificate -nd -nH https://repository.apache.org/content/groups/public/org/apache/struts/struts2-assembly/$VERSION/ 5 rm *.pom Launching wget directly from p.a.o is very very fast. Also notice that I removed 2 flags from your original version of wget: 1. -i --input-file=file: Read URLs from a local or external file 2. -E --adjust-extension: If a file of type application/xhtml+xml or text/html is downloaded and the URL does not end with the regexp \.[Hh][Tt][Mm][Ll]?, this option will cause the suffix .html to be appended to the local filename. Maurizio Cucchiara 2011/9/6 Łukasz Lenart lukasz.len...@googlemail.com Maurizio One more thing, the docs aren't accurate, you have to download the assemblies from Nexus, not to use created / uploaded by you as they miss control sums. I've been using the script below to do that: #!/bin/bash for f in struts*.* do rm $f done wget -erobots=off -nv -i -E -l 1 --accept=zip,md5,sha1,asc -r --no-check-certificate -nd -nH https://repository.apache.org/content/groups/public/org/apache/struts/struts2-assembly/$VERSION for f in *2-assembly*.zip* do mv $f `echo $f | sed s/2-assembly//g` done for f in struts2-assembly-*.pom* do rm $f done Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara maurizio.cucchi...@gmail.com: Hi René, it makes a lot of sense to me. So if there is no objections, I would rename the 2.2.3.1 branch to 2.2.3.x. In this way, it makes also sense to allow the maven release plugin to increment the version in order to prepare for next development iteration. Thank you for your suggestion. Maurizio Cucchiara On 5 September 2011 16:40, Rene Gielen rene.gie...@googlemail.com wrote: Maurizio, great, thanks for jumping in! You've earned your Release Manager Badge the hard way, as it is mostly always for the first time :) While reading your posts and checking [1] I stumbled upon the branch name to use. Actually we should adjust When a serious security issue arises, we should try to create a #.#.#.1 branch from the last GA release, and apply to that branch only the security patch. - the branch to create would be 2.2.3.x and not 2.2.3.1 - the latter one will be the tag for the version to release. If we would have to roll out another patch release, the patch would be applied against 2.2.3.x branch and the tagged as 2.2.3.2. So I'd suggest to exchange the cited #.#.#.1 with #.#.#.x. Does this make sense to you guys? - René [1] https://cwiki.apache.org/confluence/display/WW/Creating+and+Signing+a+Struts+2.2.x+Distribution#CreatingandSigningaStruts2.2.xDistribution-FastTrackinganImportantSecurityRelease Am 05.09.11 17:58, schrieb Maurizio Cucchiara: It looks like it works now, thank you Lukasz. Maurizio Cucchiara 2011/9/5 Łukasz Lenart lukasz.len...@googlemail.com: I've messed up everything, I was thinking about JIRA but checked on Confluence :/ Anyway, please check now. Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org: Hi Lukasz, I don't know if it will help, but looking at JIRA I realized that on the OGNL project (so would you) I have the admin rights which we are talking about. Maurizio Cucchiara 2011/9/5 Łukasz Lenart lukasz.len...@googlemail.com: I've asked INFRA if they can create such a group - struts-release-manager I have rights to do it, but I don't know how :/ Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org: Hi Wendy, I was talking about the 6,7,8 steps listed on http://s.apache.org/hb and generally everything related to JIIRA, since I have no JIIRA admin rights. Maurizio Cucchiara On 5 September 2011 01:59, Wendy Smoak wsm...@gmail.com wrote: On Sun, Sep 4, 2011 at 4:17 PM, Maurizio Cucchiara mcucchi...@apache.org wrote: Lukasz, I am afraid I am not able to perform the 6,7,8 tasks illustrated on http://s.apache.org/rel, since I have no enough karma. Which steps do you mean? Any committer should be able to stage a release and call a vote. (There is a 'versions' plugin that can make the version number changes, though if you're good at regular expressions your way was probably quicker. :) ) -- Wendy
Re: Looking for Release Manager
Hi Wendy, I was talking about the 6,7,8 steps listed on http://s.apache.org/hb and generally everything related to JIIRA, since I have no JIIRA admin rights. Maurizio Cucchiara On 5 September 2011 01:59, Wendy Smoak wsm...@gmail.com wrote: On Sun, Sep 4, 2011 at 4:17 PM, Maurizio Cucchiara mcucchi...@apache.org wrote: Lukasz, I am afraid I am not able to perform the 6,7,8 tasks illustrated on http://s.apache.org/rel, since I have no enough karma. Which steps do you mean? Any committer should be able to stage a release and call a vote. (There is a 'versions' plugin that can make the version number changes, though if you're good at regular expressions your way was probably quicker. :) ) -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Looking for Release Manager
I've asked INFRA if they can create such a group - struts-release-manager I have rights to do it, but I don't know how :/ Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org: Hi Wendy, I was talking about the 6,7,8 steps listed on http://s.apache.org/hb and generally everything related to JIIRA, since I have no JIIRA admin rights. Maurizio Cucchiara On 5 September 2011 01:59, Wendy Smoak wsm...@gmail.com wrote: On Sun, Sep 4, 2011 at 4:17 PM, Maurizio Cucchiara mcucchi...@apache.org wrote: Lukasz, I am afraid I am not able to perform the 6,7,8 tasks illustrated on http://s.apache.org/rel, since I have no enough karma. Which steps do you mean? Any committer should be able to stage a release and call a vote. (There is a 'versions' plugin that can make the version number changes, though if you're good at regular expressions your way was probably quicker. :) ) -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Looking for Release Manager
Hi Lukasz, I don't know if it will help, but looking at JIRA I realized that on the OGNL project (so would you) I have the admin rights which we are talking about. Maurizio Cucchiara 2011/9/5 Łukasz Lenart lukasz.len...@googlemail.com: I've asked INFRA if they can create such a group - struts-release-manager I have rights to do it, but I don't know how :/ Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org: Hi Wendy, I was talking about the 6,7,8 steps listed on http://s.apache.org/hb and generally everything related to JIIRA, since I have no JIIRA admin rights. Maurizio Cucchiara On 5 September 2011 01:59, Wendy Smoak wsm...@gmail.com wrote: On Sun, Sep 4, 2011 at 4:17 PM, Maurizio Cucchiara mcucchi...@apache.org wrote: Lukasz, I am afraid I am not able to perform the 6,7,8 tasks illustrated on http://s.apache.org/rel, since I have no enough karma. Which steps do you mean? Any committer should be able to stage a release and call a vote. (There is a 'versions' plugin that can make the version number changes, though if you're good at regular expressions your way was probably quicker. :) ) -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Looking for Release Manager
I've messed up everything, I was thinking about JIRA but checked on Confluence :/ Anyway, please check now. Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org: Hi Lukasz, I don't know if it will help, but looking at JIRA I realized that on the OGNL project (so would you) I have the admin rights which we are talking about. Maurizio Cucchiara 2011/9/5 Łukasz Lenart lukasz.len...@googlemail.com: I've asked INFRA if they can create such a group - struts-release-manager I have rights to do it, but I don't know how :/ Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org: Hi Wendy, I was talking about the 6,7,8 steps listed on http://s.apache.org/hb and generally everything related to JIIRA, since I have no JIIRA admin rights. Maurizio Cucchiara On 5 September 2011 01:59, Wendy Smoak wsm...@gmail.com wrote: On Sun, Sep 4, 2011 at 4:17 PM, Maurizio Cucchiara mcucchi...@apache.org wrote: Lukasz, I am afraid I am not able to perform the 6,7,8 tasks illustrated on http://s.apache.org/rel, since I have no enough karma. Which steps do you mean? Any committer should be able to stage a release and call a vote. (There is a 'versions' plugin that can make the version number changes, though if you're good at regular expressions your way was probably quicker. :) ) -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Looking for Release Manager
It looks like it works now, thank you Lukasz. Maurizio Cucchiara 2011/9/5 Łukasz Lenart lukasz.len...@googlemail.com: I've messed up everything, I was thinking about JIRA but checked on Confluence :/ Anyway, please check now. Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org: Hi Lukasz, I don't know if it will help, but looking at JIRA I realized that on the OGNL project (so would you) I have the admin rights which we are talking about. Maurizio Cucchiara 2011/9/5 Łukasz Lenart lukasz.len...@googlemail.com: I've asked INFRA if they can create such a group - struts-release-manager I have rights to do it, but I don't know how :/ Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org: Hi Wendy, I was talking about the 6,7,8 steps listed on http://s.apache.org/hb and generally everything related to JIIRA, since I have no JIIRA admin rights. Maurizio Cucchiara On 5 September 2011 01:59, Wendy Smoak wsm...@gmail.com wrote: On Sun, Sep 4, 2011 at 4:17 PM, Maurizio Cucchiara mcucchi...@apache.org wrote: Lukasz, I am afraid I am not able to perform the 6,7,8 tasks illustrated on http://s.apache.org/rel, since I have no enough karma. Which steps do you mean? Any committer should be able to stage a release and call a vote. (There is a 'versions' plugin that can make the version number changes, though if you're good at regular expressions your way was probably quicker. :) ) -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Looking for Release Manager
On Mon, Sep 5, 2011 at 2:38 AM, Maurizio Cucchiara mcucchi...@apache.org wrote: Hi Wendy, I was talking about the 6,7,8 steps listed on http://s.apache.org/hb and generally everything related to JIIRA, since I have no JIIRA admin rights. Okay, now I see you mean number 6, 7 and 8 under Getting Ready on that page: Release the upcoming version in JIRA (under Administration/Manage Releases) and tag the release date Add next milestone version to the JIRA roadmap Create DONE and TODO filters for the new version, share with all, and remove obsolete TODO filter (The content of the page only has 3 steps with lots of sub-parts, that's why I asked exactly what you were having trouble with. Give more detail next time. :) ) -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Looking for Release Manager
Maurizio, great, thanks for jumping in! You've earned your Release Manager Badge the hard way, as it is mostly always for the first time :) While reading your posts and checking [1] I stumbled upon the branch name to use. Actually we should adjust When a serious security issue arises, we should try to create a #.#.#.1 branch from the last GA release, and apply to that branch only the security patch. - the branch to create would be 2.2.3.x and not 2.2.3.1 - the latter one will be the tag for the version to release. If we would have to roll out another patch release, the patch would be applied against 2.2.3.x branch and the tagged as 2.2.3.2. So I'd suggest to exchange the cited #.#.#.1 with #.#.#.x. Does this make sense to you guys? - René [1] https://cwiki.apache.org/confluence/display/WW/Creating+and+Signing+a+Struts+2.2.x+Distribution#CreatingandSigningaStruts2.2.xDistribution-FastTrackinganImportantSecurityRelease Am 05.09.11 17:58, schrieb Maurizio Cucchiara: It looks like it works now, thank you Lukasz. Maurizio Cucchiara 2011/9/5 Łukasz Lenart lukasz.len...@googlemail.com: I've messed up everything, I was thinking about JIRA but checked on Confluence :/ Anyway, please check now. Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org: Hi Lukasz, I don't know if it will help, but looking at JIRA I realized that on the OGNL project (so would you) I have the admin rights which we are talking about. Maurizio Cucchiara 2011/9/5 Łukasz Lenart lukasz.len...@googlemail.com: I've asked INFRA if they can create such a group - struts-release-manager I have rights to do it, but I don't know how :/ Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org: Hi Wendy, I was talking about the 6,7,8 steps listed on http://s.apache.org/hb and generally everything related to JIIRA, since I have no JIIRA admin rights. Maurizio Cucchiara On 5 September 2011 01:59, Wendy Smoak wsm...@gmail.com wrote: On Sun, Sep 4, 2011 at 4:17 PM, Maurizio Cucchiara mcucchi...@apache.org wrote: Lukasz, I am afraid I am not able to perform the 6,7,8 tasks illustrated on http://s.apache.org/rel, since I have no enough karma. Which steps do you mean? Any committer should be able to stage a release and call a vote. (There is a 'versions' plugin that can make the version number changes, though if you're good at regular expressions your way was probably quicker. :) ) -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Looking for Release Manager
Wendy, You are right, I realized that I shortened the wrong url (the one without the anchor) late. Sorry to wasted your time. Maurizio Cucchiara On 5 September 2011 13:37, Wendy Smoak wsm...@gmail.com wrote: On Mon, Sep 5, 2011 at 2:38 AM, Maurizio Cucchiara mcucchi...@apache.org wrote: Hi Wendy, I was talking about the 6,7,8 steps listed on http://s.apache.org/hb and generally everything related to JIIRA, since I have no JIIRA admin rights. Okay, now I see you mean number 6, 7 and 8 under Getting Ready on that page: Release the upcoming version in JIRA (under Administration/Manage Releases) and tag the release date Add next milestone version to the JIRA roadmap Create DONE and TODO filters for the new version, share with all, and remove obsolete TODO filter (The content of the page only has 3 steps with lots of sub-parts, that's why I asked exactly what you were having trouble with. Give more detail next time. :) ) -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Looking for Release Manager
Hi René, it makes a lot of sense to me. So if there is no objections, I would rename the 2.2.3.1 branch to 2.2.3.x. In this way, it makes also sense to allow the maven release plugin to increment the version in order to prepare for next development iteration. Thank you for your suggestion. Maurizio Cucchiara On 5 September 2011 16:40, Rene Gielen rene.gie...@googlemail.com wrote: Maurizio, great, thanks for jumping in! You've earned your Release Manager Badge the hard way, as it is mostly always for the first time :) While reading your posts and checking [1] I stumbled upon the branch name to use. Actually we should adjust When a serious security issue arises, we should try to create a #.#.#.1 branch from the last GA release, and apply to that branch only the security patch. - the branch to create would be 2.2.3.x and not 2.2.3.1 - the latter one will be the tag for the version to release. If we would have to roll out another patch release, the patch would be applied against 2.2.3.x branch and the tagged as 2.2.3.2. So I'd suggest to exchange the cited #.#.#.1 with #.#.#.x. Does this make sense to you guys? - René [1] https://cwiki.apache.org/confluence/display/WW/Creating+and+Signing+a+Struts+2.2.x+Distribution#CreatingandSigningaStruts2.2.xDistribution-FastTrackinganImportantSecurityRelease Am 05.09.11 17:58, schrieb Maurizio Cucchiara: It looks like it works now, thank you Lukasz. Maurizio Cucchiara 2011/9/5 Łukasz Lenart lukasz.len...@googlemail.com: I've messed up everything, I was thinking about JIRA but checked on Confluence :/ Anyway, please check now. Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org: Hi Lukasz, I don't know if it will help, but looking at JIRA I realized that on the OGNL project (so would you) I have the admin rights which we are talking about. Maurizio Cucchiara 2011/9/5 Łukasz Lenart lukasz.len...@googlemail.com: I've asked INFRA if they can create such a group - struts-release-manager I have rights to do it, but I don't know how :/ Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org: Hi Wendy, I was talking about the 6,7,8 steps listed on http://s.apache.org/hb and generally everything related to JIIRA, since I have no JIIRA admin rights. Maurizio Cucchiara On 5 September 2011 01:59, Wendy Smoak wsm...@gmail.com wrote: On Sun, Sep 4, 2011 at 4:17 PM, Maurizio Cucchiara mcucchi...@apache.org wrote: Lukasz, I am afraid I am not able to perform the 6,7,8 tasks illustrated on http://s.apache.org/rel, since I have no enough karma. Which steps do you mean? Any committer should be able to stage a release and call a vote. (There is a 'versions' plugin that can make the version number changes, though if you're good at regular expressions your way was probably quicker. :) ) -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Looking for Release Manager
Maurizio One more thing, the docs aren't accurate, you have to download the assemblies from Nexus, not to use created / uploaded by you as they miss control sums. I've been using the script below to do that: #!/bin/bash for f in struts*.* do rm $f done wget -erobots=off -nv -i -E -l 1 --accept=zip,md5,sha1,asc -r --no-check-certificate -nd -nH https://repository.apache.org/content/groups/public/org/apache/struts/struts2-assembly/$VERSION for f in *2-assembly*.zip* do mv $f `echo $f | sed s/2-assembly//g` done for f in struts2-assembly-*.pom* do rm $f done Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara maurizio.cucchi...@gmail.com: Hi René, it makes a lot of sense to me. So if there is no objections, I would rename the 2.2.3.1 branch to 2.2.3.x. In this way, it makes also sense to allow the maven release plugin to increment the version in order to prepare for next development iteration. Thank you for your suggestion. Maurizio Cucchiara On 5 September 2011 16:40, Rene Gielen rene.gie...@googlemail.com wrote: Maurizio, great, thanks for jumping in! You've earned your Release Manager Badge the hard way, as it is mostly always for the first time :) While reading your posts and checking [1] I stumbled upon the branch name to use. Actually we should adjust When a serious security issue arises, we should try to create a #.#.#.1 branch from the last GA release, and apply to that branch only the security patch. - the branch to create would be 2.2.3.x and not 2.2.3.1 - the latter one will be the tag for the version to release. If we would have to roll out another patch release, the patch would be applied against 2.2.3.x branch and the tagged as 2.2.3.2. So I'd suggest to exchange the cited #.#.#.1 with #.#.#.x. Does this make sense to you guys? - René [1] https://cwiki.apache.org/confluence/display/WW/Creating+and+Signing+a+Struts+2.2.x+Distribution#CreatingandSigningaStruts2.2.xDistribution-FastTrackinganImportantSecurityRelease Am 05.09.11 17:58, schrieb Maurizio Cucchiara: It looks like it works now, thank you Lukasz. Maurizio Cucchiara 2011/9/5 Łukasz Lenart lukasz.len...@googlemail.com: I've messed up everything, I was thinking about JIRA but checked on Confluence :/ Anyway, please check now. Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org: Hi Lukasz, I don't know if it will help, but looking at JIRA I realized that on the OGNL project (so would you) I have the admin rights which we are talking about. Maurizio Cucchiara 2011/9/5 Łukasz Lenart lukasz.len...@googlemail.com: I've asked INFRA if they can create such a group - struts-release-manager I have rights to do it, but I don't know how :/ Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/9/5 Maurizio Cucchiara mcucchi...@apache.org: Hi Wendy, I was talking about the 6,7,8 steps listed on http://s.apache.org/hb and generally everything related to JIIRA, since I have no JIIRA admin rights. Maurizio Cucchiara On 5 September 2011 01:59, Wendy Smoak wsm...@gmail.com wrote: On Sun, Sep 4, 2011 at 4:17 PM, Maurizio Cucchiara mcucchi...@apache.org wrote: Lukasz, I am afraid I am not able to perform the 6,7,8 tasks illustrated on http://s.apache.org/rel, since I have no enough karma. Which steps do you mean? Any committer should be able to stage a release and call a vote. (There is a 'versions' plugin that can make the version number changes, though if you're good at regular expressions your way was probably quicker. :) ) -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Looking for Release Manager
Hi guys, Struts 2.2.3.1 is on the way, anyway I am in doubt about the release process. Could you review please the step I followed? First I created a STRUTS_2_2_3_1 branch from the latest release (STRUTS_2_2_3 tag). After I realized that there is no way to use mvn release plugin, since there was no snapshot dependencies. So I changed every pom version with the following command line: find . -name pom.xml |xargs perl -i -n -e 's/2\.2\.3/2.2.3.1-SNAPSHOT/; print;' I took a quick look at the svn diff output (for the record, inside the pom.xml of the dojo plugin, there is a 2.2.3 tlibVersion which fell into a trap) At this point I committed the change on the branch and perform a new release. Maurizio Cucchiara 2011/8/31 Łukasz Lenart lukasz.len...@googlemail.com 2011/8/31 Maurizio Cucchiara mcucchi...@apache.org: Hi Lukasz, I would like, even if I have no idea where to start :) Do you usually follow that guide [1]? Have you any hint? [1] http://struts.apache.org/2.2.3/docs/creating-and-signing-a-struts-22x-distribution.html Yes, I based on that and constantly improve it ;-) The first thing that release must base on the version from tag not from trunk. Checkout, apply patch and adjust poms to be ready for release process with Maven release plugin. Then you can follow the guideline. Maybe it would be a good idea how make a fast track release :-) Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Looking for Release Manager
Lukasz, I am afraid I am not able to perform the 6,7,8 tasks illustrated on http://s.apache.org/rel, since I have no enough karma. Maurizio Cucchiara On 4 September 2011 22:11, Maurizio Cucchiara mcucchi...@apache.org wrote: Hi guys, Struts 2.2.3.1 is on the way, anyway I am in doubt about the release process. Could you review please the step I followed? First I created a STRUTS_2_2_3_1 branch from the latest release (STRUTS_2_2_3 tag). After I realized that there is no way to use mvn release plugin, since there was no snapshot dependencies. So I changed every pom version with the following command line: find . -name pom.xml |xargs perl -i -n -e 's/2\.2\.3/2.2.3.1-SNAPSHOT/; print;' I took a quick look at the svn diff output (for the record, inside the pom.xml of the dojo plugin, there is a 2.2.3 tlibVersion which fell into a trap) At this point I committed the change on the branch and perform a new release. Maurizio Cucchiara 2011/8/31 Łukasz Lenart lukasz.len...@googlemail.com 2011/8/31 Maurizio Cucchiara mcucchi...@apache.org: Hi Lukasz, I would like, even if I have no idea where to start :) Do you usually follow that guide [1]? Have you any hint? [1] http://struts.apache.org/2.2.3/docs/creating-and-signing-a-struts-22x-distribution.html Yes, I based on that and constantly improve it ;-) The first thing that release must base on the version from tag not from trunk. Checkout, apply patch and adjust poms to be ready for release process with Maven release plugin. Then you can follow the guideline. Maybe it would be a good idea how make a fast track release :-) Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Looking for Release Manager
On Sun, Sep 4, 2011 at 4:17 PM, Maurizio Cucchiara mcucchi...@apache.org wrote: Lukasz, I am afraid I am not able to perform the 6,7,8 tasks illustrated on http://s.apache.org/rel, since I have no enough karma. Which steps do you mean? Any committer should be able to stage a release and call a vote. (There is a 'versions' plugin that can make the version number changes, though if you're good at regular expressions your way was probably quicker. :) ) -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Looking for Release Manager
Hi Lukasz, I would like, even if I have no idea where to start :) Do you usually follow that guide [1]? Have you any hint? [1] http://struts.apache.org/2.2.3/docs/creating-and-signing-a-struts-22x-distribution.html Maurizio Cucchiara 2011/8/31 Łukasz Lenart lukasz.len...@googlemail.com: Hi, Who want to take that role and prepare release of 2.2.3.1 ? It's a fast track release with important security fix, it must base on 2.2.3 tag, not on the trunk. Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Looking for Release Manager
2011/8/31 Maurizio Cucchiara mcucchi...@apache.org: Hi Lukasz, I would like, even if I have no idea where to start :) Do you usually follow that guide [1]? Have you any hint? [1] http://struts.apache.org/2.2.3/docs/creating-and-signing-a-struts-22x-distribution.html Yes, I based on that and constantly improve it ;-) The first thing that release must base on the version from tag not from trunk. Checkout, apply patch and adjust poms to be ready for release process with Maven release plugin. Then you can follow the guideline. Maybe it would be a good idea how make a fast track release :-) Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [S2] Struts 2.0.8 release manager (was PROPOSAL: s1 modules module)
Ted, I'll work on the 2.0.8 tickets for now. I'd like to resolve everything on the 'Struts 2.0.8 TODO' page. Next, I'd like to step up and release 2.0.8. At this time, I'm not sure about a time table. I'll post back as soon as the time frame is set. Personally, I'm winding down another kids soccer season, which will free up a little extra time, but that's 2 weeks away. Thanks again for all your help. Let me know if there's something I'm missing. -- James Mitchell On Apr 26, 2007, at 7:11 AM, Ted Husted wrote: If we're not going on to 2.0.9, then the JIRA stuff is mainly done. We'd just need to bulk-change whatever we don't close in 2.0.8 to 2.1.0. A release notes page is setup, which links to the detail from JIRA. If we apply any more patches, it would be nice to expand on the bullets. Otherwise, we can just delete the empty bullets, and rely on the JIRA detail. The main thing would be to hookup with the new XW2 release. It would be nice to apply the patches, but those could also be done in 2.1.0, if we are ready to move on that soon. AFAIK, the 2.1.0 blocker is the portlet plugin, which is in turn being blocked by stalled discussions regarding abstracting the URL handling. -Ted. On 4/23/07, James Mitchell [EMAIL PROTECTED] wrote: Ted, I'm willing to do s2 releases. However, even with the documentation on the wiki, the process still seems very complicated. As far as building and pushing bits around, I'm ok with it, but when it comes to the release notes and open/close jira issues, it's not totally clear (to me) what needs to happen. If you don't mind a little hand holding, I don't mind volunteering the time. -- James Mitchell - 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: [S2] Struts 2.0.8 release manager (was PROPOSAL: s1 modules module)
2007/4/26, Ted Husted [EMAIL PROTECTED]: If we're not going on to 2.0.9, then the JIRA stuff is mainly done. We'd just need to bulk-change whatever we don't close in 2.0.8 to 2.1.0. Currently the Tiles 2 plugin depends on Tiles 2.0.1, but since Tiles 2.0.3 is going to be released (well in fact it is online, it needs only to be announced and the website updated) I think that, if we cannot release it in 2.0.8, we should do it in 2.0.9 Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Struts 2.0.8 release manager (was PROPOSAL: s1 modules module)
If need be, we could also release a plugin separately. The JARs are built separately, we just glom it all together as an administrative convenience. If someone wanted to re-roll the Tiles plugin against a new Tiles 2 build and call it release 2.0.8.1, that would be simple to do. On 4/26/07, Antonio Petrelli [EMAIL PROTECTED] wrote: 2007/4/26, Ted Husted [EMAIL PROTECTED]: If we're not going on to 2.0.9, then the JIRA stuff is mainly done. We'd just need to bulk-change whatever we don't close in 2.0.8 to 2.1.0. Currently the Tiles 2 plugin depends on Tiles 2.0.1, but since Tiles 2.0.3 is going to be released (well in fact it is online, it needs only to be announced and the website updated) I think that, if we cannot release it in 2.0.8, we should do it in 2.0.9 Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Struts 2.0.8 release manager
I was hoping to find some time this week to apply the ten patches, and run 2.0.8 against the new XW release, but yet another task has just been dropped in my lap, and time will be very short this month. If no one else has time to spend on a 2.0.8 release, I'll try to schedule some time in May. After 2.0.8, we might want to push everything else to 2.1.0. AFAIK, the remaining 2.1.0 trigger is moving the portlet code to a plugin, and the blocker there is a resolution of the notion of a abstracting the URL handling. As to release management, we might not want to create tickets as subtasks of the omnibus ticket. If the ticket is not resolved within that milestone, then we have to go through a series of menus to change its parent. We will spend more time moving the ticket than it took to create it. Worse, there seems to be no way to promote a subtask to a task, so we limit our options. -Ted. On 4/11/07, Ted Husted [EMAIL PROTECTED] wrote: Is anyone else interest in volunteering as the Struts 2.0.8 release manager. I'll be spending some of my volunteer hours helping the Click framework join the ASF, as one of the podling mentors, and I don't want to stretch myself too thin. At this point, the release trigger would be a new XWork 2 release. The process is running smoothly now. The major bull work is applying contributor patches. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[S2] Struts 2.0.8 release manager
Is anyone else interest in volunteering as the Struts 2.0.8 release manager. I'll be spending some of my volunteer hours helping the Click framework join the ASF, as one of the podling mentors, and I don't want to stretch myself too thin. At this point, the release trigger would be a new XWork 2 release. The process is running smoothly now. The major bull work is applying contributor patches. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Struts 2.0.8 release manager
What's the timeline for this release? -- James Mitchell On Apr 11, 2007, at 11:40 AM, Ted Husted wrote: Is anyone else interest in volunteering as the Struts 2.0.8 release manager. I'll be spending some of my volunteer hours helping the Click framework join the ASF, as one of the podling mentors, and I don't want to stretch myself too thin. At this point, the release trigger would be a new XWork 2 release. The process is running smoothly now. The major bull work is applying contributor patches. -Ted. - 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: [S2] Struts 2.0.8 release manager
Ted, James, XWork 2.0.2 is scheduled for the weekend. We are just making sure, that the latest patches did not break anything. -Rainer What's the timeline for this release? -- James Mitchell On Apr 11, 2007, at 11:40 AM, Ted Husted wrote: Is anyone else interest in volunteering as the Struts 2.0.8 release manager. I'll be spending some of my volunteer hours helping the Click framework join the ASF, as one of the podling mentors, and I don't want to stretch myself too thin. At this point, the release trigger would be a new XWork 2 release. The process is running smoothly now. The major bull work is applying contributor patches. -Ted. - 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] -- Rainer Hermanns aixcept Neupforte 16 52062 Aachen - Germany w: http://aixcept.de/ t:+49-241-4012247 m: +49-170-3432912 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Struts 2.0.8 release manager
I was playing with showcase yesterday and everything seems to be working musachy On 4/11/07, Rainer Hermanns [EMAIL PROTECTED] wrote: Ted, James, XWork 2.0.2 is scheduled for the weekend. We are just making sure, that the latest patches did not break anything. -Rainer What's the timeline for this release? -- James Mitchell On Apr 11, 2007, at 11:40 AM, Ted Husted wrote: Is anyone else interest in volunteering as the Struts 2.0.8 release manager. I'll be spending some of my volunteer hours helping the Click framework join the ASF, as one of the podling mentors, and I don't want to stretch myself too thin. At this point, the release trigger would be a new XWork 2 release. The process is running smoothly now. The major bull work is applying contributor patches. -Ted. - 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] -- Rainer Hermanns aixcept Neupforte 16 52062 Aachen - Germany w: http://aixcept.de/ t:+49-241-4012247 m: +49-170-3432912 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd
