You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2022/04/28 16:16:19 UTC
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Testing Tomcat pre-releases
Posted by Christopher Schultz <ch...@christopherschultz.net>.
David,
On 4/29/22 15:24, David Cleary wrote:
>> -----Original Message-----
>> From: Christopher Schultz <ch...@christopherschultz.net>
>> Sent: Thursday, April 28, 2022 12:16 PM
>> To: Tomcat Users List <us...@tomcat.apache.org>
>> 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?dev@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Testing Tomcat pre-releases
Posted by David Cleary <da...@progress.com.INVALID>.
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Thursday, April 28, 2022 12:16 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> 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