Fedora Board Recap 2008-JUL-15

https://fedoraproject.org/wiki/Board/Meetings/2008-07-15

== Roll Call ==

Attendees: John Poelstra, Matt Domsch, Paul Frields, Jef Spaleta, Seth
Vidal, Harald Hoyer, Jesse Keating, Karsten Wade, Chris Tyler, Spot
Callaway, Bill Nottingham


== Mingw ==
* Cross compiling certain applications for Windows
* Board is considering from a perspective of overall affect on Fedora
Project

** Leave technical details and implementation to FESCo
* Fedora should be in support of furthering open source software even if
it doesn't run on Linux

** How far should this be taken?
** Special casing each new instance of cross compiling
* Board supports such an effort as long as it is self contained and
separated from the main package respository

* Board expresses concern on potential future resource issues
ACTIONS:
# Ask SIG to fill out request for resources with Infrastructure
# Karsten to start a new thread on fedora-advisory-board concerning
trademarks


== Release Stability ==
* Some board members are concerned that too many updates are being made
to our stable releases

ACTIONS:
* Board request more information from FESCo on the following:
*# Statistics from bodhi about the number updates and bugs fixed
*# Regression statistics from bugzilla
*# Is there a policy against updating shared library versions in stable
releases?



_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board

On Thu, Jul 17, 2008 at 8:21 AM, John Poelstra <poelstra@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

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board

On Thursday 17 July 2008, Jeff Spaleta wrote:
> On Thu, Jul 17, 2008 at 8:21 AM, John Poelstra <poelstra@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.
I would assume the only thing being considered for inclusion here is the
compiler tool chain to enable people to cross build apps for windows, im
assuming on ia64, i386 and x86_64 since thats where windows can run. I see it
no different to the current arm cross compiling toolkit. and of course if we
can only use binary blobs for part of it its not ever going to be acceptable
in fedora. are you proposing we create software builds for windows? if so
the resulting .exe files can live wherever we decide to put them. but they
obviously have no place in fedora repositories.

> > * 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.
you should have no expectations of an outcome unless you go through the board
and have them mandate something. you can share your opinion but it is to be
taken as nothing more. what you write above looks like a thinly veiled
threat. though your personal line is fedora policy. nothing can be built
that requires something outside of fedora (EPEL is an exception in that we
build upon other Fedora based distros) but its all fedora. I personally wish
you would cut down the noise that we have seen from you lately. all of the
above is just noise.

> > ** 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.
Huh,
All we should provide is the tools to enable people like libvirt build there
stuff themselves. but they should host the resulting binaries themselves. We
dont have release engineering to do windows binary releases. nor do we have
hosting space to host them. And i think it would be odd to say to a windows
user go over to this fedora place and get your binaries.

<snip noise>
> > # 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.
There should be no fedora trademark usage. the only windows tool i see that
we should provide and should have our trademark is the tool that lets you
install a fedora livecd to a usb key other than that each project to his own.

> If FESCo members or mingw SIG members need clarification as to what is
> being asked of them, do not hesitate to respond.
Id like clarification on what you think you are doing. to me its seems all you
are doing is making noise.

--
Dennis Gilmore

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board

On Thu, Jul 17, 2008 at 12:54 PM, Dennis Gilmore <dennis@ausil.us> wrote:
> I would assume the only thing being considered for inclusion here is the
> compiler tool chain to enable people to cross build apps for windows, im
> assuming on ia64, i386 and x86_64 since thats where windows can run. I see it
> no different to the current arm cross compiling toolkit. and of course if we
> can only use binary blobs for part of it its not ever going to be acceptable
> in fedora. are you proposing we create software builds for windows?

First, my understanding is that right now... everything so far
discussed has not involved any binary blobs. Mingw is a completely
open codebase that we can natively compile as a toolset in Fedora.
The issue that bubbled up to fab was not whether or not the tool
should be allowed in. The issue was whether we should be able to use
the tool to build dll payloads to be packaged up as a skeleton
development environment for people wanting to do open development over
windows.

You need to look over the previous mingw/libvirt -devel-list thread
and then the resulting fab thread that Axel started for discussion
context as to the original motivation to be able to cross-compile
enough libraries to ease libvirt client support on windows. My
personal summary of the discussions will be skewed towards what I
think are important policy questions. But the developers working on
the cross-compiling the libvirt and related libraries would be able to
speak more directly to their motivations.

