Re: [edk2-devel] RFC for Edk2-Library

["Michael D Kinney" <michael.d.kinney@intel.com>]

Hello,

It is difficult to tell if the repo name edk2-library
is for firmware or tools, so I recommend we work on a
name that clearly identifies that this repo is related
to tools.

For the pip dependencies, is the concern that a platform
that depends on these tools will not be buildable without
running a "pip install" command that pulls content from the
network?  We already have to pull content to get the sources
and potentially other dependent tools (NASM, iASL, openssl).

Can we limit the initial scope to tools that layer on top
of edk2, and a different future RFC would be required if 
there is a proposal for the edk2 repo to depend on another
repo?  If we accept this limited scope, are there still 
concerns about initially using squash commits for changes
to these tools.  Is there a way for GitHub to support both
squash commits for some PRs and preserve a patch series for
other PRs?
 
Thanks,

Mike

> -----Original Message-----
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io]
> On Behalf Of Laszlo Ersek
> Sent: Wednesday, May 8, 2019 2:56 AM
> To: devel@edk2.groups.io; sean.brogan@microsoft.com
> Subject: Re: [edk2-devel] RFC for Edk2-Library
> 
> On 05/07/19 23:35, Sean via Groups.Io wrote:
> > RFC  Edk2-Library creation
> >
> > Create a new tianocore owned repository to host a
> python library
> > package in support of UEFI development.  This package
> will allow easy
> > sharing of python library code to facilitate reuse.
> Inclusion of this
> > package and dependency management should be managed
> using Pip/Pypi. To
> > start this is a supplemental package and is not
> required to be used
> > for edk2 builds.
> 
> [1]
> 
> > Examples of content here
> >
> > * Edk2 file type parsing
> > * UEFI structure encode/decode in python
> > * Packaging tools (Capsules generation, signing, INF
> gen, Cat gen)
> > * TPM support code
> > * Potentially move content from
> basetools/source/python/common/*
> 
> [2]
> 
> > * No command line tools/interface
> >
> > Maintainers
> >
> > * Sean Brogan
> > * Bret Barkelew
> > * Placeholder for existing maintainer from the
> basetools
> >
> > License
> >
> > * BSD + Patent (edk2 aligned)
> >
> > Contribution process and issue tracking
> >
> > * Follow Github PR process for contributions and issue
> tracking
> > * Contributor forks repo in github
> > * Contributor creates branch for work
> > * Contributor updates release notes to indicate change
> (if necessary)
> > * Contributor submits PR to master branch of
> tianocore/Edk2-Library
> >   repo
> > * Review feedback is given in PR
> > * Python Tests are run on the repo (new contributions
> need unit tests)
> > * Python Style (flake8) must pass
> > * All review feedback must be completed, maintainers
> approved, and
> >   tests run successfully before PR is *squash merged*
> into master
> 
> The sentences
> 
> [1] "To start this is a supplemental package and is not
> required to be
>      used for edk2 builds."
> 
> [2] "Potentially move content from
> basetools/source/python/common/*"
> 
> foreshadow that such a code movement might happen down
> the road, and the
> external package could become a requirement for building
> edk2.
> 
> That step would mean the following:
> 
> (a) Edk2 would not remain buildable from a single
> command
> 
>     git clone --recurse-submodules
> 
>     Building edk2 would require GNU/Linux users to start
> tracking
>     packages with "pip", which is independent of any
> given distro's own
>     package management, and may cause conflicts if not
> used carefully:
> 
> 
> https://developer.fedoraproject.org/tech/languages/pytho
> n/pypi-installation.html
> 
>     This requirement on "pip" would only go away once
> the external
>     python dependencies were packaged for at least the
> larger GNU/Linux
>     distros.
> 
> (b) Edk2 users running into build problems related to
> the external
>     python dependencies would have to contribute through
> a github-only
>     workflow. That's not a deal-breaker per se -- if we
> want to
>     contribute to other edk2 dependencies, such as
> OpenSSL or nasm, we
>     also have to conform to their specific development
> models, clearly.
> 
>     However, "squash merge" is a catastrophically bad
> development model,
>     and I'd object to introducing a new edk2 build
> dependency that
>     followed that model.
> 
>     (There are other issues with the GitHub.com
> development workflow, as
>     discussed elsewhere, but "squash merge" takes the
> cake.)
> 
> Problem (a) would be solvable in the long term (through
> collaboration
> with distro maintainers, i.e. downstream packaging), but
> problem (b)
> would not be. Thus I'm fine with the proposal, in its
> current form, only
> if the new package is 100% an addition on top of edk2,
> even in the long
> term, and not in any part intended as a future
> replacement for current
> edk2 functionality.
> 
> Thanks,
> Laszlo
> 
>