You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@buildstream.apache.org by Tristan Van Berkom <tr...@codethink.co.uk> on 2022/10/12 14:51:58 UTC
Proposal for 2.0 stable release
Dear BuildStream PMC members,
I have now released the 1.95.3 release candidate releases for both the
core BuildStream and BuildStream plugins repositories.
I don't know about future releases, but for 2.0 we will definitely be
releasing the main and plugin repositories together, so it makes sense
to also vote on both releases simultaneously.
Please take some time (but not too much) to personally assess your
confidence in the 1.95.3 releases.
To cast your vote, please reply with either a "+1" or a "-1".
This proposal counts as my +1, two additional +1s will count as our
official consensus to make the 2.0 release, provided that the +1s
outnumber any -1s.
For additional clarity, below are the specific assets on which we are
voting.
BuildStream 1.95.3
------------------
https://files.pythonhosted.org/packages/3a/cc/c5ae68441f8ce2e2cb056b291e7d20181a18d8545e2993161f68d0f2a07c/BuildStream-1.95.3.dev0.tar.gz
sha256sum: 4ce6b473e6d6738de30409adb4cd717165ba3ef12a1838fd7a919f9762327859
BuildStream plugins 1.95.3
--------------------------
https://files.pythonhosted.org/packages/93/66/5a583b4b6392e1dca6b448647e1bc99b77f4f1ba3bb5a6185810d2164475/buildstream-plugins-1.95.3.tar.gz
sha256sum: e0367ed9ffdb8c3fd8b4811b6d782fa024ea72b41507c60a250c2093880eed90
Cheers,
-Tristan
Re: Proposal for 2.0 stable release
Posted by Justin Mclean <jm...@apache.org>.
Hi,
Now that you are a TLP, the website will also need to comply with our web site policy. Please see https://www.apache.org/foundation/marks/pmcs
Kind Regards,
Justin
Re: Proposal for 2.0 stable release
Posted by Tristan Van Berkom <tr...@codethink.co.uk>.
Hi Christofer,
On Wed, 2022-10-19 at 06:16 +0000, Christofer Dutz wrote:
> Hi,
>
> And as I took the liberty of reviewing the 1.6.8 release according to the ASF rules, this would have been my response (Please use it as you like)
> It should point out things that should be addressed for a first Apache release.
> Things I usually don't check in my reviews as I never actually had to check it:
> - Apache releases should be available from Apache servers https://www.apache.org/dyn/closer.lua or https://archive.apache.org
>
> Hope this helps with the first release.
The BuildStream project has never made an official Apache release and
this will be the first one, so we're learning the ropes here.
Please take note that BuildStream was previously under LGPL, as remains
the case for the 1.x series, which is not under active feature
development but widely used and needs to have periodic bugfix releases
to address user issues (until it is eventually obsoleted by users
transitioning to the new BuildStream 2).
While we do not do "official apache releases" of BuildStream 1,
periodically tagging and announcing BuildStream 1 bugfix releases is
mandatory.
While I hope this clarifies things for your review of 1.6.8, I still
have a question regarding your response, my understanding of the
release policy (which I've read multiple times in the previous months),
is that release artifacts are only to be published on apache
infrastructure *after* the release candidate is approved by the PMC:
https://www.apache.org/legal/release-policy.html#release-distribution
Is there something we did wrong in the process of proposing this
release candidate to PMC members ?
Best Regards,
-Tristan
>
> Chris
>
> -------
>
> -1
>
> Chris
>
> [FAILED] Download all staged artifacts under the url specified in the
> release vote email.
> No signed artifacts, downloaded zip package from GitHub, no
> signatures or hashes
> [FAILED] Verify the signature is correct.
> No signature
> [FAILED] Check if the signature references an Apache email address.
> No signature
> [FAILED] Verify the SHA512 hashes.
> No hashes
> [OK] Unzip the archive.
> [OK] Verify the existence of LICENSE, NOTICE files in the extracted
> source bundle.
> [MINOR] Verify the content of LICENSE, NOTICE files in the extracted
> source bundle.
> Notice references 2021 and not 2022
> [FAILED] [RM] Run RAT externally to ensure there are no surprises.
> MANY files without Apache headers at all (Searching for
> http://www.apache.org/licenses/LICENSE-2.0 in the doc folder only
> brought one result at all, even in the tests directory there are
> Apache headers only on a few files)
> The list of non-approved license headers is 2078 lines/files long
> There are binary files in there: While I would call the ODG files
> sort of ok (OpenDocument Graphic File), the test contain archives
> which we generally don't like to see
> doc/bst2html.py is an MIT licensed file not mentioned in the LICENSE
> file
> The used Apache headers in generally all files are non-standard
> headers, which contain Copyright information to “Copyright (C) 2018
> Codethink Limited”) See here to how they should look like:
> https://www.apache.org/legal/src-headers.html
> [FAILED] Search for Copyright references, and if they are in headers,
> make sure these files containing them are mentioned in the LICENSE
> file.
> There’s code with Copyright headers for (All of these in various
> flavors), none of which are mentioned anywhere (NOTICE, LICENSE):
> - Copyright (C) 2019 Bloomberg Finance L.P.
> - Copyright (C) 2017 Codethink Limited
> - Copyright (c) 2014 by Armin Ronacher.
> - Copyright 2020 The Bazel Authors.
> - Copyright (c) 2015, Google Inc.
> - Copyright 2018 Google LLC
>
>
>
>
>
>
>
> On 2022/10/17 23:46:23 Daniel Gruno wrote:
> > Hi Tristan,
> >
> > As Apache BuildStream is now a TLP, please ensure that all future
> > releases agree with the overall release policy, as set out on
> > https://www.apache.org/legal/release-policy.html (especially the
> > MUST/MUST-NOTs). The document is quite exhaustive, and should cover
> > all the various gotchas.
> >
> > With regards,
> > Daniel.
> >
> > On 2022/10/12 14:51:58 Tristan Van Berkom wrote:
> > > Dear BuildStream PMC members,
> > >
> > > I have now released the 1.95.3 release candidate releases for
> > > both the
> > > core BuildStream and BuildStream plugins repositories.
> > >
> > > I don't know about future releases, but for 2.0 we will
> > > definitely be
> > > releasing the main and plugin repositories together, so it makes
> > > sense
> > > to also vote on both releases simultaneously.
> > >
> > > Please take some time (but not too much) to personally assess
> > > your
> > > confidence in the 1.95.3 releases.
> > >
> > > To cast your vote, please reply with either a "+1" or a "-1".
> > >
> > > This proposal counts as my +1, two additional +1s will count as
> > > our
> > > official consensus to make the 2.0 release, provided that the +1s
> > > outnumber any -1s.
> > >
> > > For additional clarity, below are the specific assets on which we
> > > are
> > > voting.
> > >
> > >
> > > BuildStream 1.95.3
> > > ------------------
> > > https://files.pythonhosted.org/packages/3a/cc/c5ae68441f8ce2e2cb056b291e7d20181a18d8545e2993161f68d0f2a07c/BuildStream-1.95.3.dev0.tar.gz
> > > sha256sum:
> > > 4ce6b473e6d6738de30409adb4cd717165ba3ef12a1838fd7a919f9762327859
> > >
> > >
> > > BuildStream plugins 1.95.3
> > > --------------------------
> > > https://files.pythonhosted.org/packages/93/66/5a583b4b6392e1dca6b448647e1bc99b77f4f1ba3bb5a6185810d2164475/buildstream-plugins-1.95.3.tar.gz
> > > sha256sum:
> > > e0367ed9ffdb8c3fd8b4811b6d782fa024ea72b41507c60a250c2093880eed90
> > >
> > >
> > > Cheers,
> > > -Tristan
> > >
> > >
> > >
Re: Proposal for 2.0 stable release
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi all,
And let me get this straight … not frustrated about Buildstream … I was referring to how “easy” it is to reply via the web-tool (Unfortunately you can’t beat a real email client ;-) )
Chris
From: Christofer Dutz <cd...@apache.org>
Date: Wednesday, 19. October 2022 at 18:03
To: dev@buildstream.apache.org <de...@buildstream.apache.org>
Subject: Re: Proposal for 2.0 stable release
Hi Justin,
thanks for that ... I was just staring to get frustrated with writing a response for an inline commented email in Ponymail ... I signed up for the list, that I can in future reply with a real mail-client.
But I guess I have nothing to add to what Justin wrote.
Thanks,
Chris
On 2022/10/19 15:48:33 Justin Mclean wrote:
> Hi,
>
> Perhaps I can help.
>
> > I'm reading that published release artifacts MUST be signed, and that
> > eligible voters in the voting stage MAY provide a signature.
>
> The release candidate needs to be signed so that someone reviewing the release can check that it contains what it should and will be the same as the released software.
>
> > FWIW, all of our release tags (internal or external) are signed tags,
> > and in any case I can surely provide a signature of the tarball(s) in
> > the next candidate proposal.
>
> A vote can't be on a GitHub tag (as that could change) it needs to be on an artefact as the contents of LICENSE and NOTICE depend on what is in that bundle.
>
> > I don't see any requirement for that in the policy, is this somehow a
> > requirement ?
>
> Yes it is a requirement to have a signed artefact. See https://www.apache.org/legal/release-policy.html#what-must-every-release-contain for details.
>
> > It is our policy to never clutter these files with license statements
>
> That may be the case but it is not ASF policy, please see https://www.apache.org/legal/src-headers.html. Note it mentions what files need ASF headers and the limited exceptions.
>
> > It is my understanding that such derivative works must be listed in the
> > NOTICE file, which `doc/bst2html.py` is certainly mentioned.
>
> This is not correct only limited things belong in a NOTICE file, all license information goes in the LICENSE file. Please see https://infra.apache.org/licensing-howto.html. Anything included that is MIT or BSD licensed needs to be mentioned in LICENSE not NOTICE.
>
> > The tarballs are extremely lightweight are are only included as data to
> > run tests against (they are essentially hello world programs, or just
> > tarballs which contain data that tests expect).
>
> An ASF release cannot include compiled source code, not even compile hello world programs. They could be download or compiled as part of the testing process, if they are used for tests. See https://www.apache.org/legal/release-policy.html#source-packages
>
> > Although I wonder how important this is given the lower case "should"
> > (as opposed to "MUST")...
>
> This is a requirement only non ASF projects can use the other header. See https://www.apache.org/legal/src-headers.html#headers
>
> > and perhaps this is acceptable if added to the NOTICE file in some way
>
> Only relocated copyright notices i.e. those where you have had permission form the copyright owner to remove should be added to the NOTICE file. See https://www.apache.org/legal/src-headers.html#header-existingcopyright
>
> > Right, these are all very easy to account for, but I could use some
> > guidance as to how precisely to update the NOTICE file for this.
>
> In general you would not update the NOTICE file, you would update the LICENSE file. If the 3rd party code is ALv2 and has a NOTICE file then some additions to the NOTICE file may be required. See https://infra.apache.org/licensing-howto.html#alv2-dep
>
> > It would strike me as very odd to modify the LICENSE file
>
> The LICNSE file needs to contain all of the license of bundles software in the release artefact. See https://infra.apache.org/licensing-howto.html#permissive-deps
>
> Kind Regards,
> Justin
>
Re: Proposal for 2.0 stable release
Posted by Christofer Dutz <cd...@apache.org>.
Hi Justin,
thanks for that ... I was just staring to get frustrated with writing a response for an inline commented email in Ponymail ... I signed up for the list, that I can in future reply with a real mail-client.
But I guess I have nothing to add to what Justin wrote.
Thanks,
Chris
On 2022/10/19 15:48:33 Justin Mclean wrote:
> Hi,
>
> Perhaps I can help.
>
> > I'm reading that published release artifacts MUST be signed, and that
> > eligible voters in the voting stage MAY provide a signature.
>
> The release candidate needs to be signed so that someone reviewing the release can check that it contains what it should and will be the same as the released software.
>
> > FWIW, all of our release tags (internal or external) are signed tags,
> > and in any case I can surely provide a signature of the tarball(s) in
> > the next candidate proposal.
>
> A vote can't be on a GitHub tag (as that could change) it needs to be on an artefact as the contents of LICENSE and NOTICE depend on what is in that bundle.
>
> > I don't see any requirement for that in the policy, is this somehow a
> > requirement ?
>
> Yes it is a requirement to have a signed artefact. See https://www.apache.org/legal/release-policy.html#what-must-every-release-contain for details.
>
> > It is our policy to never clutter these files with license statements
>
> That may be the case but it is not ASF policy, please see https://www.apache.org/legal/src-headers.html. Note it mentions what files need ASF headers and the limited exceptions.
>
> > It is my understanding that such derivative works must be listed in the
> > NOTICE file, which `doc/bst2html.py` is certainly mentioned.
>
> This is not correct only limited things belong in a NOTICE file, all license information goes in the LICENSE file. Please see https://infra.apache.org/licensing-howto.html. Anything included that is MIT or BSD licensed needs to be mentioned in LICENSE not NOTICE.
>
> > The tarballs are extremely lightweight are are only included as data to
> > run tests against (they are essentially hello world programs, or just
> > tarballs which contain data that tests expect).
>
> An ASF release cannot include compiled source code, not even compile hello world programs. They could be download or compiled as part of the testing process, if they are used for tests. See https://www.apache.org/legal/release-policy.html#source-packages
>
> > Although I wonder how important this is given the lower case "should"
> > (as opposed to "MUST")...
>
> This is a requirement only non ASF projects can use the other header. See https://www.apache.org/legal/src-headers.html#headers
>
> > and perhaps this is acceptable if added to the NOTICE file in some way
>
> Only relocated copyright notices i.e. those where you have had permission form the copyright owner to remove should be added to the NOTICE file. See https://www.apache.org/legal/src-headers.html#header-existingcopyright
>
> > Right, these are all very easy to account for, but I could use some
> > guidance as to how precisely to update the NOTICE file for this.
>
> In general you would not update the NOTICE file, you would update the LICENSE file. If the 3rd party code is ALv2 and has a NOTICE file then some additions to the NOTICE file may be required. See https://infra.apache.org/licensing-howto.html#alv2-dep
>
> > It would strike me as very odd to modify the LICENSE file
>
> The LICNSE file needs to contain all of the license of bundles software in the release artefact. See https://infra.apache.org/licensing-howto.html#permissive-deps
>
> Kind Regards,
> Justin
>
Re: Proposal for 2.0 stable release
Posted by Justin Mclean <jm...@apache.org>.
Hi,
Perhaps I can help.
> I'm reading that published release artifacts MUST be signed, and that
> eligible voters in the voting stage MAY provide a signature.
The release candidate needs to be signed so that someone reviewing the release can check that it contains what it should and will be the same as the released software.
> FWIW, all of our release tags (internal or external) are signed tags,
> and in any case I can surely provide a signature of the tarball(s) in
> the next candidate proposal.
A vote can't be on a GitHub tag (as that could change) it needs to be on an artefact as the contents of LICENSE and NOTICE depend on what is in that bundle.
> I don't see any requirement for that in the policy, is this somehow a
> requirement ?
Yes it is a requirement to have a signed artefact. See https://www.apache.org/legal/release-policy.html#what-must-every-release-contain for details.
> It is our policy to never clutter these files with license statements
That may be the case but it is not ASF policy, please see https://www.apache.org/legal/src-headers.html. Note it mentions what files need ASF headers and the limited exceptions.
> It is my understanding that such derivative works must be listed in the
> NOTICE file, which `doc/bst2html.py` is certainly mentioned.
This is not correct only limited things belong in a NOTICE file, all license information goes in the LICENSE file. Please see https://infra.apache.org/licensing-howto.html. Anything included that is MIT or BSD licensed needs to be mentioned in LICENSE not NOTICE.
> The tarballs are extremely lightweight are are only included as data to
> run tests against (they are essentially hello world programs, or just
> tarballs which contain data that tests expect).
An ASF release cannot include compiled source code, not even compile hello world programs. They could be download or compiled as part of the testing process, if they are used for tests. See https://www.apache.org/legal/release-policy.html#source-packages
> Although I wonder how important this is given the lower case "should"
> (as opposed to "MUST")...
This is a requirement only non ASF projects can use the other header. See https://www.apache.org/legal/src-headers.html#headers
> and perhaps this is acceptable if added to the NOTICE file in some way
Only relocated copyright notices i.e. those where you have had permission form the copyright owner to remove should be added to the NOTICE file. See https://www.apache.org/legal/src-headers.html#header-existingcopyright
> Right, these are all very easy to account for, but I could use some
> guidance as to how precisely to update the NOTICE file for this.
In general you would not update the NOTICE file, you would update the LICENSE file. If the 3rd party code is ALv2 and has a NOTICE file then some additions to the NOTICE file may be required. See https://infra.apache.org/licensing-howto.html#alv2-dep
> It would strike me as very odd to modify the LICENSE file
The LICNSE file needs to contain all of the license of bundles software in the release artefact. See https://infra.apache.org/licensing-howto.html#permissive-deps
Kind Regards,
Justin
Re: Proposal for 2.0 stable release
Posted by Tristan Van Berkom <tr...@codethink.co.uk>.
Hi again Christofer,
I'm afraid I replied too soon, so let me get to the details which you
had included in postscript (which I failed to notice :)).
And thankyou very much for the review !!!
[...]
>
> [FAILED] Download all staged artifacts under the url specified in the
> release vote email.
This confuses me, I am able to obtain them right now with wget:
wget https://files.pythonhosted.org/packages/3a/cc/c5ae68441f8ce2e2cb056b291e7d20181a18d8545e2993161f68d0f2a07c/BuildStream-1.95.3.dev0.tar.gz
> No signed artifacts, downloaded zip package from GitHub, no
> signatures or hashes
Ok I see there is a desire for a gpg signature, it is not entirely
clear that this is required from the policy at the proposal stage:
"All supplied packages MUST be cryptographically signed by the
Release Manager with a detached signature. Folks who vote +1 for
release MAY offer their own cryptographic signature to be
concatenated with the detached signature file (at the Release
Manager's discretion) prior to release."
I'm reading that published release artifacts MUST be signed, and that
eligible voters in the voting stage MAY provide a signature.
FWIW, all of our release tags (internal or external) are signed tags,
and in any case I can surely provide a signature of the tarball(s) in
the next candidate proposal.
> [FAILED] Verify the signature is correct.
> No signature
Right.
> [FAILED] Check if the signature references an Apache email address.
> No signature
I don't see any requirement for that in the policy, is this somehow a
requirement ?
> [FAILED] Verify the SHA512 hashes.
> No hashes
I did provide the sha256 hashes which appear correct, again I'm not
seeing anything about this in the policy.
> [OK] Unzip the archive.
> [OK] Verify the existence of LICENSE, NOTICE files in the extracted
> source bundle.
> [MINOR] Verify the content of LICENSE, NOTICE files in the extracted
> source bundle.
> Notice references 2021 and not 2022
> [FAILED] [RM] Run RAT externally to ensure there are no surprises.
> MANY files without Apache headers at all (Searching for
> http://www.apache.org/licenses/LICENSE-2.0 in the doc folder only
> brought one result at all, even in the tests directory there are
> Apache headers only on a few files)
There are configuration YAML files which related to default
configuration for plugins, for instance:
https://github.com/apache/buildstream-plugins/blob/master/src/buildstream_plugins/elements/autotools.yaml
It is our policy to never clutter these files with license statements,
as these are litterally used in place to produce user facing
documentation:
https://apache.github.io/buildstream-plugins/elements/autotools.html
It would detract readability of our user facing documentation to
clutter these configuration files with license headings, and it would
be much worse to duplicate the configuration data in the docs (as we
would no longer have the guarantee that the docs tell the absolute
truth).
> The list of non-approved license headers is 2078 lines/files long
> There are binary files in there: While I would call the ODG files
> sort of ok (OpenDocument Graphic File), the test contain archives
> which we generally don't like to see
> doc/bst2html.py is an MIT licensed file not mentioned in the LICENSE
> file
As per section 4 (Redistribution) of the license:
https://www.apache.org/licenses/LICENSE-2.0
It is my understanding that such derivative works must be listed in the
NOTICE file, which `doc/bst2html.py` is certainly mentioned.
As is mentioned the copied/derived work at
`src/buildstream/_frontend/complete.py`
The odg files are of course so that we never include rendered
graphics/diagrams in our documentation without revisioning the sources
used to generate these graphics directly adjacent.
The tarballs are extremely lightweight are are only included as data to
run tests against (they are essentially hello world programs, or just
tarballs which contain data that tests expect).
Is there anything concrete we need to do here ?
> The used Apache headers in generally all files are non-standard
> headers, which contain Copyright information to “Copyright (C) 2018
> Codethink Limited”) See here to how they should look like:
> https://www.apache.org/legal/src-headers.html
It would seem that the following had escaped us:
https://www.apache.org/legal/src-headers.html#headers
Specifically:
"note that there should be no copyright notice in the header."
Although I wonder how important this is given the lower case "should"
(as opposed to "MUST")... and perhaps this is acceptable if added to
the NOTICE file in some way (as seems to be indicated by the
following):
> [FAILED] Search for Copyright references, and if they are in headers,
> make sure these files containing them are mentioned in the LICENSE
> file.
> There’s code with Copyright headers for (All of these in various
> flavors), none of which are mentioned anywhere (NOTICE, LICENSE):
> - Copyright (C) 2019 Bloomberg Finance L.P.
> - Copyright (C) 2017 Codethink Limited
> - Copyright (c) 2014 by Armin Ronacher.
> - Copyright 2020 The Bazel Authors.
> - Copyright (c) 2015, Google Inc.
> - Copyright 2018 Google LLC
>
Right, these are all very easy to account for, but I could use some
guidance as to how precisely to update the NOTICE file for this.
It would strike me as very odd to modify the LICENSE file, as I think
anyone would expect the LICENSE file to contain the unmodified text
from: https://www.apache.org/licenses/LICENSE-2.0.txt
Best Regards,
-Tristan
Re: Proposal for 2.0 stable release
Posted by Christofer Dutz <cd...@apache.org>.
Hi,
And as I took the liberty of reviewing the 1.6.8 release according to the ASF rules, this would have been my response (Please use it as you like)
It should point out things that should be addressed for a first Apache release.
Things I usually don't check in my reviews as I never actually had to check it:
- Apache releases should be available from Apache servers https://www.apache.org/dyn/closer.lua or https://archive.apache.org
Hope this helps with the first release.
Chris
-------
-1
Chris
[FAILED] Download all staged artifacts under the url specified in the release vote email.
No signed artifacts, downloaded zip package from GitHub, no signatures or hashes
[FAILED] Verify the signature is correct.
No signature
[FAILED] Check if the signature references an Apache email address.
No signature
[FAILED] Verify the SHA512 hashes.
No hashes
[OK] Unzip the archive.
[OK] Verify the existence of LICENSE, NOTICE files in the extracted source bundle.
[MINOR] Verify the content of LICENSE, NOTICE files in the extracted source bundle.
Notice references 2021 and not 2022
[FAILED] [RM] Run RAT externally to ensure there are no surprises.
MANY files without Apache headers at all (Searching for http://www.apache.org/licenses/LICENSE-2.0 in the doc folder only brought one result at all, even in the tests directory there are Apache headers only on a few files)
The list of non-approved license headers is 2078 lines/files long
There are binary files in there: While I would call the ODG files sort of ok (OpenDocument Graphic File), the test contain archives which we generally don't like to see
doc/bst2html.py is an MIT licensed file not mentioned in the LICENSE file
The used Apache headers in generally all files are non-standard headers, which contain Copyright information to “Copyright (C) 2018 Codethink Limited”) See here to how they should look like: https://www.apache.org/legal/src-headers.html
[FAILED] Search for Copyright references, and if they are in headers, make sure these files containing them are mentioned in the LICENSE file.
There’s code with Copyright headers for (All of these in various flavors), none of which are mentioned anywhere (NOTICE, LICENSE):
- Copyright (C) 2019 Bloomberg Finance L.P.
- Copyright (C) 2017 Codethink Limited
- Copyright (c) 2014 by Armin Ronacher.
- Copyright 2020 The Bazel Authors.
- Copyright (c) 2015, Google Inc.
- Copyright 2018 Google LLC
On 2022/10/17 23:46:23 Daniel Gruno wrote:
> Hi Tristan,
>
> As Apache BuildStream is now a TLP, please ensure that all future releases agree with the overall release policy, as set out on https://www.apache.org/legal/release-policy.html (especially the MUST/MUST-NOTs). The document is quite exhaustive, and should cover all the various gotchas.
>
> With regards,
> Daniel.
>
> On 2022/10/12 14:51:58 Tristan Van Berkom wrote:
> > Dear BuildStream PMC members,
> >
> > I have now released the 1.95.3 release candidate releases for both the
> > core BuildStream and BuildStream plugins repositories.
> >
> > I don't know about future releases, but for 2.0 we will definitely be
> > releasing the main and plugin repositories together, so it makes sense
> > to also vote on both releases simultaneously.
> >
> > Please take some time (but not too much) to personally assess your
> > confidence in the 1.95.3 releases.
> >
> > To cast your vote, please reply with either a "+1" or a "-1".
> >
> > This proposal counts as my +1, two additional +1s will count as our
> > official consensus to make the 2.0 release, provided that the +1s
> > outnumber any -1s.
> >
> > For additional clarity, below are the specific assets on which we are
> > voting.
> >
> >
> > BuildStream 1.95.3
> > ------------------
> > https://files.pythonhosted.org/packages/3a/cc/c5ae68441f8ce2e2cb056b291e7d20181a18d8545e2993161f68d0f2a07c/BuildStream-1.95.3.dev0.tar.gz
> > sha256sum: 4ce6b473e6d6738de30409adb4cd717165ba3ef12a1838fd7a919f9762327859
> >
> >
> > BuildStream plugins 1.95.3
> > --------------------------
> > https://files.pythonhosted.org/packages/93/66/5a583b4b6392e1dca6b448647e1bc99b77f4f1ba3bb5a6185810d2164475/buildstream-plugins-1.95.3.tar.gz
> > sha256sum: e0367ed9ffdb8c3fd8b4811b6d782fa024ea72b41507c60a250c2093880eed90
> >
> >
> > Cheers,
> > -Tristan
> >
> >
> >
>
Re: Proposal for 2.0 stable release
Posted by Daniel Gruno <hu...@apache.org>.
Hi Tristan,
As Apache BuildStream is now a TLP, please ensure that all future releases agree with the overall release policy, as set out on https://www.apache.org/legal/release-policy.html (especially the MUST/MUST-NOTs). The document is quite exhaustive, and should cover all the various gotchas.
With regards,
Daniel.
On 2022/10/12 14:51:58 Tristan Van Berkom wrote:
> Dear BuildStream PMC members,
>
> I have now released the 1.95.3 release candidate releases for both the
> core BuildStream and BuildStream plugins repositories.
>
> I don't know about future releases, but for 2.0 we will definitely be
> releasing the main and plugin repositories together, so it makes sense
> to also vote on both releases simultaneously.
>
> Please take some time (but not too much) to personally assess your
> confidence in the 1.95.3 releases.
>
> To cast your vote, please reply with either a "+1" or a "-1".
>
> This proposal counts as my +1, two additional +1s will count as our
> official consensus to make the 2.0 release, provided that the +1s
> outnumber any -1s.
>
> For additional clarity, below are the specific assets on which we are
> voting.
>
>
> BuildStream 1.95.3
> ------------------
> https://files.pythonhosted.org/packages/3a/cc/c5ae68441f8ce2e2cb056b291e7d20181a18d8545e2993161f68d0f2a07c/BuildStream-1.95.3.dev0.tar.gz
> sha256sum: 4ce6b473e6d6738de30409adb4cd717165ba3ef12a1838fd7a919f9762327859
>
>
> BuildStream plugins 1.95.3
> --------------------------
> https://files.pythonhosted.org/packages/93/66/5a583b4b6392e1dca6b448647e1bc99b77f4f1ba3bb5a6185810d2164475/buildstream-plugins-1.95.3.tar.gz
> sha256sum: e0367ed9ffdb8c3fd8b4811b6d782fa024ea72b41507c60a250c2093880eed90
>
>
> Cheers,
> -Tristan
>
>
>