You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@baremaps.apache.org by Bertil Chapuis <bc...@gmail.com> on 2023/03/07 23:02:46 UTC
[VOTE] Release Baremaps 0.7.1 (incubating)
Hello Baremaps Community,
This is a call for a vote to the 1st release candidate for Apache Baremaps, version 0.7.1-incubating.
We request project mentors (binded) as well as all contributors (unbinded) and users to review and vote on this incubator release. This release contains a DISCLAIMER-WIP file and the identified issues will be addressed in future releases.
The commit to be voted upon:
https://github.com/apache/incubator-baremaps/commit/b999c68a371ba9ffc7ca2ca5815746cdcf6bcfd1 <https://github.com/apache/incubator-baremaps/commit/cf4a80be49d6961c84caeb281906fd4dfa40f904>
The full list of changes and release notes are available at:
https://github.com/apache/incubator-baremaps/releases/tag/v0.7.1-rc1 <https://github.com/apache/incubator-baremaps/releases/tag/untagged-8dd4aefde3f5a905c163>
Best regards,
Bertil Chapuis
Re: [VOTE] Release Baremaps 0.7.1 (incubating)
Posted by Josh Fischer <jo...@joshfischer.io>.
Ha! Friday works for me. I’ll send a another email off list to get a time
set. Once we find something that works for both of us, I’ll send it out to
this thread in case anyone wants to participate.
On Wed, Mar 8, 2023 at 4:38 PM Bertil Chapuis <bc...@gmail.com> wrote:
> This is a good list of points and pointers. It will take some time to
> address them all, but it clarify things a lot.
>
> Regarding the hash, I appreciate the necessity to include it in the email.
> However, if we assume that we and our users download the files with an
> uncompromised machine and over an HTTPS connection, the risk of a MITM
> attack seems low. In my understanding, the main risk occurs when an
> attacker gains access to the download server. In this case, he could
> probably tamper both the .tar.gz file and the .sha256 files and this may go
> unnoticed for a while. I didn’t raised this issue because I wanted to focus
> on the release, but I would prefer to store the .sha256 file on another
> server or to rely exclusively on PGP (the .asc file is more difficult to
> tamper). What do you think?
>
> Regarding the release of artifacts, GitHub and Docker are mentioned as
> being approved distribution platforms in the “Other release platforms”
> section of the guide [1]. I didn’t realise that a special authorisation was
> needed.
>
> Josh, thank you for your availability. Would Friday work for you? (I’m not
> sure about your time zone; GMT+1 for me).
>
> As for wine, beer and whisky, I suppose that a good old release process
> eventually tastes good ;)
>
> Bertil
>
> [1] https://infra.apache.org/release-distribution.html#other-platforms
>
>
> > On 8 Mar 2023, at 21:01, Julian Hyde <jh...@apache.org> wrote:
> >
> > -1 (binding)
> >
> > This is a very good first release candidate from an incubating project.
> > Many things are done right. As noted below, the release needs to be in
> > tar.gz form, but I reviewed the release based on the contents of git.
> When
> > the errors have been fixed, let's have another release candidate.
> >
> > What I checked:
> > * I checked NOTICE, LICENSE, DISCLAIMER-WIP. README was great (could use
> a
> > newline at the end).
> > * I could not check hashes or signatures (because this was based on Git,
> > not a tarball).
> > * I compiled and ran tests using Maven 3.8.1 on OpenJDK 17 Ubuntu Linux.
> > * I ran Apache RAT using ‘mvn rat:rat’ and it failed with 'Too many
> > unapproved licenses: 6’. This is not unexpected at this stage.
> >
> > A lot of files need headers: .xml, .html, .sql, .js, .md, .yaml files can
> > all support headers. Can you document the source of the .tif, .ico and
> > .json files, since these don’t admit headers?
> >
> > ——
> >
> > I agree with Josh’s remarks regarding the structure of the release and
> the
> > email.
> >
> > The KEYS file can wait a little while, but the main thing we are voting
> on
> > is the artifacts - the tar.gz file and its signature files. It may seem
> > archaic in this age of Git, but it makes sense when you remember that a
> > release is a legal action - publishing something that wasn’t previously
> > published.
> >
> > Bertil, a good place to start would be the vote email from an established
> > project such as Calcite. For example, the vote for Calcite 1.33 rc1 [1].
> > Just about everything in that email is necessary:
> > * the subject should include the name of the release candidate, so that
> you
> > can start a distinct email thread for the next RC;
> > * there are release notes (often external to the release, so that they
> can
> > be modified after the vote);
> > * there is a git tag (mainly for convenience)
> > * the artifacts to be voted on are staged at
> > dist.apache.org/repos/dist/dev/{project}/{version}
> <http://dist.apache.org/repos/dist/dev/%7Bproject%7D/%7Bversion%7D>
> > <http://dist.apache.org/repos/dist/dev/%7Bproject%7D/%7Bversion%7D>;
> after
> > the vote they will be moved to
> > dist.apache.org/dist/release/{project}/{version}
> <http://dist.apache.org/dist/release/%7Bproject%7D/%7Bversion%7D>
> > <http://dist.apache.org/dist/release/%7Bproject%7D/%7Bversion%7D>
> > * hashes must be in the email, so that voters can be sure they are voting
> > on the same artifacts that the release manager prepared (i.e. to prevent
> > man-in-the-middle attacks);
> > * the maven repository containing binary artifacts can be skipped;
> > * the PGP key of the release manager who signed the artifacts;
> > * instructions for how people can recreate the release (optional);
> > * instructions for people to build the release based on these artifacts;
> > * instructions how to vote, the duration of the vote.
> >
> > If you are not already doing so, document the process of making the
> > release, and write scripts. Anyone on the PPMC should be able to step
> into
> > the release manager role.
> >
> > Community members, please vote on the release, and please say what you
> did
> > to verify the release; don’t just vote ‘+1’ or ‘-1’.
> >
> > Julian
> >
> >
> > On Mar 8, 2023, at 11:06 AM, Josh Fischer <jo...@joshfischer.io> wrote:
> >
> > Using dist.a.o is a must [1]. You could always ask for a special case to
> > be made, but I think you'd have to have solid reasoning behind it. We
> will
> > have to use the mirroring system as well [2]. I can be available in the
> > next few days.
> >
> > 1.
> https://infra.apache.org/release-distribution.html#public-distribution
> > 2. https://infra.apache.org/release-distribution.html#download-links
> >
> > On Wed, Mar 8, 2023 at 8:28 AM Bertil Chapuis <bc...@gmail.com>
> wrote:
> >
> >> Sorry, I should have better checked the URLs.
> >>
> >> Here is the release (incorrect in the first mail):
> >> https://github.com/apache/incubator-baremaps/releases/tag/v0.7.1-rc1
> >>
> >> And the corresponding commit (correct in the first mail):
> >>
> >>
> https://github.com/apache/incubator-baremaps/commit/b999c68a371ba9ffc7ca2ca5815746cdcf6bcfd1
> >>
> >> 1. We need accompanying checksum files and a gpg signature to verify the
> >> integrity of the download.
> >>
> >>
> >> The signature and integrity files are listed among the assets attached
> to
> >> the release (screenshot).
> >>
> >> 2. The archives should be uploaded to somewhere like
> >> https://dist.apache.org/repos/dist/dev/incubator/
> >> baremaps/baremaps-${version}-candidate-1
> >> <
> >>
> https://dist.apache.org/repos/dist/dev/incubator/baremaps/baremaps-${version}-candidate-1
> >>>
> >>
> >>
> >> Is this mandatory, or can we use the release page of GitHub to
> distribute
> >> the release?
> >>
> >> 4. We also need a KEYS file here:
> >> https://dist.apache.org/repos/dist/dev/incubator/baremaps/. An
> example is
> >> https://dist.apache.org/repos/dist/dev/incubator/datalab/KEYS
> >>
> >>
> >> I just read the instructions on release signing and I will probably have
> >> to adapt the release pipeline.
> >> https://infra.apache.org/release-signing.html
> >>
> >> There may be other things, but this is a rough first pass. We don't
> need
> >> to start a new vote or create a new candidate. I think we can simply
> add
> >> the required files and continue the vote.
> >>
> >>
> >> I will upload the necessary files. Would someone be available to review
> >> the release pipeline during a video call before resuming the vote? I
> think
> >> it may be a good way to eliminate the most salient problems.
> >>
> >> Best,
> >>
> >> Bertil
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@baremaps.apache.org
> For additional commands, e-mail: dev-help@baremaps.apache.org
>
> --
Sent from A Mobile Device
Re: [VOTE] Release Baremaps 0.7.1 (incubating)
Posted by Bertil Chapuis <bc...@gmail.com>.
Hello Everyone,
I updated the release instructions[1] to include the comments of Josh and Julian.
Thank you Léonard for your work on the license headers. We still have some work ahead regarding licensing (favicon, minified js, etc.), but in my understanding the DISCLAIMER-WIP allows us to release and address these issues later on.
I will try to drop a 2nd release candidate with this updated release early next week.
Best,
Bertil
[1] - https://github.com/apache/incubator-baremaps/blob/f7e178c33bed7fd2f669d4d7392280b8d3bbb110/RELEASE.md
> On 9 Mar 2023, at 11:19, Bertil Chapuis <bc...@gmail.com> wrote:
>
> Sounds good, let’s focus on implementing a release process conform to Apache's guidelines.
>
>> On 9 Mar 2023, at 10:52, Julian Hyde <jh...@apache.org> wrote:
>>
>> I could attempt to justify why ASF uses sha256 (or higher) and PGP for
>> its releases, but suffice to say that's just just how ASF does
>> releases and it's not negotiable.
>>
>> On Wed, Mar 8, 2023 at 2:38 PM Bertil Chapuis <bc...@gmail.com> wrote:
>>>
>>> This is a good list of points and pointers. It will take some time to address them all, but it clarify things a lot.
>>>
>>> Regarding the hash, I appreciate the necessity to include it in the email. However, if we assume that we and our users download the files with an uncompromised machine and over an HTTPS connection, the risk of a MITM attack seems low. In my understanding, the main risk occurs when an attacker gains access to the download server. In this case, he could probably tamper both the .tar.gz file and the .sha256 files and this may go unnoticed for a while. I didn’t raised this issue because I wanted to focus on the release, but I would prefer to store the .sha256 file on another server or to rely exclusively on PGP (the .asc file is more difficult to tamper). What do you think?
>>>
>>> Regarding the release of artifacts, GitHub and Docker are mentioned as being approved distribution platforms in the “Other release platforms” section of the guide [1]. I didn’t realise that a special authorisation was needed.
>>>
>>> Josh, thank you for your availability. Would Friday work for you? (I’m not sure about your time zone; GMT+1 for me).
>>>
>>> As for wine, beer and whisky, I suppose that a good old release process eventually tastes good ;)
>>>
>>> Bertil
>>>
>>> [1] https://infra.apache.org/release-distribution.html#other-platforms
>>>
>>>
>>>> On 8 Mar 2023, at 21:01, Julian Hyde <jh...@apache.org> wrote:
>>>>
>>>> -1 (binding)
>>>>
>>>> This is a very good first release candidate from an incubating project.
>>>> Many things are done right. As noted below, the release needs to be in
>>>> tar.gz form, but I reviewed the release based on the contents of git. When
>>>> the errors have been fixed, let's have another release candidate.
>>>>
>>>> What I checked:
>>>> * I checked NOTICE, LICENSE, DISCLAIMER-WIP. README was great (could use a
>>>> newline at the end).
>>>> * I could not check hashes or signatures (because this was based on Git,
>>>> not a tarball).
>>>> * I compiled and ran tests using Maven 3.8.1 on OpenJDK 17 Ubuntu Linux.
>>>> * I ran Apache RAT using ‘mvn rat:rat’ and it failed with 'Too many
>>>> unapproved licenses: 6’. This is not unexpected at this stage.
>>>>
>>>> A lot of files need headers: .xml, .html, .sql, .js, .md, .yaml files can
>>>> all support headers. Can you document the source of the .tif, .ico and
>>>> .json files, since these don’t admit headers?
>>>>
>>>> ——
>>>>
>>>> I agree with Josh’s remarks regarding the structure of the release and the
>>>> email.
>>>>
>>>> The KEYS file can wait a little while, but the main thing we are voting on
>>>> is the artifacts - the tar.gz file and its signature files. It may seem
>>>> archaic in this age of Git, but it makes sense when you remember that a
>>>> release is a legal action - publishing something that wasn’t previously
>>>> published.
>>>>
>>>> Bertil, a good place to start would be the vote email from an established
>>>> project such as Calcite. For example, the vote for Calcite 1.33 rc1 [1].
>>>> Just about everything in that email is necessary:
>>>> * the subject should include the name of the release candidate, so that you
>>>> can start a distinct email thread for the next RC;
>>>> * there are release notes (often external to the release, so that they can
>>>> be modified after the vote);
>>>> * there is a git tag (mainly for convenience)
>>>> * the artifacts to be voted on are staged at
>>>> dist.apache.org/repos/dist/dev/{project}/{version}
>>>> <http://dist.apache.org/repos/dist/dev/%7Bproject%7D/%7Bversion%7D>; after
>>>> the vote they will be moved to
>>>> dist.apache.org/dist/release/{project}/{version}
>>>> <http://dist.apache.org/dist/release/%7Bproject%7D/%7Bversion%7D>
>>>> * hashes must be in the email, so that voters can be sure they are voting
>>>> on th£ning binary artifacts can be skipped;
>>>> * the PGP key of the release manager who signed the artifacts;
>>>> * instructions for how people can recreate the release (optional);
>>>> * instructions for people to build the release based on these artifacts;
>>>> * instructions how to vote, the duration of the vote.
>>>>
>>>> If you are not already doing so, document the process of making the
>>>> release, and write scripts. Anyone on the PPMC should be able to step into
>>>> the release manager role.
>>>>
>>>> Community members, please vote on the release, and please say what you did
>>>> to verify the release; don’t just vote ‘+1’ or ‘-1’.
>>>>
>>>> Julian
>>>>
>>>>
>>>> On Mar 8, 2023, at 11:06 AM, Josh Fischer <jo...@joshfischer.io> wrote:
>>>>
>>>> Using dist.a.o is a must [1]. You could always ask for a special case to
>>>> be made, but I think you'd have to have solid reasoning behind it. We will
>>>> have to use the mirroring system as well [2]. I can be available in the
>>>> next few days.
>>>>
>>>> 1. https://infra.apache.org/release-distribution.html#public-distribution
>>>> 2. https://infra.apache.org/release-distribution.html#download-links
>>>>
>>>> On Wed, Mar 8, 2023 at 8:28 AM Bertil Chapuis <bc...@gmail.com> wrote:
>>>>
>>>>> Sorry, I should have better checked the URLs.
>>>>>
>>>>> Here is the release (incorrect in the first mail):
>>>>> https://github.com/apache/incubator-baremaps/releases/tag/v0.7.1-rc1
>>>>>
>>>>> And the corresponding commit (correct in the first mail):
>>>>>
>>>>> https://github.com/apache/incubator-baremaps/commit/b999c68a371ba9ffc7ca2ca5815746cdcf6bcfd1
>>>>>
>>>>> 1. We need accompanying checksum files and a gpg signature to verify the
>>>>> integrity of the download.
>>>>>
>>>>>
>>>>> The signature and integrity files are listed among the assets attached to
>>>>> the release (screenshot).
>>>>>
>>>>> 2. The archives should be uploaded to somewhere like
>>>>> https://dist.apache.org/repos/dist/dev/incubator/
>>>>> baremaps/baremaps-${version}-candidate-1
>>>>> <
>>>>> https://dist.apache.org/repos/dist/dev/incubator/baremaps/baremaps-${version}-candidate-1
>>>>>>
>>>>>
>>>>>
>>>>> Is this mandatory, or can we use the release page of GitHub to distribute
>>>>> the release?
>>>>>
>>>>> 4. We also need a KEYS file here:
>>>>> https://dist.apache.org/repos/dist/dev/incubator/baremaps/. An example is
>>>>> https://dist.apache.org/repos/dist/dev/incubator/datalab/KEYS
>>>>>
>>>>>
>>>>> I just read the instructions on release signing and I will probably have
>>>>> to adapt the release pipeline.
>>>>> https://infra.apache.org/release-signing.html
>>>>>
>>>>> There may be other things, but this is a rough first pass. We don't need
>>>>> to start a new vote or create a new candidate. I think we can simply add
>>>>> the required files and continue the vote.
>>>>>
>>>>>
>>>>> I will upload the necessary files. Would someone be available to review
>>>>> the release pipeline during a video call before resuming the vote? I think
>>>>> it may be a good way to eliminate the most salient problems.
>>>>>
>>>>> Best,
>>>>>
>>>>> Bertil
>>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@baremaps.apache.org
>>> For additional commands, e-mail: dev-help@baremaps.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@baremaps.apache.org
>> For additional commands, e-mail: dev-help@baremaps.apache.org
>>
>
Re: [VOTE] Release Baremaps 0.7.1 (incubating)
Posted by Bertil Chapuis <bc...@gmail.com>.
Sounds good, let’s focus on implementing a release process conform to Apache's guidelines.
> On 9 Mar 2023, at 10:52, Julian Hyde <jh...@apache.org> wrote:
>
> I could attempt to justify why ASF uses sha256 (or higher) and PGP for
> its releases, but suffice to say that's just just how ASF does
> releases and it's not negotiable.
>
> On Wed, Mar 8, 2023 at 2:38 PM Bertil Chapuis <bc...@gmail.com> wrote:
>>
>> This is a good list of points and pointers. It will take some time to address them all, but it clarify things a lot.
>>
>> Regarding the hash, I appreciate the necessity to include it in the email. However, if we assume that we and our users download the files with an uncompromised machine and over an HTTPS connection, the risk of a MITM attack seems low. In my understanding, the main risk occurs when an attacker gains access to the download server. In this case, he could probably tamper both the .tar.gz file and the .sha256 files and this may go unnoticed for a while. I didn’t raised this issue because I wanted to focus on the release, but I would prefer to store the .sha256 file on another server or to rely exclusively on PGP (the .asc file is more difficult to tamper). What do you think?
>>
>> Regarding the release of artifacts, GitHub and Docker are mentioned as being approved distribution platforms in the “Other release platforms” section of the guide [1]. I didn’t realise that a special authorisation was needed.
>>
>> Josh, thank you for your availability. Would Friday work for you? (I’m not sure about your time zone; GMT+1 for me).
>>
>> As for wine, beer and whisky, I suppose that a good old release process eventually tastes good ;)
>>
>> Bertil
>>
>> [1] https://infra.apache.org/release-distribution.html#other-platforms
>>
>>
>>> On 8 Mar 2023, at 21:01, Julian Hyde <jh...@apache.org> wrote:
>>>
>>> -1 (binding)
>>>
>>> This is a very good first release candidate from an incubating project.
>>> Many things are done right. As noted below, the release needs to be in
>>> tar.gz form, but I reviewed the release based on the contents of git. When
>>> the errors have been fixed, let's have another release candidate.
>>>
>>> What I checked:
>>> * I checked NOTICE, LICENSE, DISCLAIMER-WIP. README was great (could use a
>>> newline at the end).
>>> * I could not check hashes or signatures (because this was based on Git,
>>> not a tarball).
>>> * I compiled and ran tests using Maven 3.8.1 on OpenJDK 17 Ubuntu Linux.
>>> * I ran Apache RAT using ‘mvn rat:rat’ and it failed with 'Too many
>>> unapproved licenses: 6’. This is not unexpected at this stage.
>>>
>>> A lot of files need headers: .xml, .html, .sql, .js, .md, .yaml files can
>>> all support headers. Can you document the source of the .tif, .ico and
>>> .json files, since these don’t admit headers?
>>>
>>> ——
>>>
>>> I agree with Josh’s remarks regarding the structure of the release and the
>>> email.
>>>
>>> The KEYS file can wait a little while, but the main thing we are voting on
>>> is the artifacts - the tar.gz file and its signature files. It may seem
>>> archaic in this age of Git, but it makes sense when you remember that a
>>> release is a legal action - publishing something that wasn’t previously
>>> published.
>>>
>>> Bertil, a good place to start would be the vote email from an established
>>> project such as Calcite. For example, the vote for Calcite 1.33 rc1 [1].
>>> Just about everything in that email is necessary:
>>> * the subject should include the name of the release candidate, so that you
>>> can start a distinct email thread for the next RC;
>>> * there are release notes (often external to the release, so that they can
>>> be modified after the vote);
>>> * there is a git tag (mainly for convenience)
>>> * the artifacts to be voted on are staged at
>>> dist.apache.org/repos/dist/dev/{project}/{version}
>>> <http://dist.apache.org/repos/dist/dev/%7Bproject%7D/%7Bversion%7D>; after
>>> the vote they will be moved to
>>> dist.apache.org/dist/release/{project}/{version}
>>> <http://dist.apache.org/dist/release/%7Bproject%7D/%7Bversion%7D>
>>> * hashes must be in the email, so that voters can be sure they are voting
>>> on th£ning binary artifacts can be skipped;
>>> * the PGP key of the release manager who signed the artifacts;
>>> * instructions for how people can recreate the release (optional);
>>> * instructions for people to build the release based on these artifacts;
>>> * instructions how to vote, the duration of the vote.
>>>
>>> If you are not already doing so, document the process of making the
>>> release, and write scripts. Anyone on the PPMC should be able to step into
>>> the release manager role.
>>>
>>> Community members, please vote on the release, and please say what you did
>>> to verify the release; don’t just vote ‘+1’ or ‘-1’.
>>>
>>> Julian
>>>
>>>
>>> On Mar 8, 2023, at 11:06 AM, Josh Fischer <jo...@joshfischer.io> wrote:
>>>
>>> Using dist.a.o is a must [1]. You could always ask for a special case to
>>> be made, but I think you'd have to have solid reasoning behind it. We will
>>> have to use the mirroring system as well [2]. I can be available in the
>>> next few days.
>>>
>>> 1. https://infra.apache.org/release-distribution.html#public-distribution
>>> 2. https://infra.apache.org/release-distribution.html#download-links
>>>
>>> On Wed, Mar 8, 2023 at 8:28 AM Bertil Chapuis <bc...@gmail.com> wrote:
>>>
>>>> Sorry, I should have better checked the URLs.
>>>>
>>>> Here is the release (incorrect in the first mail):
>>>> https://github.com/apache/incubator-baremaps/releases/tag/v0.7.1-rc1
>>>>
>>>> And the corresponding commit (correct in the first mail):
>>>>
>>>> https://github.com/apache/incubator-baremaps/commit/b999c68a371ba9ffc7ca2ca5815746cdcf6bcfd1
>>>>
>>>> 1. We need accompanying checksum files and a gpg signature to verify the
>>>> integrity of the download.
>>>>
>>>>
>>>> The signature and integrity files are listed among the assets attached to
>>>> the release (screenshot).
>>>>
>>>> 2. The archives should be uploaded to somewhere like
>>>> https://dist.apache.org/repos/dist/dev/incubator/
>>>> baremaps/baremaps-${version}-candidate-1
>>>> <
>>>> https://dist.apache.org/repos/dist/dev/incubator/baremaps/baremaps-${version}-candidate-1
>>>>>
>>>>
>>>>
>>>> Is this mandatory, or can we use the release page of GitHub to distribute
>>>> the release?
>>>>
>>>> 4. We also need a KEYS file here:
>>>> https://dist.apache.org/repos/dist/dev/incubator/baremaps/. An example is
>>>> https://dist.apache.org/repos/dist/dev/incubator/datalab/KEYS
>>>>
>>>>
>>>> I just read the instructions on release signing and I will probably have
>>>> to adapt the release pipeline.
>>>> https://infra.apache.org/release-signing.html
>>>>
>>>> There may be other things, but this is a rough first pass. We don't need
>>>> to start a new vote or create a new candidate. I think we can simply add
>>>> the required files and continue the vote.
>>>>
>>>>
>>>> I will upload the necessary files. Would someone be available to review
>>>> the release pipeline during a video call before resuming the vote? I think
>>>> it may be a good way to eliminate the most salient problems.
>>>>
>>>> Best,
>>>>
>>>> Bertil
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@baremaps.apache.org
>> For additional commands, e-mail: dev-help@baremaps.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@baremaps.apache.org
> For additional commands, e-mail: dev-help@baremaps.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@baremaps.apache.org
For additional commands, e-mail: dev-help@baremaps.apache.org
Re: [VOTE] Release Baremaps 0.7.1 (incubating)
Posted by Julian Hyde <jh...@apache.org>.
I could attempt to justify why ASF uses sha256 (or higher) and PGP for
its releases, but suffice to say that's just just how ASF does
releases and it's not negotiable.
On Wed, Mar 8, 2023 at 2:38 PM Bertil Chapuis <bc...@gmail.com> wrote:
>
> This is a good list of points and pointers. It will take some time to address them all, but it clarify things a lot.
>
> Regarding the hash, I appreciate the necessity to include it in the email. However, if we assume that we and our users download the files with an uncompromised machine and over an HTTPS connection, the risk of a MITM attack seems low. In my understanding, the main risk occurs when an attacker gains access to the download server. In this case, he could probably tamper both the .tar.gz file and the .sha256 files and this may go unnoticed for a while. I didn’t raised this issue because I wanted to focus on the release, but I would prefer to store the .sha256 file on another server or to rely exclusively on PGP (the .asc file is more difficult to tamper). What do you think?
>
> Regarding the release of artifacts, GitHub and Docker are mentioned as being approved distribution platforms in the “Other release platforms” section of the guide [1]. I didn’t realise that a special authorisation was needed.
>
> Josh, thank you for your availability. Would Friday work for you? (I’m not sure about your time zone; GMT+1 for me).
>
> As for wine, beer and whisky, I suppose that a good old release process eventually tastes good ;)
>
> Bertil
>
> [1] https://infra.apache.org/release-distribution.html#other-platforms
>
>
> > On 8 Mar 2023, at 21:01, Julian Hyde <jh...@apache.org> wrote:
> >
> > -1 (binding)
> >
> > This is a very good first release candidate from an incubating project.
> > Many things are done right. As noted below, the release needs to be in
> > tar.gz form, but I reviewed the release based on the contents of git. When
> > the errors have been fixed, let's have another release candidate.
> >
> > What I checked:
> > * I checked NOTICE, LICENSE, DISCLAIMER-WIP. README was great (could use a
> > newline at the end).
> > * I could not check hashes or signatures (because this was based on Git,
> > not a tarball).
> > * I compiled and ran tests using Maven 3.8.1 on OpenJDK 17 Ubuntu Linux.
> > * I ran Apache RAT using ‘mvn rat:rat’ and it failed with 'Too many
> > unapproved licenses: 6’. This is not unexpected at this stage.
> >
> > A lot of files need headers: .xml, .html, .sql, .js, .md, .yaml files can
> > all support headers. Can you document the source of the .tif, .ico and
> > .json files, since these don’t admit headers?
> >
> > ——
> >
> > I agree with Josh’s remarks regarding the structure of the release and the
> > email.
> >
> > The KEYS file can wait a little while, but the main thing we are voting on
> > is the artifacts - the tar.gz file and its signature files. It may seem
> > archaic in this age of Git, but it makes sense when you remember that a
> > release is a legal action - publishing something that wasn’t previously
> > published.
> >
> > Bertil, a good place to start would be the vote email from an established
> > project such as Calcite. For example, the vote for Calcite 1.33 rc1 [1].
> > Just about everything in that email is necessary:
> > * the subject should include the name of the release candidate, so that you
> > can start a distinct email thread for the next RC;
> > * there are release notes (often external to the release, so that they can
> > be modified after the vote);
> > * there is a git tag (mainly for convenience)
> > * the artifacts to be voted on are staged at
> > dist.apache.org/repos/dist/dev/{project}/{version}
> > <http://dist.apache.org/repos/dist/dev/%7Bproject%7D/%7Bversion%7D>; after
> > the vote they will be moved to
> > dist.apache.org/dist/release/{project}/{version}
> > <http://dist.apache.org/dist/release/%7Bproject%7D/%7Bversion%7D>
> > * hashes must be in the email, so that voters can be sure they are voting
> > on the same artifacts that the release manager prepared (i.e. to prevent
> > man-in-the-middle attacks);
> > * the maven repository containing binary artifacts can be skipped;
> > * the PGP key of the release manager who signed the artifacts;
> > * instructions for how people can recreate the release (optional);
> > * instructions for people to build the release based on these artifacts;
> > * instructions how to vote, the duration of the vote.
> >
> > If you are not already doing so, document the process of making the
> > release, and write scripts. Anyone on the PPMC should be able to step into
> > the release manager role.
> >
> > Community members, please vote on the release, and please say what you did
> > to verify the release; don’t just vote ‘+1’ or ‘-1’.
> >
> > Julian
> >
> >
> > On Mar 8, 2023, at 11:06 AM, Josh Fischer <jo...@joshfischer.io> wrote:
> >
> > Using dist.a.o is a must [1]. You could always ask for a special case to
> > be made, but I think you'd have to have solid reasoning behind it. We will
> > have to use the mirroring system as well [2]. I can be available in the
> > next few days.
> >
> > 1. https://infra.apache.org/release-distribution.html#public-distribution
> > 2. https://infra.apache.org/release-distribution.html#download-links
> >
> > On Wed, Mar 8, 2023 at 8:28 AM Bertil Chapuis <bc...@gmail.com> wrote:
> >
> >> Sorry, I should have better checked the URLs.
> >>
> >> Here is the release (incorrect in the first mail):
> >> https://github.com/apache/incubator-baremaps/releases/tag/v0.7.1-rc1
> >>
> >> And the corresponding commit (correct in the first mail):
> >>
> >> https://github.com/apache/incubator-baremaps/commit/b999c68a371ba9ffc7ca2ca5815746cdcf6bcfd1
> >>
> >> 1. We need accompanying checksum files and a gpg signature to verify the
> >> integrity of the download.
> >>
> >>
> >> The signature and integrity files are listed among the assets attached to
> >> the release (screenshot).
> >>
> >> 2. The archives should be uploaded to somewhere like
> >> https://dist.apache.org/repos/dist/dev/incubator/
> >> baremaps/baremaps-${version}-candidate-1
> >> <
> >> https://dist.apache.org/repos/dist/dev/incubator/baremaps/baremaps-${version}-candidate-1
> >>>
> >>
> >>
> >> Is this mandatory, or can we use the release page of GitHub to distribute
> >> the release?
> >>
> >> 4. We also need a KEYS file here:
> >> https://dist.apache.org/repos/dist/dev/incubator/baremaps/. An example is
> >> https://dist.apache.org/repos/dist/dev/incubator/datalab/KEYS
> >>
> >>
> >> I just read the instructions on release signing and I will probably have
> >> to adapt the release pipeline.
> >> https://infra.apache.org/release-signing.html
> >>
> >> There may be other things, but this is a rough first pass. We don't need
> >> to start a new vote or create a new candidate. I think we can simply add
> >> the required files and continue the vote.
> >>
> >>
> >> I will upload the necessary files. Would someone be available to review
> >> the release pipeline during a video call before resuming the vote? I think
> >> it may be a good way to eliminate the most salient problems.
> >>
> >> Best,
> >>
> >> Bertil
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@baremaps.apache.org
> For additional commands, e-mail: dev-help@baremaps.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@baremaps.apache.org
For additional commands, e-mail: dev-help@baremaps.apache.org
Re: [VOTE] Release Baremaps 0.7.1 (incubating)
Posted by Bertil Chapuis <bc...@gmail.com>.
This is a good list of points and pointers. It will take some time to address them all, but it clarify things a lot.
Regarding the hash, I appreciate the necessity to include it in the email. However, if we assume that we and our users download the files with an uncompromised machine and over an HTTPS connection, the risk of a MITM attack seems low. In my understanding, the main risk occurs when an attacker gains access to the download server. In this case, he could probably tamper both the .tar.gz file and the .sha256 files and this may go unnoticed for a while. I didn’t raised this issue because I wanted to focus on the release, but I would prefer to store the .sha256 file on another server or to rely exclusively on PGP (the .asc file is more difficult to tamper). What do you think?
Regarding the release of artifacts, GitHub and Docker are mentioned as being approved distribution platforms in the “Other release platforms” section of the guide [1]. I didn’t realise that a special authorisation was needed.
Josh, thank you for your availability. Would Friday work for you? (I’m not sure about your time zone; GMT+1 for me).
As for wine, beer and whisky, I suppose that a good old release process eventually tastes good ;)
Bertil
[1] https://infra.apache.org/release-distribution.html#other-platforms
> On 8 Mar 2023, at 21:01, Julian Hyde <jh...@apache.org> wrote:
>
> -1 (binding)
>
> This is a very good first release candidate from an incubating project.
> Many things are done right. As noted below, the release needs to be in
> tar.gz form, but I reviewed the release based on the contents of git. When
> the errors have been fixed, let's have another release candidate.
>
> What I checked:
> * I checked NOTICE, LICENSE, DISCLAIMER-WIP. README was great (could use a
> newline at the end).
> * I could not check hashes or signatures (because this was based on Git,
> not a tarball).
> * I compiled and ran tests using Maven 3.8.1 on OpenJDK 17 Ubuntu Linux.
> * I ran Apache RAT using ‘mvn rat:rat’ and it failed with 'Too many
> unapproved licenses: 6’. This is not unexpected at this stage.
>
> A lot of files need headers: .xml, .html, .sql, .js, .md, .yaml files can
> all support headers. Can you document the source of the .tif, .ico and
> .json files, since these don’t admit headers?
>
> ——
>
> I agree with Josh’s remarks regarding the structure of the release and the
> email.
>
> The KEYS file can wait a little while, but the main thing we are voting on
> is the artifacts - the tar.gz file and its signature files. It may seem
> archaic in this age of Git, but it makes sense when you remember that a
> release is a legal action - publishing something that wasn’t previously
> published.
>
> Bertil, a good place to start would be the vote email from an established
> project such as Calcite. For example, the vote for Calcite 1.33 rc1 [1].
> Just about everything in that email is necessary:
> * the subject should include the name of the release candidate, so that you
> can start a distinct email thread for the next RC;
> * there are release notes (often external to the release, so that they can
> be modified after the vote);
> * there is a git tag (mainly for convenience)
> * the artifacts to be voted on are staged at
> dist.apache.org/repos/dist/dev/{project}/{version}
> <http://dist.apache.org/repos/dist/dev/%7Bproject%7D/%7Bversion%7D>; after
> the vote they will be moved to
> dist.apache.org/dist/release/{project}/{version}
> <http://dist.apache.org/dist/release/%7Bproject%7D/%7Bversion%7D>
> * hashes must be in the email, so that voters can be sure they are voting
> on the same artifacts that the release manager prepared (i.e. to prevent
> man-in-the-middle attacks);
> * the maven repository containing binary artifacts can be skipped;
> * the PGP key of the release manager who signed the artifacts;
> * instructions for how people can recreate the release (optional);
> * instructions for people to build the release based on these artifacts;
> * instructions how to vote, the duration of the vote.
>
> If you are not already doing so, document the process of making the
> release, and write scripts. Anyone on the PPMC should be able to step into
> the release manager role.
>
> Community members, please vote on the release, and please say what you did
> to verify the release; don’t just vote ‘+1’ or ‘-1’.
>
> Julian
>
>
> On Mar 8, 2023, at 11:06 AM, Josh Fischer <jo...@joshfischer.io> wrote:
>
> Using dist.a.o is a must [1]. You could always ask for a special case to
> be made, but I think you'd have to have solid reasoning behind it. We will
> have to use the mirroring system as well [2]. I can be available in the
> next few days.
>
> 1. https://infra.apache.org/release-distribution.html#public-distribution
> 2. https://infra.apache.org/release-distribution.html#download-links
>
> On Wed, Mar 8, 2023 at 8:28 AM Bertil Chapuis <bc...@gmail.com> wrote:
>
>> Sorry, I should have better checked the URLs.
>>
>> Here is the release (incorrect in the first mail):
>> https://github.com/apache/incubator-baremaps/releases/tag/v0.7.1-rc1
>>
>> And the corresponding commit (correct in the first mail):
>>
>> https://github.com/apache/incubator-baremaps/commit/b999c68a371ba9ffc7ca2ca5815746cdcf6bcfd1
>>
>> 1. We need accompanying checksum files and a gpg signature to verify the
>> integrity of the download.
>>
>>
>> The signature and integrity files are listed among the assets attached to
>> the release (screenshot).
>>
>> 2. The archives should be uploaded to somewhere like
>> https://dist.apache.org/repos/dist/dev/incubator/
>> baremaps/baremaps-${version}-candidate-1
>> <
>> https://dist.apache.org/repos/dist/dev/incubator/baremaps/baremaps-${version}-candidate-1
>>>
>>
>>
>> Is this mandatory, or can we use the release page of GitHub to distribute
>> the release?
>>
>> 4. We also need a KEYS file here:
>> https://dist.apache.org/repos/dist/dev/incubator/baremaps/. An example is
>> https://dist.apache.org/repos/dist/dev/incubator/datalab/KEYS
>>
>>
>> I just read the instructions on release signing and I will probably have
>> to adapt the release pipeline.
>> https://infra.apache.org/release-signing.html
>>
>> There may be other things, but this is a rough first pass. We don't need
>> to start a new vote or create a new candidate. I think we can simply add
>> the required files and continue the vote.
>>
>>
>> I will upload the necessary files. Would someone be available to review
>> the release pipeline during a video call before resuming the vote? I think
>> it may be a good way to eliminate the most salient problems.
>>
>> Best,
>>
>> Bertil
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@baremaps.apache.org
For additional commands, e-mail: dev-help@baremaps.apache.org
Re: [VOTE] Release Baremaps 0.7.1 (incubating)
Posted by Léonard Besseau <l....@gmail.com>.
-1 due to the issues raised by Julian and josh. Otherwise it's OK for me
on the functional part.
Thanks a lot Bertil for your work on this release.
I've opened #598 Fix missing license
<https://github.com/apache/incubator-baremaps/pull/598> for the files that
need a header with the license.
What I checked:
- Full test suite from the git repository with 'mvn clean test -P
integration' and maven 3.8.6 openJDK 19 OSX
- Full test suite from the src.zip artifacts in the release with 'mvn clean
test -P integration' and maven 3.8.6 openJDK 19 OSX (Hash:
4455dbfef94146d4d98292d3feb5da458f4f4e5b1938d27ec2f387ae5b8352bcd93a72cd2d7d1ff7d2479ee890c8a070d626d01786e0a89704fc09af2b197e56
)
- Checked the Release hash
- Ran the OpenStreetMap example
Best
Léonard
On Wed, 8 Mar 2023 at 21:01, Julian Hyde <jh...@apache.org> wrote:
> -1 (binding)
>
> This is a very good first release candidate from an incubating project.
> Many things are done right. As noted below, the release needs to be in
> tar.gz form, but I reviewed the release based on the contents of git. When
> the errors have been fixed, let's have another release candidate.
>
> What I checked:
> * I checked NOTICE, LICENSE, DISCLAIMER-WIP. README was great (could use a
> newline at the end).
> * I could not check hashes or signatures (because this was based on Git,
> not a tarball).
> * I compiled and ran tests using Maven 3.8.1 on OpenJDK 17 Ubuntu Linux.
> * I ran Apache RAT using ‘mvn rat:rat’ and it failed with 'Too many
> unapproved licenses: 6’. This is not unexpected at this stage.
>
> A lot of files need headers: .xml, .html, .sql, .js, .md, .yaml files can
> all support headers. Can you document the source of the .tif, .ico and
> .json files, since these don’t admit headers?
>
> ——
>
> I agree with Josh’s remarks regarding the structure of the release and the
> email.
>
> The KEYS file can wait a little while, but the main thing we are voting on
> is the artifacts - the tar.gz file and its signature files. It may seem
> archaic in this age of Git, but it makes sense when you remember that a
> release is a legal action - publishing something that wasn’t previously
> published.
>
> Bertil, a good place to start would be the vote email from an established
> project such as Calcite. For example, the vote for Calcite 1.33 rc1 [1].
> Just about everything in that email is necessary:
> * the subject should include the name of the release candidate, so that you
> can start a distinct email thread for the next RC;
> * there are release notes (often external to the release, so that they can
> be modified after the vote);
> * there is a git tag (mainly for convenience)
> * the artifacts to be voted on are staged at
> dist.apache.org/repos/dist/dev/{project}/{version}
> <http://dist.apache.org/repos/dist/dev/%7Bproject%7D/%7Bversion%7D>
> <http://dist.apache.org/repos/dist/dev/%7Bproject%7D/%7Bversion%7D>; after
> the vote they will be moved to
> dist.apache.org/dist/release/{project}/{version}
> <http://dist.apache.org/dist/release/%7Bproject%7D/%7Bversion%7D>
> <http://dist.apache.org/dist/release/%7Bproject%7D/%7Bversion%7D>
> * hashes must be in the email, so that voters can be sure they are voting
> on the same artifacts that the release manager prepared (i.e. to prevent
> man-in-the-middle attacks);
> * the maven repository containing binary artifacts can be skipped;
> * the PGP key of the release manager who signed the artifacts;
> * instructions for how people can recreate the release (optional);
> * instructions for people to build the release based on these artifacts;
> * instructions how to vote, the duration of the vote.
>
> If you are not already doing so, document the process of making the
> release, and write scripts. Anyone on the PPMC should be able to step into
> the release manager role.
>
> Community members, please vote on the release, and please say what you did
> to verify the release; don’t just vote ‘+1’ or ‘-1’.
>
> Julian
>
>
> On Mar 8, 2023, at 11:06 AM, Josh Fischer <jo...@joshfischer.io> wrote:
>
> Using dist.a.o is a must [1]. You could always ask for a special case to
> be made, but I think you'd have to have solid reasoning behind it. We will
> have to use the mirroring system as well [2]. I can be available in the
> next few days.
>
> 1. https://infra.apache.org/release-distribution.html#public-distribution
> 2. https://infra.apache.org/release-distribution.html#download-links
>
> On Wed, Mar 8, 2023 at 8:28 AM Bertil Chapuis <bc...@gmail.com> wrote:
>
> > Sorry, I should have better checked the URLs.
> >
> > Here is the release (incorrect in the first mail):
> > https://github.com/apache/incubator-baremaps/releases/tag/v0.7.1-rc1
> >
> > And the corresponding commit (correct in the first mail):
> >
> >
> https://github.com/apache/incubator-baremaps/commit/b999c68a371ba9ffc7ca2ca5815746cdcf6bcfd1
> >
> > 1. We need accompanying checksum files and a gpg signature to verify the
> > integrity of the download.
> >
> >
> > The signature and integrity files are listed among the assets attached to
> > the release (screenshot).
> >
> > 2. The archives should be uploaded to somewhere like
> > https://dist.apache.org/repos/dist/dev/incubator/
> > baremaps/baremaps-${version}-candidate-1
> > <
> >
> https://dist.apache.org/repos/dist/dev/incubator/baremaps/baremaps-${version}-candidate-1
> > >
> >
> >
> > Is this mandatory, or can we use the release page of GitHub to distribute
> > the release?
> >
> > 4. We also need a KEYS file here:
> > https://dist.apache.org/repos/dist/dev/incubator/baremaps/. An example
> is
> > https://dist.apache.org/repos/dist/dev/incubator/datalab/KEYS
> >
> >
> > I just read the instructions on release signing and I will probably have
> > to adapt the release pipeline.
> > https://infra.apache.org/release-signing.html
> >
> > There may be other things, but this is a rough first pass. We don't need
> > to start a new vote or create a new candidate. I think we can simply
> add
> > the required files and continue the vote.
> >
> >
> > I will upload the necessary files. Would someone be available to review
> > the release pipeline during a video call before resuming the vote? I
> think
> > it may be a good way to eliminate the most salient problems.
> >
> > Best,
> >
> > Bertil
> >
>
Re: [VOTE] Release Baremaps 0.7.1 (incubating)
Posted by Julian Hyde <jh...@apache.org>.
-1 (binding)
This is a very good first release candidate from an incubating project.
Many things are done right. As noted below, the release needs to be in
tar.gz form, but I reviewed the release based on the contents of git. When
the errors have been fixed, let's have another release candidate.
What I checked:
* I checked NOTICE, LICENSE, DISCLAIMER-WIP. README was great (could use a
newline at the end).
* I could not check hashes or signatures (because this was based on Git,
not a tarball).
* I compiled and ran tests using Maven 3.8.1 on OpenJDK 17 Ubuntu Linux.
* I ran Apache RAT using ‘mvn rat:rat’ and it failed with 'Too many
unapproved licenses: 6’. This is not unexpected at this stage.
A lot of files need headers: .xml, .html, .sql, .js, .md, .yaml files can
all support headers. Can you document the source of the .tif, .ico and
.json files, since these don’t admit headers?
——
I agree with Josh’s remarks regarding the structure of the release and the
email.
The KEYS file can wait a little while, but the main thing we are voting on
is the artifacts - the tar.gz file and its signature files. It may seem
archaic in this age of Git, but it makes sense when you remember that a
release is a legal action - publishing something that wasn’t previously
published.
Bertil, a good place to start would be the vote email from an established
project such as Calcite. For example, the vote for Calcite 1.33 rc1 [1].
Just about everything in that email is necessary:
* the subject should include the name of the release candidate, so that you
can start a distinct email thread for the next RC;
* there are release notes (often external to the release, so that they can
be modified after the vote);
* there is a git tag (mainly for convenience)
* the artifacts to be voted on are staged at
dist.apache.org/repos/dist/dev/{project}/{version}
<http://dist.apache.org/repos/dist/dev/%7Bproject%7D/%7Bversion%7D>; after
the vote they will be moved to
dist.apache.org/dist/release/{project}/{version}
<http://dist.apache.org/dist/release/%7Bproject%7D/%7Bversion%7D>
* hashes must be in the email, so that voters can be sure they are voting
on the same artifacts that the release manager prepared (i.e. to prevent
man-in-the-middle attacks);
* the maven repository containing binary artifacts can be skipped;
* the PGP key of the release manager who signed the artifacts;
* instructions for how people can recreate the release (optional);
* instructions for people to build the release based on these artifacts;
* instructions how to vote, the duration of the vote.
If you are not already doing so, document the process of making the
release, and write scripts. Anyone on the PPMC should be able to step into
the release manager role.
Community members, please vote on the release, and please say what you did
to verify the release; don’t just vote ‘+1’ or ‘-1’.
Julian
On Mar 8, 2023, at 11:06 AM, Josh Fischer <jo...@joshfischer.io> wrote:
Using dist.a.o is a must [1]. You could always ask for a special case to
be made, but I think you'd have to have solid reasoning behind it. We will
have to use the mirroring system as well [2]. I can be available in the
next few days.
1. https://infra.apache.org/release-distribution.html#public-distribution
2. https://infra.apache.org/release-distribution.html#download-links
On Wed, Mar 8, 2023 at 8:28 AM Bertil Chapuis <bc...@gmail.com> wrote:
> Sorry, I should have better checked the URLs.
>
> Here is the release (incorrect in the first mail):
> https://github.com/apache/incubator-baremaps/releases/tag/v0.7.1-rc1
>
> And the corresponding commit (correct in the first mail):
>
> https://github.com/apache/incubator-baremaps/commit/b999c68a371ba9ffc7ca2ca5815746cdcf6bcfd1
>
> 1. We need accompanying checksum files and a gpg signature to verify the
> integrity of the download.
>
>
> The signature and integrity files are listed among the assets attached to
> the release (screenshot).
>
> 2. The archives should be uploaded to somewhere like
> https://dist.apache.org/repos/dist/dev/incubator/
> baremaps/baremaps-${version}-candidate-1
> <
> https://dist.apache.org/repos/dist/dev/incubator/baremaps/baremaps-${version}-candidate-1
> >
>
>
> Is this mandatory, or can we use the release page of GitHub to distribute
> the release?
>
> 4. We also need a KEYS file here:
> https://dist.apache.org/repos/dist/dev/incubator/baremaps/. An example is
> https://dist.apache.org/repos/dist/dev/incubator/datalab/KEYS
>
>
> I just read the instructions on release signing and I will probably have
> to adapt the release pipeline.
> https://infra.apache.org/release-signing.html
>
> There may be other things, but this is a rough first pass. We don't need
> to start a new vote or create a new candidate. I think we can simply add
> the required files and continue the vote.
>
>
> I will upload the necessary files. Would someone be available to review
> the release pipeline during a video call before resuming the vote? I think
> it may be a good way to eliminate the most salient problems.
>
> Best,
>
> Bertil
>
Re: [VOTE] Release Baremaps 0.7.1 (incubating)
Posted by Josh Fischer <jo...@joshfischer.io>.
Using dist.a.o is a must [1]. You could always ask for a special case to
be made, but I think you'd have to have solid reasoning behind it. We will
have to use the mirroring system as well [2]. I can be available in the
next few days.
1. https://infra.apache.org/release-distribution.html#public-distribution
2. https://infra.apache.org/release-distribution.html#download-links
On Wed, Mar 8, 2023 at 8:28 AM Bertil Chapuis <bc...@gmail.com> wrote:
> Sorry, I should have better checked the URLs.
>
> Here is the release (incorrect in the first mail):
> https://github.com/apache/incubator-baremaps/releases/tag/v0.7.1-rc1
>
> And the corresponding commit (correct in the first mail):
>
> https://github.com/apache/incubator-baremaps/commit/b999c68a371ba9ffc7ca2ca5815746cdcf6bcfd1
>
> 1. We need accompanying checksum files and a gpg signature to verify the
> integrity of the download.
>
>
> The signature and integrity files are listed among the assets attached to
> the release (screenshot).
>
> 2. The archives should be uploaded to somewhere like
> https://dist.apache.org/repos/dist/dev/incubator/
> baremaps/baremaps-${version}-candidate-1
> <
> https://dist.apache.org/repos/dist/dev/incubator/baremaps/baremaps-${version}-candidate-1
> >
>
>
> Is this mandatory, or can we use the release page of GitHub to distribute
> the release?
>
> 4. We also need a KEYS file here:
> https://dist.apache.org/repos/dist/dev/incubator/baremaps/. An example is
> https://dist.apache.org/repos/dist/dev/incubator/datalab/KEYS
>
>
> I just read the instructions on release signing and I will probably have
> to adapt the release pipeline.
> https://infra.apache.org/release-signing.html
>
> There may be other things, but this is a rough first pass. We don't need
> to start a new vote or create a new candidate. I think we can simply add
> the required files and continue the vote.
>
>
> I will upload the necessary files. Would someone be available to review
> the release pipeline during a video call before resuming the vote? I think
> it may be a good way to eliminate the most salient problems.
>
> Best,
>
> Bertil
>
Re: [VOTE] Release Baremaps 0.7.1 (incubating)
Posted by Bertil Chapuis <bc...@gmail.com>.
Sorry, I should have better checked the URLs.
Here is the release (incorrect in the first mail):
https://github.com/apache/incubator-baremaps/releases/tag/v0.7.1-rc1 <https://github.com/apache/incubator-baremaps/releases/tag/v0.7.1-rc1>
And the corresponding commit (correct in the first mail):
https://github.com/apache/incubator-baremaps/commit/b999c68a371ba9ffc7ca2ca5815746cdcf6bcfd1 <https://github.com/apache/incubator-baremaps/commit/b999c68a371ba9ffc7ca2ca5815746cdcf6bcfd1>
> 1. We need accompanying checksum files and a gpg signature to verify the
> integrity of the download.
The signature and integrity files are listed among the assets attached to the release (screenshot).
> 2. The archives should be uploaded to somewhere like
> https://dist.apache.org/repos/dist/dev/incubator/ <https://dist.apache.org/repos/dist/dev/incubator/>
> baremaps/baremaps-${version}-candidate-1
> <https://dist.apache.org/repos/dist/dev/incubator/baremaps/baremaps-${version}-candidate-1>
Is this mandatory, or can we use the release page of GitHub to distribute the release?
> 4. We also need a KEYS file here:
> https://dist.apache.org/repos/dist/dev/incubator/baremaps/ <https://dist.apache.org/repos/dist/dev/incubator/baremaps/>. An example is
> https://dist.apache.org/repos/dist/dev/incubator/datalab/KEYS <https://dist.apache.org/repos/dist/dev/incubator/datalab/KEYS>
I just read the instructions on release signing and I will probably have to adapt the release pipeline.
https://infra.apache.org/release-signing.html <https://infra.apache.org/release-signing.html>
> There may be other things, but this is a rough first pass. We don't need
> to start a new vote or create a new candidate. I think we can simply add
> the required files and continue the vote.
I will upload the necessary files. Would someone be available to review the release pipeline during a video call before resuming the vote? I think it may be a good way to eliminate the most salient problems.
Best,
Bertil
Re: [VOTE] Release Baremaps 0.7.1 (incubating)
Posted by Josh Fischer <jo...@joshfischer.io>.
Hi,
-1.
We have a few things to do.
1. We need accompanying checksum files and a gpg signature to verify the
integrity of the download.
2. The archives should be uploaded to somewhere like
https://dist.apache.org/repos/dist/dev/incubator/
baremaps/baremaps-${version}-candidate-1
<https://dist.apache.org/repos/dist/dev/incubator/baremaps/baremaps-${version}-candidate-1>
3. This link doesn't work:
https://github.com/apache/incubator-baremaps/releases/tag/untagged-8dd4aefde3f5a905c163
4. We also need a KEYS file here:
https://dist.apache.org/repos/dist/dev/incubator/baremaps/. An example is
https://dist.apache.org/repos/dist/dev/incubator/datalab/KEYS
There may be other things, but this is a rough first pass. We don't need
to start a new vote or create a new candidate. I think we can simply add
the required files and continue the vote.
- Josh
On Wed, Mar 8, 2023 at 4:36 AM Andrea Borghi <an...@camptocamp.com>
wrote:
> +1 non-binding
>
> On Wed, Mar 8, 2023 at 12:02 AM Bertil Chapuis <bc...@gmail.com> wrote:
>
> > Hello Baremaps Community,
> >
> > This is a call for a vote to the 1st release candidate for Apache
> > Baremaps, version 0.7.1-incubating.
> >
> > We request project mentors (binded) as well as all contributors
> > (unbinded) and users to review and vote on this incubator release. This
> > release contains a DISCLAIMER-WIP file and the identified issues will be
> > addressed in future releases.
> >
> > The commit to be voted upon:
> >
> >
> https://github.com/apache/incubator-baremaps/commit/b999c68a371ba9ffc7ca2ca5815746cdcf6bcfd1
> > <
> https://github.com/apache/incubator-baremaps/commit/cf4a80be49d6961c84caeb281906fd4dfa40f904
> >
> >
> > The full list of changes and release notes are available at:
> > https://github.com/apache/incubator-baremaps/releases/tag/v0.7.1-rc1
> > <
> https://github.com/apache/incubator-baremaps/releases/tag/untagged-8dd4aefde3f5a905c163
> >
> >
> > Best regards,
> >
> > Bertil Chapuis
> >
>
Re: [VOTE] Release Baremaps 0.7.1 (incubating)
Posted by Andrea Borghi <an...@camptocamp.com>.
+1 non-binding
On Wed, Mar 8, 2023 at 12:02 AM Bertil Chapuis <bc...@gmail.com> wrote:
> Hello Baremaps Community,
>
> This is a call for a vote to the 1st release candidate for Apache
> Baremaps, version 0.7.1-incubating.
>
> We request project mentors (binded) as well as all contributors
> (unbinded) and users to review and vote on this incubator release. This
> release contains a DISCLAIMER-WIP file and the identified issues will be
> addressed in future releases.
>
> The commit to be voted upon:
>
> https://github.com/apache/incubator-baremaps/commit/b999c68a371ba9ffc7ca2ca5815746cdcf6bcfd1
> <https://github.com/apache/incubator-baremaps/commit/cf4a80be49d6961c84caeb281906fd4dfa40f904>
>
> The full list of changes and release notes are available at:
> https://github.com/apache/incubator-baremaps/releases/tag/v0.7.1-rc1
> <https://github.com/apache/incubator-baremaps/releases/tag/untagged-8dd4aefde3f5a905c163>
>
> Best regards,
>
> Bertil Chapuis
>