Hi, I just want to make sure we take our move to the ASF into account. So far I've been thinking that we are moving the core buildstream repository. And maybe a set of "core" plugins, but most of the other repositories are probably worth retiring/moving out. I don't think that adding what is essentially a project that could stand on its own into this namespace is necessarily the way to go.
Thoughts? Cheers, Sander On Fri, Sep 11, 2020 at 4:09 PM Benjamin Schubert <[email protected]> wrote: > Hey everyone, > > That seems like a good idea to me. > > I just have a meta question about such moves: > > What is the expectations we have for a project in order to move to the > BuildStream namespace? Who is responsible for maintaining it, making > releases where relevant, etc? > > Thanks! > > Ben > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Monday, 7 September 2020 09:32, Tristan Van Berkom < > [email protected]> wrote: > > > Hi Douglas, > > > > Thanks for bringing it to the list. > > > > For the readership, for avoidance of doubt: This particular license > > checker script is not the "whole story" around license related > > assertions and policy solutions for BuildStream projects, which has > > been under discussion here: > > > > > https://lists.apache.org/thread.html/re806060db181d176089108325d9c8564546f5e686eb96198ea9be458%40 > <dev.buildstream.apache.org> > > > > As Douglas points out, this script in particular is basically a handy > > script which you can use for any BuildStream project to harvest license > > scanning results and view reports of such. > > > > On Fri, 2020-09-04 at 12:51 +0100, Douglas Winship wrote: > > > > > Hi everyone. > > > For a couple of weeks, we've been working on a Buildstream license > > > checker script. We're hoping that it can become a useful tool for the > > > BuildStream community, and we'd like to bring it under the BuildStream > > > umbrella by making it a project in the BuildStream GitLab group. > > > The tool is a python script that interacts with a BuildStream project > by > > > invoking BuildStream commands like 'bst show' and 'bst workspace open' > > > (using subprocess.call). The script checks out the source code of > > > BuildStream elements into temporary folders, and then uses a separate > > > piece of software called licensecheck to scan the files for license > > > information. > > > The final output is a list of licensecheck output files (one for each > > > element), plus human readable and machine readable summary files (html > > > and json, respectively). We're currently testing the tool by running it > > > in CI on a Freedesktop SDK branch. Sample outputs can be seen in the CI > > > job artifacts. > > > We'd appreciate feedback on the script itself, and on the idea of > making > > > it part of the BuildStream group. > > > > Normally we would add standalone python scripts like this to the > > contrib/ directory, like `bst-here` and others: > > > > https://gitlab.com/BuildStream/buildstream/tree/master/contrib > > > > However, I think that given the structure of your gitlab repo, it makes > > more sense to add this as a separate repo in the BuildStream group. > > > > Any other thoughts on this ? > > > > Cheers, > > -Tristan > > >
