Proposal to reduce anti-bundling requirements

[Bill Nottingham]

Stephen Gallagher (sgallagh at redhat.com) said: 
> Sorry, I was unclear. I do agree that once upon a time, this was
> absolutely effective. I probably should have said something more along
> the lines of what you did below; that the battlefield has changed and
> our former tactics are no longer sufficient.

(Aside: using war metaphors implicitly frames the conversation in a way
that isn't great for mutual understanding.)

It's definitely true, though - the landscape has changed and our policies
likely should change with it.  When the policies were created, all software
was complied from source, there wasn't much effort done for providing builds
of software from an upstream location, and the goal of having All The
Softwares in one place under a Red Hat Linux/Powertools/Fedora.us/Fedora tent
made sense in terms of providing what users need. But that's *not the case*
any more, and these policies don't make as much sense.

1) There is an implied goal of "package all the things". Our policies work
against that.

I'd hope this is self-explanatory, but in case it's not: we have a
cumbersome process for new package review, strict requirements on bundling,
versioning, etc., and a long process for sponsorship. If we really intend to
package all the things, we need to streamline the process and make it
easier.

2) Our policies *actively work against upstream goals*

https://gregdekspeaks.wordpress.com/2012/01/06/why-the-fedora-isv-sig-never-caught-fire/

(Yes, 2012. Nothing has changed here, other than 'even more so'.)

Upstream wants their complex software tested on a stable set of components
for replicability and reliability.  We don't provide that (we rev libraries
very fast, and still have arguably 'too much' accidental breakage), and we make it
*worse* by forced unbundling (by making their software use a different set
of dependencies).

3) Does "package all the things" really make sense, anyway?

What is the gain from 'conform Chromium to our package regulations' gain us? 
A few people who won't just install Chrome for F/OSS reasons?  If that's the
goal, we should be clear that that's the tiny set of users we're targeting. 
Maybe it makes sense if we're moving to Chromium as our main deployed
browser ala the Endless folks.  But if we're not, banging Chromium into our
guidelines in a way that Google themselves doesn't particularly care about
or support doesn't gain us much.

Similarly, if I'm developing some piece of software that embeds/uses
PostgreSQL, I'm likely targeting multiple distributions, potentially
including Fedora, CentOS, RHEL, Ubuntu, and more. Even if Postgres is a core
well maintained part of Fedora, I'm not going to care about that version.
I'm going to pick a constant version and pull it from something like
software collections (or, you know, upstream postgresql.org.)

And this doesn't even dig into the web develoment world (woo bundled
javascript, or even vendored python), where the *only* reasonable solution
is ship-your-own-vendored-stuff-with-your-app.

4) Combine 2+3: The world has moved beyond the distro as the distribution mechanism

Upstreams want to get their stuff out and make it available. They want to
control their distribution mechanism and supported platform list in a way
they can support, and that leads to tools like FPM that exist for a very
real reason.

Similarly, large ecosystems exist for language infrastructure - python, JS,
ruby, and more. If there's a compelling case for "package the entirety of
pip/rubygems/npm, including all versions, in the distro".... I haven't heard
it. Just use the upstream sources, and build tools to work with that. That's
what they are there for.

And that doesn't even mention containers, which is where everything is
moving - small immutable 'apps' separate from their data.  Fedora's not
going to run a verified container registry (at least, I HOPE NOT), so as
people move their apps to containers, again, our policies are irrelevant. 
(Plus, those containers are very likely to be based on something CentOS-ish
anyways, see #2 above.)

...

To allow or not allow bundling is the small side point here - the questions
should be more of "Are we a distribution of packages?  Are we an OS?  Where
do we see the distribution/OS fit in how software is consumed and provided?
Is that different for a Workstation vs an Atomic host?" Answer those big
questions, and the questions on what to do along Ring0->RingN, what bundling
to allow, etc. should fall out.

Bill