> if so
> the resulting .exe files can live wherever we decide to put them. but they
> obviously have no place in fedora repositories.

That's sort of where we are now. It's okay to do, and we are pretty
sure its not impossible to do with our given infrastructure, the Board
has agreed that we can do it, but it should live outside the main
repository.

> you should have no expectations of an outcome unless you go through the board
> and have them mandate something.

What? I completely disagree with that. I am personally allowed to
have expectations, if my expectations are severely out of alignment
then I'm not on the same page and then I, personally, have a
communication gap that I need to work on.

> you can share your opinion but it is to be
> > taken as nothing more. what you write above looks like a thinly veiled
> threat.

It wasn't meant as a threat. If FESCo ends up coming up to a different
conclusion then I need to understand why, so that I can be more
effective as a Board member. If I'm not on the same page as FESCo's
consensus opinion with regard to this sort of issue.. then there's a
deep impendance mismatch with regard to interpreting project
objectives that I need to be aware of.

though your personal line is fedora policy. nothing can be built
> that requires something outside of fedora (EPEL is an exception in that we
> build upon other Fedora based distros) but its all fedora. I personally wish
> you would cut down the noise that we have seen from you lately. all of the
> above is just noise.

Yes. I have a personal character flaw to be overly verbose at times.
It helps to be reminded to attempt to be succinct. I will make a
renewed effort.

> Huh,
> All we should provide is the tools to enable people like libvirt build there
> stuff themselves. but they should host the resulting binaries themselves. We
> dont have release engineering to do windows binary releases. nor do we have
> hosting space to host them. And i think it would be odd to say to a windows
> user go over to this fedora place and get your binaries.

I cannot invalidate the resource concerns you bring up. I believe the
developers who are pushing the mingw use as a cross-compiler of
libvirt have attempted to highlight the value to Fedora in discussions
leading up to this Board meeting. In both the fab and -devel-list
threads. I doubt I would be better able to make an argument that
justifies the resource outlay better than they have.

>> If FESCo members or mingw SIG members need clarification as to what is
>> being asked of them, do not hesitate to respond.
> Id like clarification on what you think you are doing. to me its seems all you
> are doing is making noise.

I don't know how to respond to this in a way that would not be
considered noise. I have a tendency to be even more verbose, when I'm
asked to clarify. But if I'm already being overly verbose, isn't he
best course of action at that point to just cut my losses and be
silent? This riddle will keep my from sleeping this evening.

-jef

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board

On Thu, 17 Jul 2008, Jeff Spaleta wrote:

I don't know how to respond to this in a way that would not be
considered noise. I have a tendency to be even more verbose, when I'm
asked to clarify. But if I'm already being overly verbose, isn't he
best course of action at that point to just cut my losses and be
silent? This riddle will keep my from sleeping this evening.


[spevack@localhost ~]$ ./jef -vvv

(Attempting to inject humor, and not taking sides or offering opinions
or anything else. I love you both!)


--Max

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board

On Thu, 2008-07-17 at 13:26 -0800, Jeff Spaleta wrote:
> > you can share your opinion but it is to be
> > > taken as nothing more. what you write above looks like a thinly veiled
> > threat.
>
> It wasn't meant as a threat. If FESCo ends up coming up to a different
> conclusion then I need to understand why, so that I can be more
> effective as a Board member. If I'm not on the same page as FESCo's
> consensus opinion with regard to this sort of issue.. then there's a
> deep impendance mismatch with regard to interpreting project
> objectives that I need to be aware of.

This is how it's going to go down.

Board (you?): "FESCo, Go mandate policies on cross-compiling"

FESCo: "Ok. We need a packaging guideline. FPC, go make the packaging
guidelines for cross-compiling toolchains."

FPC: "Crap. Add that to the end of the queue."

<time passes>

FPC: "Here is your guideline for cross-compiling"

FESCo: "Thanks. Approved."

Now, if you (or the Board) _really_ want to make good progress on this
issue and you care about it enough then there is nothing preventing
_anyone_ from writing up those guidelines _right now_.

