Hi all,
Yesterday the team met to discuss the logistics of rolling out a
BuildStream 2.0 final release.
In attendance:
- Benjamin Schubert
- Chandan Singh
- Abderrahim Kitouni
- Jürg Billeter
- Sander Striker
- Tristan van Berkom
Below is a summary of topics we discussed and their outcomes.
Formalization of BuildStream as an Apache project
-------------------------------------------------
For a long time BuildStream has been considered a "petri culture"[0],
which was the path chosen for onboarding the project in Apache,
BuildStream will have to graduate this stage in order to eventually
roll out an official 2.0 release.
Some results of this conversation are:
* Clarification of the Release Policy[1].
We only need 3 "+1" votes from active members to make an official
release, and it must be a majority of all votes. This means that
PMC members (maintainers) which are inactive and abstain from a
vote do not count as a vote against the release.
* We can freely continue to make beta releases or 2.0 release
candidates without graduating as an official Apache project
or needing to follow the release policy.
* We are sufficiently satisfied that we will have graduated as
an official Apache project by the time we are prepared to vote
on an actual 2.0 release.
Passing criteria for a BuildStream 2.0 final release
----------------------------------------------------
When we initially released 1.0, we had a lot more developers and
engagement, weekly IRC team meetings where we would discuss the
remaining blockers, as such we had a high bar to pass where we wanted
something more polished.
We don't have the same level of engagement this time around and so the
bar must be set lower - so we set to task evaluating existing proposed
blockers on the 2.0 milestone[2], with the goal of deriving some
criteria for issues which should realistically block the release.
These are the criteria we came up with:
* Website material shall not block 2.0, so long as it is not
obviously contradictory to ASF guidelines.
* Bugs which have workarounds need not block the release.
* Issues which would potentially require an API break to fix must
block the release.
CLARIFICATION:
It has been our experience that in some cases BuildStream does
not function as intended, leading to downstream projects using
the API with incorrect expectations, and fixing these issues
later on caused these downstream projects to break.
Any issue of this class which we are aware of must block
the release.
EXAMPLE:
Issue with cross project include file variable resolution[3].
* Issues where we are unsure if a (new) feature works or not, are not
a blocker, but a possible later feature addition.
EXAMPLE:
Ability to include yaml fragments in junctions[4].
* If a feature is functional now but could be improved, it is not
a blocker.
EXAMPLE:
Poor error messaging when attempting to launch build shells
on elements which do not support such[5]
Filtering of the blocker list
-----------------------------
After analyzing some issues, we decided to walk through the list, and
we excluded the following issues from the milestone[2]:
- https://github.com/apache/buildstream/issues/1370
- https://github.com/apache/buildstream/issues/1001
- https://github.com/apache/buildstream/issues/979
- https://github.com/apache/buildstream/issues/528
- https://github.com/apache/buildstream/issues/522
- https://github.com/apache/buildstream/issues/517
- https://github.com/apache/buildstream/issues/505
- https://github.com/apache/buildstream-plugins/issues/18
Issue was moved to buildstream-plugins, and not considered
a blocker but rather a known limitation (should still be fixed
but is not a blocker).
- https://github.com/apache/buildstream/issues/1189
This issue can be removed from the blocker list so long as
BuildStream has taken measures to properly inform the user how
to obtain the correct version of buildbox binaries.
- https://github.com/apache/buildstream/issues/1263
This issue can be removed from the blocker list so long as
it is possible to fix without breaking cache key stability.
Cheers,
-Tristan
[0]: https://petri.apache.org/buildstream
[1]: https://www.apache.org/legal/release-policy.html
[2]: https://github.com/apache/buildstream/milestone/3
[3]: https://github.com/apache/buildstream/issues/1485
[4]: https://github.com/apache/buildstream/issues/1370
[5]: https://github.com/apache/buildstream/issues/1001
