Plan for tomorrows (20080910) FESCO meeting

[Jeff Spaleta]

2008/9/10 Toshio Kuratomi <a.badger at gmail.com>:
> I think that some discussion of this is warranted, though.  It would be
> desirable to have a program that can run on Linux and generate Windows
> installers, for instance, but do we want to force our developers to do
> the work of adapting a Windows program like NSIS installer to run on
> Linux natively?

You could as a compromise include a clause to have FESCo rule on
exceptions to this on a case by case basis.  Though to do that, I
think it would be best to narrowly defined what the purpose of the
exceptions must serve... development aids... so that FESCo is only
asked to make narrow exception judgements. If the exceptions criteria
are more broadly defined as to allow end user applications  you'll
have a harder time down the road applying a consistent exceptions
policy without getting wrapped up in debates over Fedora's purpose.
I'd rather front load as much of the policy pain around these payloads
with explicit policies now..then have reactionary policies on down the
line.

> When dep solving or downloading filelists.xml for resolving a filename
> dep, you will end up including MingW stuff unnecessarily which slows
> things down.  But I don't know that that is sufficient reason to disable
> the repo by default.

As long as individual Spins are explicitly told to they are allowed to
disable or enable and that we are not requiring them to keep it in the
default state.  I fully expect the Developer Spin to enable it. I
fully expect the Desktop Spin to disable it.

The default state only impacts the traditional installer scenario, and
ultimately releng has the final decision as to whether they want this
enabled or disabled the mingw repo by default.  The suggested default
has the least impact on releng. FESCo is certainly free to invert that
suggestion so that the new repo is enabled by default.

-jef