Fedora Board Meeting Recap 2009-02-03

[inode0]

On Sat, Feb 7, 2009 at 3:40 AM, Jon Stanley <jonstanley at gmail.com> wrote:
> On Thu, Feb 5, 2009 at 10:59 PM, inode0 <inode0 at gmail.com> wrote:
>
>> The packaging guidelines are not clear to me about whether cowsay is
>> or isn't code. They also aren't clear to me about whether OVM is or
>> isn't code. Judging from the FESCO minutes I would hazard a guess that
>> it wasn't entirely clear to them as a body either. Is it clear to
>> board members whether cowsay and/or OVM are code or content?
>
> OVM was brought to FESCo as content, and that classification seemed to
> be appropriate - per spot's definition later in this thread, OVM *is*
> useful in a standalone state - as input to a SystemVerilog interpreter
> and/or compiler.

Ok. I don't know how OVM became content in the discussion, it seems
from the explanation spot has given here that it is code and can
reasonably be excluded at this time for lacking a compiler available
in Fedora.

> However, the only thing that it's useful to is a proprietary
> SystemVerilog interpreter - there is no free consumer for this (as per
> the previous definition) content.

This view is very code-centric. When I look at other content included
in Fedora most of it only needs to be viewable by the user (and meet
other requirements of course). If OVM is viewed as content its
usefulness likely needs to be judged differently. Do users benefit
from being able to read it? Do developers benefit from having access
to a reference implementation of a standard used in this field? When
viewed in this way as content there are free consumers in Fedora.

>> The distinction matters because content has additional requirements
>> beyond what is required of code to be included according to the
>> guidelines. Whether the FESCO decision with respect to OVM was correct
>> or not, the process made this onlooker feel uncomfortable as the
>> distinction between code and content in some cases is so fuzzy that it
>> appears to be decided by whimsy.
>
> I don't think that it's quite whimsy.  As I discussed with you at
> length on IRC, this is no different than me submitting a freely
> licensed C# library without the free mono interpreter in Fedora - it's
> useless without it.

Again you are talking about code.

>> I know FESCO is a serious body. I know they take their work seriously.
>> I also know there are some hard feelings, those happen from time to
>> time. I am sure I am not the only one who finds this decision
>> baffling. Even when I ask is OVM code or content, I get both answers.
>
> I admit to an onlooker that it could be a baffling decision, however
> it was not random or without careful deliberation (and to be clear,
> all deliberation took place in public - either via fedora-devel or in
> the meeting).  After the submitter disagreed with our decision, we
> decided to take it up again, and came up with the identical decision -
> that while we were quite enthusiastic about OVM, we couldn't allow it
> in without a free method to use this content.

Quoting myself above: "I know FESCO is a serious body. I know they
take their work seriously." I'm honestly not questioning the
seriousness or the deliberation given to this by FESCo.

>> When I weigh the potential benefit of OVM with, say, the hello package
>> I can't help but wonder if including in OVM a silly little program
>> that can be compiled on Fedora but does nothing useful would allow it
>> in under the guidelines. And if so, isn't that preposterous?
>
> I agree that the benefit of OVM is greater than that of hello (or
> cowsay, which for the record I maintain for EPEL), however, the
> guidelines are fairly clear here - Fedora Legal brought it to FESCo as
> doubtful content, and FESCo made a decision on that (and for the
> record, spot was in favor of this content being included per the
> review request). I realize that there were hard feelings hare, but
> those happen, and the most important thing here is that none were
> intended by any party.

I will admit I'm now baffled by spot's position expressed in the BZ.
If it is code, and I don't see why it is any different than cowsay
without a free perl in that respect, then it should be rejected for
the reasons spot gave here.

> At times, FESCo is required to take a 50,000 foot view of things. From
> that vantage point, this wasn't a precedent that we (or at least I
> personally, I'll let other members speak for themselves) were willing
> to set.

My issue wasn't with the outcome (although I do admit my instincts are
to allow it as content) so much as it was with not being able to fully
understand the reasoning behind it. And to be honest, I think the
reasoning behind it is treating it as code and not as content. The
emphasis, which now seems unnecessary, on the packaging guideline
section on code vs. content seems a diversion that only added to the
confusion.

Unless I'm still confused and we probably should just accept that as
my fate now if I still am.
Thanks for the discussion, I do feel more comfortable now with the
principles behind the decision. I do appreciate the efforts made here
to help me understand this issue better.

John