Fedora board vote and way forward

Christian Schaller cschalle at redhat.com
Fri Jan 24 18:23:17 UTC 2014


Hi Adam,
It is not really a question of trying to be tricky here. I understand that us trying to find a solution both sides can live with here feels frustrating to you, as it constantly butts head against where you feel the boundary should be, but trust me the situation is frustrating for us too.

But I agree that a tenable solution is not likely to be found in this direction, so I think what we need is to take a step back and some timeout to try think outside the box about this problem. Your idea from yesterday to enable features such as this in a differently branded product has some obvious issues to me, but at least it was a good example of someone trying to come up with a solution to the disagreement by not getting locked into the the context of the current debate, and thus maybe something we should at least think about. Anyway maybe some brainstorming is what is needed here.

Christian


----- Original Message -----
From: "Adam Williamson" <awilliam at redhat.com>
To: "Discussions about development for the Fedora desktop" <desktop at lists.fedoraproject.org>
Sent: Friday, January 24, 2014 6:11:03 PM
Subject: Re: Fedora board vote and way forward

On Fri, 2014-01-24 at 05:54 -0500, Christian Schaller wrote:
> My take away from the discussion so far is that the current board would not accept 
> anything that 'automates' access to such external software. Doesn't matter if we ship 
> the metadata on the ISO or not.
> 
> The only thing that I can see flying with the current board is a system that is 'blind' to what it is offering, just like
> a web browser.

I can see this thread goes on for miles, but I really wanted to say
this.

Christian: This is not a question of being tricksy with technical
implementation details. It is a question of principle. The Board is not
attempting to give you oblique hints as to how you can achieve your
initial goal without infringing on some technicality or other. The Board
has made a clear statement that the substance of your proposal conflicts
with Fedora's foundations. I wish you would respect that, rather than
trying to fiddle with the implementation details to try and argue that
you're complying with the letter of the Board's statement; as someone at
the Board meeting told me when I suggested rewording the latter
agreement to make it more clear you should not do *precisely* what
you're trying to do now, this is not a court of law and we are not
playing a game of "that depends on what the meaning of the word 'is'
is".

>From my reading of the Board meeting and my conversation with Board
members, the consensus was broadly what I suggested during the meeting:
there needs to be a 'bright line' between Fedora and not-Fedora, and
there needs to be an active and informed decision on the user/sysadmin's
part to cross that line. What you are now proposing violates that
principle even more than your original proposal.

When the board talked about 'reducing technical barriers' it wasn't
talking about this: it was acknowledging the broader debate about
whether the perceived difficulty of using third party software in Fedora
is *really* about the poor infrastructure for the building and
distribution of such software, rather than any problem with the process
of hopping the 'bright line' itself, which as others have pointed out,
really isn't that onerous: clicking on a package that contains a .repo
definition and saying 'yes' a couple of times is not rocket science. So
the Board was endorsing the idea of looking at the *real* pain points
for third party software use instead of trying to subvert the
fundamental principles of the project in a way that doesn't even address
the correct problem.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
desktop mailing list
desktop at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop


More information about the desktop mailing list