Hi all,
Yesterday we finally got together to discuss BuildStream 2.0 again and
we made great strides towards putting this long overdue release on the
fast track.
The new milestone overview, which dictates what we expect to land before
our first candidate release, can be viewed here:
https://github.com/apache/buildstream/milestone/2
I've included the minutes below for reference.
Cheers,
-Tristan
Meeting minutes
===============
* Walk back over zealous plan to disallow writing in the sandbox
In our last meeting I had pushed for us to disallow plugins writing
to the sandbox using python code, as there have been some instances
of non-deterministic output as a result.
This turns out to be complicated and is dragging the release, so instead
just consider plugins who generate non-deterministic to be buggy and
need fixing.
VOTE: +1 unanimous
* Remove #1274 and #1275 from the blocker list
We had intended to use the remote asset cache to improve performance
of fetching and tracking when infrastructure allows for this.
Motion to not block on these features.
VOTE: +1 unanimous
NOTE: When implementing this after freezing the API, source plugins
will need to explicitly opt-in to participate in such
optimizations.
* Minimum time to market for plugin testing API
Discussion reached the following unanimous agreements:
- The 'buildstream.testing' API will be made private until it
can be deemed stable, as this need not block a 2.0 release.
- Some plugins which we intend to remove from BuildStream core
are required in order to preserve adequate test coverage of
the BuildStream core, in order to test the core API surfaces.
These plugins will be copied verbatim under the tests/ directory
before removing the plugins from BuildStream core, in order to
preserve test coverage.
NOTE: The ideal is still to produce minimal dummy plugins for testing
purposes, but for now there is no need to block on this.
* Plugin migration
Discussion reached the following unanimous agreements:
- Prominant plugins migrated outside of the BuildStream core for which we
intend to maintain, shall be migrated to a 'buildstream-plugins' repository
in apache github.
These shall be distributed on PyPI as a single package, even if the package
might not contain all plugins on platforms which lack support for
potentially
platform specific plugins.
- These plugins include:
Source plugins: zip, git, bzr, pip, docker, cargo, patch
Element plugins: cmake, meson, autotools, make, pip, distutils
NOTE: The distutils element plugin will be renamed 'setuptools'
NOTE: The 'patch' source plugin may be promoted back to the core in the
case that we find that we need to use 'patch' with 'tar' in order
to load external plugins via junctions, but for now this is not
expected.
- Adding core plugins in the future could potentially cause namespace issues.
To solve this, we shall ensure that core plugin names are shadowed by
explicitly loaded external plugins
ACTION: Sander to work on obtaining our new 'buildstream-plugins' repo
ACTION: Tristan to file an issue regarding plugin name shadowing and add
this to the BuildStream 2.0 milestone (blocker list)
* Review remaining blockers on the milestone
Discussion reached the following unanimous agreements:
- Remove #1327 from the blocker list.
This was a requirement for a proposal regarding composite plugins, which
is complex and most probably unneeded - in the worst case it may result
in a less than perfect API to create the composite plugin mechanism.
- Remove #1385 from the blocker list.
This is the policy about cache keys being stable indefinitely.
At this stage there are no action items remaining to make this a reality,
and we need follow our policy of not breaking cache key stability in the
core.
NOTE: External plugins can still potentially break cache keys, or they
can be written in such a was as to preserve cache keys. The new
'junction' plugin origin which allows strict plugin version pinning
helps the consumer to avoid consuming plugins which break cache keys.
- Remove #1296 from the blocker list.
This issue proposes a nice feature to attempt to automatically upgrade
your project to be BuildStream 2.0 ready when running `bst init`, while
this is a nice feature, there is no need to block a release on this.
* Relicensing effort
After a long and arduous process of contacting contributors which continue
to have code changes that exist in the master branch, we are finally ready
to merge #1464 and formally relicense BuildStream under the apache license.
VOTE: +1 unanimous