I understand the Board is not meant to be a technical design and
implementation body. I get that it's purpose is broader than that.
However, if there are issues that the Board thinks need attention, then
damnit make a proposal.

I know for a fact that the people on the Board are more than capable of
thinking hard about this. And you apparently have already done so. At
the very least disclose the discussion you had that made you feel so
confident that cross-compiling could be accomplished.

josh

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board

On Thu, 17 Jul 2008, Josh Boyer wrote:

Now, if you (or the Board) _really_ want to make good progress on this
issue and you care about it enough then there is nothing preventing
_anyone_ from writing up those guidelines _right now_.


I understand the Board is not meant to be a technical design and
implementation body. I get that it's purpose is broader than that.
However, if there are issues that the Board thinks need attention, then
damnit make a proposal.


I know for a fact that the people on the Board are more than capable of
thinking hard about this. And you apparently have already done so. At
the very least disclose the discussion you had that made you feel so
confident that cross-compiling could be accomplished.


A hearty +1.

No matter how committees we form, the soul of "governance" is someone
writing a policy, saying "this is how we do things now," and daring
someone to say otherwise. Nothing happens without a straw man.


--g

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board

On Thu, Jul 17, 2008 at 6:15 PM, Josh Boyer <jwboyer@gmail.com> wrote:
> I know for a fact that the people on the Board are more than capable of
> thinking hard about this. And you apparently have already done so. At
> the very least disclose the discussion you had that made you feel so
> confident that cross-compiling could be accomplished.

If I remember the conversation accurately, I believe spot's comments
concerning his personal use koji to build a perl branch assuaged my
primary concern on whether a space can be built for this in a workable
manner. Though honestly, I'm somewhat crap with voices so it might
not have been spot. A more international grouping on the Board would
have made it easier to know whose talking when on calls based on
accents. And you are absolutely correct, the private calls suck for
this sort of stuff. We know that. We cut discussion short on
implementation details specifically because we are sensitive to the
fact that its a private call.

If you missed some of my back and forth with Richard Jones concerning
the mingw policy 'discussion', do to the over lengthy nature of my
posts, I could attempt to summarize my personal feelings on things,
just as long as everyone understands that I am doing so at the behest
of FESCo and not attempting to usurp authority. Please understand that
I am trying to be sensitive to the recent discussions concerning how
the Board and FESCo are meant to work together. I've no problem
making personal suggestions but I want to be as considerate as I can
to FESCo's role as an authority. Obviously I didn't do as well as I
could have separating my personal input to FESCo from the Board
mandate in my previous post. So I am somewhat gun shy to drop more of
personal braindump in FESCo's lap prior to them even taking up the
issue formally and talking amongst themselves.

What I would prefer to do is make sure that I am at the FESCo meeting
where this topic is introduced, so I can act as a resource to FESCo.
We should make sure that spot is there as well I guess. If FESCo
wants me to personally tap me to draft up my braindump on the
packaging policy, by working with Richard Jones and the other
developers who have initiated this.. outside of the public lists...I
can do that, as long as I haven't burned too many bridges in the fab
conversation leading up to this moment.

-jef

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board

On Thu, 2008-07-17 at 15:54 -0500, Dennis Gilmore wrote:
> On Thursday 17 July 2008, Jeff Spaleta wrote:
> > On Thu, Jul 17, 2008 at 8:21 AM, John Poelstra <poelstra@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.
> I would assume the only thing being considered for inclusion here is the
> compiler tool chain to enable people to cross build apps for windows,
Agreed, + a couple of "free" applications that should be added to be
used as testsuites.

> I see it
> no different to the current arm cross compiling toolkit.
Agreed.

