Fedora Board Recap 2008-JUL-15

[Jeff Spaleta]

On Thu, Jul 17, 2008 at 8:21 AM, John Poelstra <poelstra at redhat.com> wrote:
> == Mingw ==
I'm going to editorialize a little and reorder the bullets in doing so.

> * Board supports such an effort as long as it is self contained and
> separated from the main package respository

> ** Leave technical details and implementation to FESCo

>From a broad Project policy perspective we think that cross-compiling
is a new and different enough concept to separated out from the main
repository offering as a new subproject endeavor.  How exactly that is
done, is something we want FESCo to take up.  The Board is
deliberately avoiding making specific implementation choices, but we
did talk through enough of the possibilities so I was confident that
this can be implemented without asking anyone to do the impossible
with the available infrastructure.

> * Fedora should be in support of furthering open source software even if it
> doesn't run on Linux
> ** How far should this be taken?

FESCo also has a mandate to build policy associated with the packaging
of the cross-compiled libraries.  And while the Board didn't make the
mandate, I have a personal expectation that the packaging policies
concerning cross-compiled libraries and applications will put a strong
emphasis on requiring natively built versions of anything in the main
repository before it can be considered for cross-compiling in the new
mingw construct whatever it looks like.  We have a long term interest
in making sure we focus primarily on native libraries and
applications. And while we don't have to be exclusive about it.. we
must not undermine that focus as it relates to our primary project
objective.  My personal line is drawn thusly: If it can't be built
natively for our distribution, then it can't be built in our
buildsystem.  If FESCo decides differently, I as a Board member would
need to understand why.

> ** Special casing each new instance of cross compiling
> * Board expresses concern on potential future resource issues

We can look at what is before us with mingw both narrowly and quite broadly.
Looking quite narrowly, as to the specific purpose trying to be
achieved with the libvirt cross-compiling using the mingw toolset, I
don't think anyone has a problem with what is trying to be achieved.
Making libvirt available as a technology on Windows will most likely
make it easier for people to run Fedora and other linux distributions
in real world environments. And as such the Board is comfortable
allocating resources for that very narrow purpose.

But looking more broadly, its far less clear that a resource
allocation of existing project resources to enable a broad collection
of cross-compiled items makes sense from a resource allocation point
of view.  Compared to everything else we could be doing, and aren't
providing resources for.. including native secondary arch work going
on in the community right now...we aren't able to justify providing
all the hosting and cpu time to open up a general purpose mingw
cross-compiled repository.

The compromise here is to create the policy and process structure that
is generally applicable to mingw cross-compiled payloads and to
provide a small amount of space to start the subproject so that the
libvirt work can go forward while providing some headroom to grow
beyond libvirt based on contributor interest.  Since this will be an
explicitly constrained space, I fully expect the submission process to
this structure to be more demanding in response to enforced scarcity
of hosting resources.  The reality is, community members are going to
have to  bring external resources to the table to significantly extend
the reach of this beyond a skeleton development environment needed for
the libvirt development.

And looking even more broadly...the existence of a process which
supports mingw built payloads can not be used to justify any future
cross-compiling desires.  If another cross-compiler toolchain shows up
in Fedora.. it does not automatically mean we are going to follow what
we are doing with mingw and provide any resources what-so-ever to
accommodate new cross-compiled payloads.  Useful cross-compilers may
make it in to the main repository as a set of tools, or not, based on
existing packaging guidelines. But if anyone wants to use package
cross-compiled items as part of this project, we will need to have the
same sort of project impact discussion similar to what we are
currently having with mingw.

> # Ask SIG to fill out request for resources with Infrastructure

the mingw SIG is going to have to work with FESCo concerning the
implementation details on how to contain and separate the mingw
compiled packages into its own corner of our project space. And once
there is a plan in place infrastructure will need to allocate
resources informed by that plan.

> # Karsten to start a new thread on fedora-advisory-board concerning
> trademarks

I would encourage everyone to read over our objectives page in the
wiki again before joining Karsten's thread concerning trademark usage
which he'll be starting.

If FESCo members or mingw SIG members need clarification as to what is
being asked of them, do not hesitate to respond.

-jef