Re: Testing Tomcat pre-releases
David, On 4/29/22 15:24, David Cleary wrote: -Original Message- From: Christopher Schultz Sent: Thursday, April 28, 2022 12:16 PM To: Tomcat Users List Subject: Re: Testing Tomcat pre-releases David, (Replying to the Tomcat users@ list) On 4/28/22 08:45, David Cleary wrote: Hi Chris. We have spoken over the years at various Apachecons. In one of your presentations, you talked about smoke testing Tomcat pre-releases. We just got bitten by a regression in 9.0.62, and the team that is responsible for updating it is interested in the details on doing this. Can you give me details on where we would pick up pre-release builds and what mailing list we should monitor and report any issues. Sure. Briefly, the release process goes like this[1]: 1. Announce intent to do a release on dev@ mailing list; call for any last-minute commits or conversations. This often doesn't happen because we have a release-cadence that follows a rough schedule of prep-and-release around the beginning of each month. 2. Tag the release + prepare a release candidate build. This is a formal process which results in a vote. 3. Declare a vote on Tomcat x.y.z for a [VOTE] thread posted to the dev@ mailing list. Here is your opportunity to give feedback on the release. (See below). Information about where to get the release candidates is available in that [VOTE] message. 4. Assuming the [VOTE] passes, the release is promoted from "candidate" to "official release", distributed to mirrors, and announced. So, how can you participate in #3 above? Well, the release candidate includes all the binary artifacts from a regular release, so you can use it just as you would usually use a "real" release. You can also build it from source as you always could, etc. The "Getting Started Hacking Tomcat" presentation[2] contains some information about how to build from source, run the unit-tests, etc. if you'd like some guidance. If you find a bug and are able to contribute a test-case for us to include in our test process, that would be great: it will prevent the bug from coming-back as a regression in the future. Simply reply to the [VOTE] thread with any concerns you may have, or, if everything is great, we'd love to have your "+1 to release" vote as well. Technically speaking, non-PMC-members don't have a binding vote, but I have never seen a vote move-forward in spite of legitimate negative community feedback. If something is wrong with the release, we'll cancel it, the fix issue, and repeat the process with a new release candidate (and version number). Let us know if you have any questions. -chris Thanks Chris. Is this where we can expect the pre-releases to show up? https://repository.apache.org/content/groups/staging/org/apache/tomcat/tomcat/ No, you should expect them to show up here: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/ (for Tomcat 8) There's nothing there, now, because it's been promoted to released, here: https://dist.apache.org/repos/dist/release/tomcat/tomcat-8/ There is a directory like that for each of the current releases (10.1, 10.0, 9.0, 8.5). The [VOTE] message to the dev list will contain a link to the binaries proposed for release. Have a look at the history of [VOTE] emails here: https://lists.apache.org/list?d...@tomcat.apache.org:lte=1M:[VOTE]%20release One issue I've run into is that our Gradle builds use the Windows 32 and 64 bit zip files since we ship with the commons-daemon executable. Don't really know where or Artifactory gets those from. Are those available in staging somewhere before release? Yep. The "release" directory contains byte-for-byte identical items to whatever was in the "dev" directory during the voting process. So, for example: https://dist.apache.org/repos/dist/release/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78-windows-x86.zip Hope that helps, -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Testing Tomcat pre-releases
> -Original Message- > From: Christopher Schultz > Sent: Thursday, April 28, 2022 12:16 PM > To: Tomcat Users List > Subject: Re: Testing Tomcat pre-releases > > David, > > (Replying to the Tomcat users@ list) > > On 4/28/22 08:45, David Cleary wrote: > > Hi Chris. We have spoken over the years at various Apachecons. In one > > of your presentations, you talked about smoke testing Tomcat pre-releases. > > We just got bitten by a regression in 9.0.62, and the team that is > > responsible for updating it is interested in the details on doing this. > > Can you give me details on where we would pick up pre-release builds > > and what mailing list we should monitor and report any issues. > > Sure. > > Briefly, the release process goes like this[1]: > > 1. Announce intent to do a release on dev@ mailing list; call for any > last-minute > commits or conversations. This often doesn't happen because we have a > release-cadence that follows a rough schedule of prep-and-release around the > beginning of each month. > > 2. Tag the release + prepare a release candidate build. This is a formal > process > which results in a vote. > > 3. Declare a vote on Tomcat x.y.z for a [VOTE] thread posted to the dev@ > mailing list. Here is your opportunity to give feedback on the release. > (See below). Information about where to get the release candidates is > available > in that [VOTE] message. > > 4. Assuming the [VOTE] passes, the release is promoted from "candidate" > to "official release", distributed to mirrors, and announced. > > So, how can you participate in #3 above? > > Well, the release candidate includes all the binary artifacts from a regular > release, so you can use it just as you would usually use a "real" release. > You can > also build it from source as you always could, etc. > > The "Getting Started Hacking Tomcat" presentation[2] contains some > information about how to build from source, run the unit-tests, etc. if you'd > like > some guidance. > > If you find a bug and are able to contribute a test-case for us to include in > our > test process, that would be great: it will prevent the bug from coming-back > as a > regression in the future. > > Simply reply to the [VOTE] thread with any concerns you may have, or, if > everything is great, we'd love to have your "+1 to release" vote as well. > Technically speaking, non-PMC-members don't have a binding vote, but I have > never seen a vote move-forward in spite of legitimate negative community > feedback. If something is wrong with the release, we'll cancel it, the fix > issue, > and repeat the process with a new release candidate (and version number). > > Let us know if you have any questions. > > -chris > Thanks Chris. Is this where we can expect the pre-releases to show up? https://repository.apache.org/content/groups/staging/org/apache/tomcat/tomcat/ One issue I've run into is that our Gradle builds use the Windows 32 and 64 bit zip files since we ship with the commons-daemon executable. Don't really know where or Artifactory gets those from. Are those available in staging somewhere before release? Thanks Dave
Re: Testing Tomcat pre-releases
David, (Replying to the Tomcat users@ list) On 4/28/22 08:45, David Cleary wrote: Hi Chris. We have spoken over the years at various Apachecons. In one of your presentations, you talked about smoke testing Tomcat pre-releases. We just got bitten by a regression in 9.0.62, and the team that is responsible for updating it is interested in the details on doing this. Can you give me details on where we would pick up pre-release builds and what mailing list we should monitor and report any issues. Sure. Briefly, the release process goes like this[1]: 1. Announce intent to do a release on dev@ mailing list; call for any last-minute commits or conversations. This often doesn't happen because we have a release-cadence that follows a rough schedule of prep-and-release around the beginning of each month. 2. Tag the release + prepare a release candidate build. This is a formal process which results in a vote. 3. Declare a vote on Tomcat x.y.z for a [VOTE] thread posted to the dev@ mailing list. Here is your opportunity to give feedback on the release. (See below). Information about where to get the release candidates is available in that [VOTE] message. 4. Assuming the [VOTE] passes, the release is promoted from "candidate" to "official release", distributed to mirrors, and announced. So, how can you participate in #3 above? Well, the release candidate includes all the binary artifacts from a regular release, so you can use it just as you would usually use a "real" release. You can also build it from source as you always could, etc. The "Getting Started Hacking Tomcat" presentation[2] contains some information about how to build from source, run the unit-tests, etc. if you'd like some guidance. If you find a bug and are able to contribute a test-case for us to include in our test process, that would be great: it will prevent the bug from coming-back as a regression in the future. Simply reply to the [VOTE] thread with any concerns you may have, or, if everything is great, we'd love to have your "+1 to release" vote as well. Technically speaking, non-PMC-members don't have a binding vote, but I have never seen a vote move-forward in spite of legitimate negative community feedback. If something is wrong with the release, we'll cancel it, the fix issue, and repeat the process with a new release candidate (and version number). Let us know if you have any questions. -chris [1] Subject to the whims of the release managers, who are -- remember -- unpaid volunteers [2] https://tomcat.apache.org/presentations.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