> and of course if we
> can only use binary blobs for part of it its not ever going to be acceptable
> in fedora.
Emphasize on _can_ (i.e. if feasible, do so, if not don't be forced to),
because wrt. cross-toolchains

* it doesn't always make sense to build everything from scratch/source

* bootstrapping cross-toolchains may be difficult if not impossible
without (at least temporarily) inserting binary blobs, due to them offen
suffering from circular dependencies.

> are you proposing we create software builds for windows?
No.

> > If FESCo members or mingw SIG members need clarification as to what is
> > being asked of them, do not hesitate to respond.
> Id like clarification on what you think you are doing. to me its seems all you
> are doing is making noise.
?!? urgh, ... yes, there is a lot of noise on this topic.

I feel a lot of people don't want to comprehend that cross-toolchains
are ordinary (Fedora-)native applications and do not need any special
treatment besides the spots where they collide with current policies.

That said, the mingw-toolset is not any different from any arbitrary
other cross-toolchain, except that its target platform is windows and
not some other less popular OS.

Ralf



_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board

On Thu, 2008-07-17 at 19:57 -0800, Jeff Spaleta wrote:
> On Thu, Jul 17, 2008 at 6:15 PM, Josh Boyer <jwboyer@gmail.com> wrote:
> > I know for a fact that the people on the Board are more than capable of
> > thinking hard about this. And you apparently have already done so. At
> > the very least disclose the discussion you had that made you feel so
> > confident that cross-compiling could be accomplished.
>
> If I remember the conversation accurately, I believe spot's comments
> concerning his personal use koji to build a perl branch assuaged my
> primary concern on whether a space can be built for this in a workable
> manner. Though honestly, I'm somewhat crap with voices so it might
> not have been spot. A more international grouping on the Board would
> have made it easier to know whose talking when on calls based on
> accents.

I believe you're correct, it was Spot.

> And you are absolutely correct, the private calls suck for
> this sort of stuff. We know that. We cut discussion short on
> implementation details specifically because we are sensitive to the
> fact that its a private call.

We did try to keep the conversation focused on the political concerns of
whether, and to what extent, we should allow, encourage, or provide
resources for cross-platform toolchains. The Board members, including
Jef, have brought up several different facets of these issues in his
previous messages here and on fedora-devel-list.

> If you missed some of my back and forth with Richard Jones concerning
> the mingw policy 'discussion', do to the over lengthy nature of my
> posts, I could attempt to summarize my personal feelings on things,
> just as long as everyone understands that I am doing so at the behest
> of FESCo and not attempting to usurp authority. Please understand that
> I am trying to be sensitive to the recent discussions concerning how
> the Board and FESCo are meant to work together. I've no problem
> making personal suggestions but I want to be as considerate as I can
> to FESCo's role as an authority. Obviously I didn't do as well as I
> could have separating my personal input to FESCo from the Board
> mandate in my previous post. So I am somewhat gun shy to drop more of
> personal braindump in FESCo's lap prior to them even taking up the
> issue formally and talking amongst themselves.

I think everyone realizes you speak for yourself. Much like Seth, only
with ten times the verbosity. ;-)

> What I would prefer to do is make sure that I am at the FESCo meeting
> where this topic is introduced, so I can act as a resource to FESCo.
> We should make sure that spot is there as well I guess. If FESCo
> wants me to personally tap me to draft up my braindump on the
> packaging policy, by working with Richard Jones and the other
> developers who have initiated this.. outside of the public lists...I
> can do that, as long as I haven't burned too many bridges in the fab
> conversation leading up to this moment.

The Board at large has obviously has an interest in this topic from the
perspective of the Fedora Project's mission.

Spot as Fedora Engineering Manager has an interest in being at next
week's FESCo meeting. Since IIRC it's the kickoff for the new FESCo,
he'll want to make sure they know he's available as an informal advisor.
He can ensure any implementation details they discuss are informed by
the resources available from the Red Hat Engineering perspective.

Any community member, including someone who also happens to be a Board
member, can show up for FESCo meetings, add items to their agenda, and
make proposals. (No fair voting or pulling rank though, just because
you're on the Board.) ;-) FESCo is there to decide on the technical
merits and implementation. If a proposal comes from a Board member who
understands the Board's position on a topic, that hopefully cuts a step
out of any potential processing. I don't think there's a point in
waiting for FESCo to ask you to do something. Just prepare something,
and tell people about it so they can discuss it before a meeting.

This is a great opportunity for the new FESCo -- assuming I'm correct
that next week will be the new group's first gathering -- to set the
tone for their meetings. Seeing as how it's Friday already, any
proposal might not have any discussion time before that first meeting.
Jef, if I were you, I'd work with Richard et al. to have something ready
next week, so it could be discussed substantially outside of the FESCo's
block of meeting time and not consume their whole hour.

--
Paul W. Frields
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://paul.frields.org/ - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board