On Thu, Dec 13, 2018 at 01:47:30PM -0500, Josh Boyer wrote:
I cannot tell from the writeup below if it is documenting existing
practice, describing an ideal end state to be worked towards, or
somewhere in between. I read this less as a guiding policy and more
as an idea. I realize these topics are very difficult to draft
properly, particularly in a consumable format without the context of a
3 day meeting behind them.
This is an ideal we'd like the project to work towards, but it's also a path
that we're already on. There's some more context in a meeting report we're
getting ready to post; hopefully some of that will help.
Can we approach the topic a different way? Perhaps by saying what
you
believe needs to materially *change* to make this a reality?
1. We want "Fedora" to be the Project. For things Fedora makes, describe
them as "Fedora Thingname", like "Fedora IoT" or "the Fedora
RPM Package
Collection". I've been saying this for a while, but I want to make it
official. (Just as "Red Hat" isn't RHEL.)
2. We're going to set up a (hosted) Taiga instance. Anyone in Fedora will be
able to create a project there, and *every team in Fedora should*.
This will create a directory listing which will supplant
https://fedoraproject.org/wiki/Subprojects
and have three significant advantages:
1. Available all in one place
2. Searchable in a reasonable, non-wiki way
3. Not a wiki: inherently self-updating and sortable by activity
This is the minimum required to be a Fedora Team. A Team with no formal
membership process other than signing up and no formal structure is a
SIG. Other Teams may have more formalized membership, a charter with
rules for voting, regular meetings, regular reports to FESCo or
Mindshare, etc. (We decided against formalizing rules for words like
"Working Group" or "Subproject" and instead agreed that any Team
more
formal than a SIG can use those labels if they like.)
More on Taiga and this directory-service idea to come soon.
3. Teams providing services should formalize a menu of offerings. They
should describe the criteria by which those offerings are... offered.
I think the Council should provide some standard ideas for reasonable
criteria. These could include team structure and activity level, user
base, a link to current Fedora Objective, etc.
4. We need a way for Teams to release artifacts in a self-service way. The
Astronomy spin (to pick a random example) should not need to wait for
release engineering to make a release. In fact, they might choose to make
new releases around the cadence of their most important included
software. At the same time, since the Team can do it themselves, Release
Engineering might also not be on the hook for building artifacts for
spins with a niche audience or that don't meet some other criteria.
5. We need to allow for non-RPM building blocks somehow. I mean, not in a
technical way but in a *rules* way. We need to allow for RPMs built in
non-traditional ways (the source git idea). No solution is forced to
consume these, but we shouldn't block someone from providing them,
either. For example, Silverblue may want to provide some Flatpaks that
are built (in an open and transparent from-source way) straight to
Flatpak rather than going through RPM. Or AI/ML may want to generate and
ship container images with python wheels built specially.
(
https://github.com/thoth-station/tensorflow-build-s2i)
6. We need to relax policies on what Solutions are allowed to do. (We also
want to drop the Spins/Labs naming thing — it's confusing to people even
within the project. Note that Solutions is *also* not a great name. Feel
free to suggest!) Solution-makers should know their audiences best and
should be able to make more technical choices — the things currently
known as Spins should be able to offer different defaults and presets,
even including enabling different module streams by default. Solutions
should not require Spin SIG (or FESCo) approval on technical merit or
perceived feasibility.
There are probably more, but these are the half-dozen that come to mind
right away.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader