|
 |
09118c |
Attendees:
|
|
|
09118c |
Karanbir Singh
|
|
|
09118c |
Jim Perrin
|
|
|
09118c |
Fabian Arrotin
|
|
|
09118c |
Johnny Hughes
|
|
|
09118c |
Ralph Angenendt
|
|
|
09118c |
Karsten Wade
|
|
|
09118c |
|
|
|
09118c |
Actions:
|
|
|
09118c |
Add a license field for every container entry
|
|
|
09118c |
Develop list of all licenses in the distro + per repo
|
|
|
09118c |
Add requirements for license field into the SIG guide
|
|
|
09118c |
Add verification check
|
|
|
09118c |
Messaging for unified git
|
|
|
09118c |
Write up proposal & submit to Board for discussion / approval
|
|
|
09118c |
|
|
|
09118c |
|
|
|
09118c |
Notes:
|
|
|
09118c |
Registry.centos.org containers
|
|
|
09118c |
Who is vetting that things match the correct rules?
|
|
|
09118c |
Akin to SIGs -- they can go succeed but following the guidelines
|
|
|
09118c |
Need guidelines for this
|
|
|
09118c |
Containers may be more visible than other domains
|
|
|
09118c |
Licensing guidelines are already in https://wiki.centos.org/SpecialInterestGroup
|
|
|
09118c |
What is our response?
|
|
|
09118c |
Containers are acting separately from what SIGs do?
|
|
|
09118c |
Operate within Atomic SIG
|
|
|
09118c |
Who is responsible for content going into registry?
|
|
|
09118c |
BamaChrn Kundu & Container Eng team
|
|
|
09118c |
Action: Need a ‘License:’ field for every container entry
|
|
|
09118c |
Action: Make sure it is in the SIG guide & referenced from that SIG
|
|
|
09118c |
What do we put in the license field?
|
|
|
09118c |
License field should contain the license for the app that is the ‘purpose’ of the container
|
|
|
09118c |
All licenses need to be included in the container viewable when examining the container
|
|
|
09118c |
Make it clear to the SIGs what we are happy to host/not host
|
|
|
09118c |
Issue of how we build containers
|
|
|
09118c |
LIfecycle terms
|
|
|
09118c |
OK to just consume content
|
|
|
09118c |
Can take built binaries …
|
|
|
09118c |
Requiring restriction to come from RPMs would be a very high barrier for the upstreams we are working from
|
|
|
09118c |
Licenses we approve of …
|
|
|
09118c |
Verification check post-build?
|
|
|
09118c |
If we’re not checking / don’t have a way to check, we’re responsible.
|
|
|
09118c |
Unified git (NDA topic)
|
|
|
09118c |
Discussed at FOSDEM
|
|
|
09118c |
Buildroot for RHEL8 likely larger than shipped OS
|
|
|
09118c |
All source coming into CentOS
|
|
|
09118c |
To make this work with need a unified git with Fedora
|
|
|
09118c |
Result
|
|
|
09118c |
Git.centos.org maintained by us, pulls from common place as git.fedoraproject.org
|
|
|
09118c |
Effects
|
|
|
09118c |
No appreciable negative effects?
|
|
|
09118c |
Positive for certain type of maintainers
|
|
|
09118c |
Makes our future lives easier as stuff is changing anyway
|
|
|
09118c |
Modified packages
|
|
|
09118c |
How is this going to work if CentOS & Fedora have a common upstream git repo -- where do our changes go?
|
|
|
09118c |
Different branches - ‘f’ v ‘c’, so each group/hat worn pushes changes to their branches
|
|
|
09118c |
Some packagers may wear both hats
|
|
|
09118c |
How are the CentOS changes retained?
|
|
|
09118c |
The official branches ‘c7’ are for debranding only -- workflow stays in place.
|
|
|
09118c |
Johnny’s changes go through as they do currently
|
|
|
09118c |
We need to be better updating patches in alt-src
|
|
|
09118c |
E.g. c7-sig-altarch would be protected for project & SIG members via authentication, so no one from e.g. Fedora could step on something.
|
|
|
09118c |
Ideally this is a minimal changes to current workflow
|
|
|
09118c |
|
|
|
09118c |
|
|
|
09118c |
|
|
|
09118c |
|
|
|
09118c |
|