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/04/25 08:44:28 UTC
Proposal for initial API stable Beta release
Hi,
All of the outstanding issues on the milestone[0] which came out of
our last meeting[1] have been take care of, including removing the last
plugins out of the buildstream repository and adding them to the new
buildstream-plugins[2] repository (which also includes the plugins we
agreed to add from other repositories such as bst-plugins-container and
bst-plugins-experimental).
As such, I propose that we declare the API to be stable, and make an
initial beta release of buildstream & buildstream-plugins to signify
this API stability cutoff.
After this, we still have some road to travel to assist the
freedesktop-sdk project to migrate[3] to BuildStream 2, which will be a
great help in assisting us to find and fix any remaining issue before
we can finally reach a formal BuildStream 2.0 release, for which we've
already created another milestone[4].
This email is a sanity check:
* Have we missed any critical issues which must be fixed and cannot
be fixed without breaking API ?
* Are there any reasons to delay declaring the API surfaces for
BuildStream (and buildstream-plugins) as stable ?
So long as there are no reasons to block this, I will be looking into
how the release process should work within our new home at Apache and
hopefully we can get passed this important milestone soon.
Cheers,
-Tristan
[0]: https://github.com/apache/buildstream/milestone/2
[1]: https://lists.apache.org/thread/d7fgbdnfx62b4v1mz8g8qq56ohm3kjmz
[2]: https://github.com/apache/buildstream-plugins
[3]: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1383
[4]: https://github.com/apache/buildstream/milestone/3
Re: Proposal for initial API stable Beta release
Posted by Tristan Van Berkom <tr...@codethink.co.uk>.
Hi again,
As you will have noticed here[0], after a long wait I've decided to go
ahead with releasing the beta, which signifies that BuildStream 2 is
now stable.
My rationale here is that the project can no longer be held hostage to
the wheels of bureaucracy and ambiguity of whether we can manage to
follow the guidelines to roll a proper official Apache release.
I think we should continue to iron out the process such that our
releases can be recognized as "official" in terms of proper Apache
process, in parallel, and in the meantime we should not be blocked from
functioning as a project until this is sorted.
Cheers,
-Tristan
[0]: https://lists.apache.org/thread/fm5sob2r93vrcgocg0k1lzz60kfoc63h
On Sun, 2022-05-22 at 17:07 +0900, Tristan Van Berkom wrote:
> Hi all,
>
> It's been a little while without much activity in this thread and I
> wanted to make sure the ball is still rolling here.
>
> I've reviewed in detail the policy statement here[0], and can see there
> may be some gaps we need to cover or understand better how we are going
> to go about officiating any release.
>
> In general from what I can understand, the process is fairly straight
> forward:
>
> o A release is proposed on this archived mailing list
> o Three team members (and at least a majority) must give their +1
> to approve the release
> o The approved release tarball is then cryptographically signed
> and uploaded to downloads.apache.org
>
> One of the obstacles I can see here, is in the "RELEASE APPROVAL"
> section it is stated:
>
> "individuals are REQUIRED to download all signed source code
> packages onto their own hardware, verify that they meet all
> requirements of ASF policy on releases as described below"
>
> This seems a bit dated to me, should we be creating tarballs with
> `python3 setup.py sdist` and signing them and uploading them to some
> location ?
>
> Perhaps in 2022, it should be sufficient to create a signed git tag for
> other core developers to checkout and run `tox` against on their own
> machines ?
>
> Further, I should note that voting on an EXACT version or tarball for a
> release does not make sense for us, as we will need to TAG the official
> release AFTER it is finally approved, and doing so will effectively
> alter the generated output of a release tarball due to the version
> number change.
>
> For right now, we really need to get an official "Beta" release out if
> only to signify that by now, the API is officially frozen and shall not
> be broken (while it *may* be extended in advance of a 2.0 final
> release).
>
> What do we need to do to make this happen ? Should I propose the
> current tip of the master branch
> (d796c4e079b3bb5c85e4c3adf87c86e3cfa4d76a) as the beta release ?
>
> Any thoughts and input on this would be greatly appreciated to help us
> get the ball rolling here.
>
> Cheers,
> -Tristan
>
> [0]: https://www.apache.org/legal/release-policy.html
>
>
> On Mon, 2022-04-25 at 17:44 +0900, Tristan Van Berkom wrote:
> > Hi,
> >
> > All of the outstanding issues on the milestone[0] which came out
> > of
> > our last meeting[1] have been take care of, including removing the
> > last
> > plugins out of the buildstream repository and adding them to the new
> > buildstream-plugins[2] repository (which also includes the plugins we
> > agreed to add from other repositories such as bst-plugins-container
> > and
> > bst-plugins-experimental).
> >
> > As such, I propose that we declare the API to be stable, and make an
> > initial beta release of buildstream & buildstream-plugins to signify
> > this API stability cutoff.
> >
> > After this, we still have some road to travel to assist the
> > freedesktop-sdk project to migrate[3] to BuildStream 2, which will be
> > a
> > great help in assisting us to find and fix any remaining issue before
> > we can finally reach a formal BuildStream 2.0 release, for which
> > we've
> > already created another milestone[4].
> >
> > This email is a sanity check:
> >
> > * Have we missed any critical issues which must be fixed and cannot
> > be fixed without breaking API ?
> >
> > * Are there any reasons to delay declaring the API surfaces for
> > BuildStream (and buildstream-plugins) as stable ?
> >
> > So long as there are no reasons to block this, I will be looking into
> > how the release process should work within our new home at Apache and
> > hopefully we can get passed this important milestone soon.
> >
> > Cheers,
> > -Tristan
> >
> > [0]: https://github.com/apache/buildstream/milestone/2
> > [1]: https://lists.apache.org/thread/d7fgbdnfx62b4v1mz8g8qq56ohm3kjmz
> > [2]: https://github.com/apache/buildstream-plugins
> > [3]: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1383
> > [4]: https://github.com/apache/buildstream/milestone/3
> >
> >
> >
Re: Proposal for initial API stable Beta release
Posted by Tristan Van Berkom <tr...@codethink.co.uk>.
Hi all,
It's been a little while without much activity in this thread and I
wanted to make sure the ball is still rolling here.
I've reviewed in detail the policy statement here[0], and can see there
may be some gaps we need to cover or understand better how we are going
to go about officiating any release.
In general from what I can understand, the process is fairly straight
forward:
o A release is proposed on this archived mailing list
o Three team members (and at least a majority) must give their +1
to approve the release
o The approved release tarball is then cryptographically signed
and uploaded to downloads.apache.org
One of the obstacles I can see here, is in the "RELEASE APPROVAL"
section it is stated:
"individuals are REQUIRED to download all signed source code
packages onto their own hardware, verify that they meet all
requirements of ASF policy on releases as described below"
This seems a bit dated to me, should we be creating tarballs with
`python3 setup.py sdist` and signing them and uploading them to some
location ?
Perhaps in 2022, it should be sufficient to create a signed git tag for
other core developers to checkout and run `tox` against on their own
machines ?
Further, I should note that voting on an EXACT version or tarball for a
release does not make sense for us, as we will need to TAG the official
release AFTER it is finally approved, and doing so will effectively
alter the generated output of a release tarball due to the version
number change.
For right now, we really need to get an official "Beta" release out if
only to signify that by now, the API is officially frozen and shall not
be broken (while it *may* be extended in advance of a 2.0 final
release).
What do we need to do to make this happen ? Should I propose the
current tip of the master branch
(d796c4e079b3bb5c85e4c3adf87c86e3cfa4d76a) as the beta release ?
Any thoughts and input on this would be greatly appreciated to help us
get the ball rolling here.
Cheers,
-Tristan
[0]: https://www.apache.org/legal/release-policy.html
On Mon, 2022-04-25 at 17:44 +0900, Tristan Van Berkom wrote:
> Hi,
>
> All of the outstanding issues on the milestone[0] which came out
> of
> our last meeting[1] have been take care of, including removing the
> last
> plugins out of the buildstream repository and adding them to the new
> buildstream-plugins[2] repository (which also includes the plugins we
> agreed to add from other repositories such as bst-plugins-container
> and
> bst-plugins-experimental).
>
> As such, I propose that we declare the API to be stable, and make an
> initial beta release of buildstream & buildstream-plugins to signify
> this API stability cutoff.
>
> After this, we still have some road to travel to assist the
> freedesktop-sdk project to migrate[3] to BuildStream 2, which will be
> a
> great help in assisting us to find and fix any remaining issue before
> we can finally reach a formal BuildStream 2.0 release, for which
> we've
> already created another milestone[4].
>
> This email is a sanity check:
>
> * Have we missed any critical issues which must be fixed and cannot
> be fixed without breaking API ?
>
> * Are there any reasons to delay declaring the API surfaces for
> BuildStream (and buildstream-plugins) as stable ?
>
> So long as there are no reasons to block this, I will be looking into
> how the release process should work within our new home at Apache and
> hopefully we can get passed this important milestone soon.
>
> Cheers,
> -Tristan
>
> [0]: https://github.com/apache/buildstream/milestone/2
> [1]: https://lists.apache.org/thread/d7fgbdnfx62b4v1mz8g8qq56ohm3kjmz
> [2]: https://github.com/apache/buildstream-plugins
> [3]: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1383
> [4]: https://github.com/apache/buildstream/milestone/3
>
>
>