Fedora Present and Future: a Fedora.next 2014 Update (Part II, “What’s Happening?”)

[Matthew Miller]

I promised a while ago that I would provide a text version of my talk at
DevConf, for people who couldn't make it and because sitting through a video
of me standing up there going on and on doesn't really make for good
followup discussion.

I posted a link to the first part last week:

<http://fedoramagazine.org/fedora-present-and-future-a-fedora-next-2014-up...

and now, Part II:

<http://fedoramagazine.org/fedora-present-and-future-a-fedora-next-2014-up...

And as I said last week, I will take questions, comments, complaints, in any
media including replies here, on the article, on the social media, or at any
bar or coffee shop within walking distance of Boston's MBTA.



-- 
Matthew Miller    --   Fedora Project    --    <mattdm(a)fedoraproject.org&gt;
                                  "Tepid change for the somewhat better!"

[Richard W.M. Jones]

On Fri, Mar 28, 2014 at 01:11:58PM -0400, Matthew Miller wrote:
>  I promised a while ago that I would provide a text version of my talk
> at
>  DevConf, for people who couldn't make it and because sitting through a video
>  of me standing up there going on and on doesn't really make for good
>  followup discussion.
>  
>  I posted a link to the first part last week:
>  
>
> <http://fedoramagazine.org/fedora-present-and-future-a-fedora-next-2014-up...
>  
>  and now, Part II:
>  
>
> <http://fedoramagazine.org/fedora-present-and-future-a-fedora-next-2014-up...
>  
>  And as I said last week, I will take questions, comments, complaints, in any
>  media including replies here, on the article, on the social media, or at any
>  bar or coffee shop within walking distance of Boston's MBTA. 
So first I'll say these are interesting articles, and I encourage
people to read them.

I work better when I see some examples of what this would mean in
practice.  Under Fedora.next, how & where would you see the following
being packaged?

 - libvirt

Big, with lots and lots of big dependencies, but for virtualization
it's pretty much the definition of a core, stable API.

 - virt-manager

An application written in Python, and therefore needing to be "above"
the stacks layer, I think?

 - VLC

Free software video player, but with a requirement (or at least can
use if available) proprietary / patented / ugly / semi-legal codecs.
Currently packaged in RPMFusion for reasons I'm not clear on.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/30/2014 11:00 AM, Richard W.M. Jones wrote:
>  On Fri, Mar 28, 2014 at 01:11:58PM -0400, Matthew Miller wrote:
> > I promised a while ago that I would provide a text version of my
> > talk at DevConf, for people who couldn't make it and because
> > sitting through a video of me standing up there going on and on
> > doesn't really make for good followup discussion.
> > 
> > I posted a link to the first part last week:
> > 
> >
> <http://fedoramagazine.org/fedora-present-and-future-a-fedora-next-2014-up...
> >
> >
> >  
and now, Part II:
> > 
> >
> <http://fedoramagazine.org/fedora-present-and-future-a-fedora-next-2014-up...
> >
> >
> >  
And as I said last week, I will take questions, comments, complaints, in any
> > media including replies here, on the article, on the social
> > media, or at any bar or coffee shop within walking distance of
> > Boston's MBTA.
>  
>  So first I'll say these are interesting articles, and I encourage 
>  people to read them.
>  
>  I work better when I see some examples of what this would mean in 
>  practice.  Under Fedora.next, how & where would you see the
>  following being packaged?
>  
>  - libvirt
>  
>  Big, with lots and lots of big dependencies, but for
>  virtualization it's pretty much the definition of a core, stable
>  API.
>   
libvirt is one of those pieces that we need to settle on its
positioning. At the absolute minimum, the Fedora Server will almost
certainly declare it part of our guaranteed API. Given its
wide-ranging utility, I'd also like to see it as part of the Base
Design (which means that it is assumed to be a guaranteed API
available to all Products).


>  - virt-manager
>  
>  An application written in Python, and therefore needing to be
>  "above" the stacks layer, I think?
>   
As Matthew noted: these are *policy* rings, not packaging. The idea is
that each ring could conceivably carry different policies, such as
applications that are outside this layer being given relaxed rules
(e.g. bundling exceptions in the outer rings could be assumed rather
than FPC-approved, provided that the RPM includes "Provides:
bundled(libfoo)")[1]




>  - VLC
>  
>  Free software video player, but with a requirement (or at least
>  can use if available) proprietary / patented / ugly / semi-legal
>  codecs. Currently packaged in RPMFusion for reasons I'm not clear
>  on.
>   
I think it's packaged in RPMFusion because it contains an
implementation of a CSS decoder but I could be mistaken.



[1] Note: this is not an approved proposal, but it's one I'm
personally in favor of.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlM5VMcACgkQeiVVYja6o6MX9QCeMbkGUNhWr0yMbZvzomJ+bbD8
> 1M0AnirwkNvoXJbJsbsfq9APN09cq1FO
> =ZR40
> -----END PGP SIGNATURE-----

[Josh Boyer]

On Mon, Mar 31, 2014 at 7:43 AM, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  On 03/30/2014 11:00 AM, Richard W.M. Jones wrote:
> > On Fri, Mar 28, 2014 at 01:11:58PM -0400, Matthew Miller wrote:
> >> I promised a while ago that I would provide a text version of my
> >> talk at DevConf, for people who couldn't make it and because
> >> sitting through a video of me standing up there going on and on
> >> doesn't really make for good followup discussion.
> >>
> >> I posted a link to the first part last week:
> >>
> >>
> <http://fedoramagazine.org/fedora-present-and-future-a-fedora-next-2014-up...
> >>
> >>
> >>
>  and now, Part II:
> >>
> >>
> <http://fedoramagazine.org/fedora-present-and-future-a-fedora-next-2014-up...
> >>
> >>
> >>
>  And as I said last week, I will take questions, comments, complaints, in any
> >> media including replies here, on the article, on the social
> >> media, or at any bar or coffee shop within walking distance of
> >> Boston's MBTA.
> >
> > So first I'll say these are interesting articles, and I encourage
> > people to read them.
> >
> > I work better when I see some examples of what this would mean in
> > practice.  Under Fedora.next, how & where would you see the
> > following being packaged?
> >
> > - libvirt
> >
> > Big, with lots and lots of big dependencies, but for
> > virtualization it's pretty much the definition of a core, stable
> > API.
> >
>
>  libvirt is one of those pieces that we need to settle on its
>  positioning. At the absolute minimum, the Fedora Server will almost
>  certainly declare it part of our guaranteed API. Given its
>  wide-ranging utility, I'd also like to see it as part of the Base
>  Design (which means that it is assumed to be a guaranteed API
>  available to all Products). 
Workstation will require this too.  Having it be in Base is a good idea.

josh

[Jaroslav Reznik]

----- Original Message -----
>  On Mon, Mar 31, 2014 at 7:43 AM, Stephen Gallagher
> <sgallagh(a)redhat.com&gt;
>  wrote:
>  > -----BEGIN PGP SIGNED MESSAGE-----
>  > Hash: SHA1
>  >
>  > On 03/30/2014 11:00 AM, Richard W.M. Jones wrote:
>  >> On Fri, Mar 28, 2014 at 01:11:58PM -0400, Matthew Miller wrote:
>  >>> I promised a while ago that I would provide a text version of my
>  >>> talk at DevConf, for people who couldn't make it and because
>  >>> sitting through a video of me standing up there going on and on
>  >>> doesn't really make for good followup discussion.
>  >>>
>  >>> I posted a link to the first part last week:
>  >>>
>  >>>
> <http://fedoramagazine.org/fedora-present-and-future-a-fedora-next-2014-up...
>  >>>
>  >>>
>  >>>
>  > and now, Part II:
>  >>>
>  >>>
> <http://fedoramagazine.org/fedora-present-and-future-a-fedora-next-2014-up...
>  >>>
>  >>>
>  >>>
>  > And as I said last week, I will take questions, comments, complaints, in
>  > any
>  >>> media including replies here, on the article, on the social
>  >>> media, or at any bar or coffee shop within walking distance of
>  >>> Boston's MBTA.
>  >>
>  >> So first I'll say these are interesting articles, and I encourage
>  >> people to read them.
>  >>
>  >> I work better when I see some examples of what this would mean in
>  >> practice.  Under Fedora.next, how & where would you see the
>  >> following being packaged?
>  >>
>  >> - libvirt
>  >>
>  >> Big, with lots and lots of big dependencies, but for
>  >> virtualization it's pretty much the definition of a core, stable
>  >> API.
>  >>
>  >
>  > libvirt is one of those pieces that we need to settle on its
>  > positioning. At the absolute minimum, the Fedora Server will almost
>  > certainly declare it part of our guaranteed API. Given its
>  > wide-ranging utility, I'd also like to see it as part of the Base
>  > Design (which means that it is assumed to be a guaranteed API
>  > available to all Products).
>  
>  Workstation will require this too.  Having it be in Base is a good idea. 
Makes sense for base, as with libvirt we're close to containers.

Jaroslav

>  
>  josh
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Jóhann B. Guðmundsson]

On 03/31/2014 12:38 PM, Josh Boyer wrote:
>  Workstation will require this too.  Having it be in Base is a good
> idea. 
If there emerges a WG that does not require this from WG then what and 
was not base limiting itself to it's already defined package set?


JBG

[Jaroslav Reznik]

----- Original Message -----
>  
>  On 03/31/2014 12:38 PM, Josh Boyer wrote:
>  > Workstation will require this too.  Having it be in Base is a good idea.
>  
>  If there emerges a WG that does not require this from WG then what and
>  was not base limiting itself to it's already defined package set? 
Base is common platform for products but it does not mean everything has
to be used by other products or everything has to follow base path (for
example installer is part of Base as we agreed but it can diverge a lot
over products, and even it would not be used in all products explicitely
just to provide images - cloud). Of course if some technology gets
obsoleted/deprecated by most of products, it means the time to deprecate
it in Base comes (or change of the owner). So common sense, not exact
numbers :).

Jaroslav

>  
>  JBG
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Jóhann B. Guðmundsson]

On 03/31/2014 01:00 PM, Jaroslav Reznik wrote:
>  Base is common platform for products but it does not mean everything
> has
>  to be used by other products or everything has to follow base path (for
>  example installer is part of Base as we agreed but it can diverge a lot
>  over products, and even it would not be used in all products explicitely
>  just to provide images - cloud). Of course if some technology gets
>  obsoleted/deprecated by most of products, it means the time to deprecate
>  it in Base comes (or change of the owner). So common sense, not exact
>  numbers:). 
You do realize that the size of the base needs to be bound to the lowest 
common denominator between current and future multiple products to make 
it this kind of proposal work now and in the future right?

That immediately binds it and limit it to the size of embedded ( 
Embedded --> Cloud/Containers --> Servers --> Workstation/Desktop/Laptop 
whatever else )  to relevant packages for embedded within those 1806 
components that make up the self hosting Fedora base since there seemed 
there had been reached a perfectly logical consensus to limit what makes 
up the baseWG from those self hosting 1806 component.

Nor can you introduce components to be shared among WG outside the self 
hosting components of the baseWG and I'm quite frankly a bit stunned if 
Philipp Knirsch and the rest of the baseWG agreed to do that since by 
doing so they invalidate their own logical approach of building and 
limit baseWG to self hosting components.

JBG

[Miloslav Trmač]

2014-03-31 15:29 GMT+02:00 "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;:
>  You do realize that the size of the base needs to be bound to the
> lowest
>  common denominator between current and future multiple products to make it
>  this kind of proposal work now and in the future right? 
We are at liberty to force all possible products to carry some
overhead to simplify our work or user's expectations. For example,
even if no program in Fedora ever called glibc's hcreate() or
strfry(), we wouldn't consider dropping the implementation and
breaking the ABI; and the same thing can happen at the library level:
We are quite at liberty to promise that libvirt.so.0 will be available
on every Fedora system (even if any attempt to connect to a hypervisor
returned an error.)

Sure, such choices to simplify our environment at the cost of Base
size would disqualify us from the "smallest distribution for embedded
use", but we have never really been in that race anyway, and I'm not
even sure that size matters all that much for the embedded cases where
Fedora is an option (compared to ease of deployment, or availability
of "common" APIs, for example).

>  since by doing
>  so they invalidate their own logical approach of building and limit baseWG
>  to self hosting components. 
Only creating Base from self-hosting components does not actually make
sense to me: fedup is not necessary to compile any package, and yet it
clearly belongs in base; various specialized build tools like
documentation extractors and build test frameworks, or even make(1),
are necessary to build packages, but we may not want to promise their
existence to Base users.
     Mirek

[Jóhann B. Guðmundsson]

On 03/31/2014 01:46 PM, Miloslav Trmač wrote:
>  Sure, such choices to simplify our environment at the cost of Base
>  size would disqualify us from the "smallest distribution for embedded
>  use", but we have never really been in that race anyway 
I hardly call it simplification shifting workload and package set the 
wg's should be carrying themselves from themselves to the baseWG  and us 
not being in that race arguable is contributing to Fedora irrelevance 
since the market is moving away from traditional desktop usage to a 
smartphone/tablets.

JBG

[Corey Sheldon]

As I've til recently been a whimsical just install whatever a package needs
but am now beginning to look more granularly at this could someone either
briefly explain differences in main sources etc or link me to a good
write-up to this effect....??


much appreciated and while it hasn't been the easiest distro to learn it
has been a great learning experience and look forward to staying and
helping the community much more in the coming months and years..


TIA

Corey W Sheldon
Owner, 1st Class Mobile Shine
310.909.7672
www.facebook.com/1stclassmobileshine


On Mon, Mar 31, 2014 at 9:55 AM, "Jóhann B. Guðmundsson" <johannbg(a)gmail.com
>  wrote: 
>  On 03/31/2014 01:46 PM, Miloslav Trmač wrote:
>
> > Sure, such choices to simplify our environment at the cost of Base
> > size would disqualify us from the "smallest distribution for embedded
> > use", but we have never really been in that race anyway
> >
>
>  I hardly call it simplification shifting workload and package set the wg's
>  should be carrying themselves from themselves to the baseWG  and us not
>  being in that race arguable is contributing to Fedora irrelevance since the
>  market is moving away from traditional desktop usage to a
>  smartphone/tablets.
>
>  JBG
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

[Matthew Miller]

On Sun, Mar 30, 2014 at 04:00:28PM +0100, Richard W.M. Jones wrote:
>  So first I'll say these are interesting articles, and I
> encourage
>  people to read them. 
Thanks!

>  I work better when I see some examples of what this would mean in
>  practice.  Under Fedora.next, how & where would you see the following
>  being packaged?
>   - libvirt
>  Big, with lots and lots of big dependencies, but for virtualization
>  it's pretty much the definition of a core, stable API. 
Yeah, all of those dependencies present a problem, because some of those are
pretty fast moving. I think conceptually, in the modern world where
virtualization is everwhere, it belongs in the base. (I think certainly both
the server and workstation products will want it, and possibly cloud in some
cases.) The Base WG is trying to define a self-hosting core, though, and
it's possible that it'd be better for this to live outside of that.

>   - virt-manager
>  An application written in Python, and therefore needing to be "above"
>  the stacks layer, I think? 
Right, that is more clear.




-- 
Matthew Miller    --   Fedora Project    --    <mattdm(a)fedoraproject.org&gt;
                                  "Tepid change for the somewhat better!"

[Rex Dieter]

Richard W.M. Jones wrote:

>  - VLC
>  
>  Free software video player, but with a requirement (or at least can
>  use if available) proprietary / patented / ugly / semi-legal codecs.
>  Currently packaged in RPMFusion for reasons I'm not clear on. 
I've looked into this a bit, and discussed with other distro packagers and 
vlc upstream.

VLC is fairly modular, and it's unencumbered bits could be brought to fedora 
and the other stuff live in some -freeworld subpkg in rpmfusion. 

Implementing this would be a bit of work, but worth it in my opinion.  I 
haven't had much time to pursue implementing it myself unfortunately.  I 
only wanted to highlight that bringing vlc to fedora is possible.

-- Rex

[Adam Williamson]

On Mon, 2014-03-31 at 09:17 -0500, Rex Dieter wrote:
>  Richard W.M. Jones wrote:
>  
>  > - VLC
>  > 
>  > Free software video player, but with a requirement (or at least can
>  > use if available) proprietary / patented / ugly / semi-legal codecs.
>  > Currently packaged in RPMFusion for reasons I'm not clear on.
>  
>  I've looked into this a bit, and discussed with other distro packagers and 
>  vlc upstream.
>  
>  VLC is fairly modular, and it's unencumbered bits could be brought to fedora 
>  and the other stuff live in some -freeworld subpkg in rpmfusion. 
>  
>  Implementing this would be a bit of work, but worth it in my opinion.  I  
Well, I'm not so sure. A *lot* of people really don't understand the
patent issue. Like, at all. They don't understand modularity. Like, at
all. To a lot of people, the thing called 'vlc' is a magic black box
that plays every video ever. They "install VLC" and then they play
videos. This is the limit of their understanding.

If we make it so you can 'yum install vlc' and get something that can
barely play anything, then tell people they 'just' have to 'yum install
vlc-freeworld' to get it to actually work properly, we may wind up with
more unhappiness than we have just by having all of vlc in the Sekrit
Third Party Repository in the first place. That kinda forces them to get
the whole thing or nothing, which is almost always what they want. They
never wind up in the twilight zone where they have what is, to them,
half a VLC.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Corey Sheldon]

Whatever if they can't learn the basics and the fundamental basis of Linux
or the "Patent" issues and what have you then go somewhere else like to mac
or windows......sometimes you need to work for things and teaching a man to
fish is always better and personally while i think at first you may be
right the community as a whole will have less of the "why the #@#@@# can't
I use this or that in the development forums and force the maintainers to
make this more transparent and beyond that if you can't grasp that minor
issue then why are you on a RPM-based IT linux distro much less Fedora in
the blanking first place?


Corey W Sheldon
Owner, 1st Class Mobile Shine
310.909.7672
www.facebook.com/1stclassmobileshine


On Mon, Mar 31, 2014 at 8:17 PM, Adam Williamson <awilliam(a)redhat.com&gt;wrote:

>  On Mon, 2014-03-31 at 09:17 -0500, Rex Dieter wrote:
>  > Richard W.M. Jones wrote:
>  >
>  > > - VLC
>  > >
>  > > Free software video player, but with a requirement (or at least can
>  > > use if available) proprietary / patented / ugly / semi-legal codecs.
>  > > Currently packaged in RPMFusion for reasons I'm not clear on.
>  >
>  > I've looked into this a bit, and discussed with other distro packagers
>  and
>  > vlc upstream.
>  >
>  > VLC is fairly modular, and it's unencumbered bits could be brought to
>  fedora
>  > and the other stuff live in some -freeworld subpkg in rpmfusion.
>  >
>  > Implementing this would be a bit of work, but worth it in my opinion.  I
>
>  Well, I'm not so sure. A *lot* of people really don't understand the
>  patent issue. Like, at all. They don't understand modularity. Like, at
>  all. To a lot of people, the thing called 'vlc' is a magic black box
>  that plays every video ever. They "install VLC" and then they play
>  videos. This is the limit of their understanding.
>
>  If we make it so you can 'yum install vlc' and get something that can
>  barely play anything, then tell people they 'just' have to 'yum install
>  vlc-freeworld' to get it to actually work properly, we may wind up with
>  more unhappiness than we have just by having all of vlc in the Sekrit
>  Third Party Repository in the first place. That kinda forces them to get
>  the whole thing or nothing, which is almost always what they want. They
>  never wind up in the twilight zone where they have what is, to them,
>  half a VLC.
>  --
>  Adam Williamson
>  Fedora QA Community Monkey
>  IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
>  http://www.happyassassin.net
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

[David]

On 3/31/2014 8:37 PM, Corey Sheldon wrote:
>  Whatever if they can't learn the basics and the fundamental basis
> of
>  Linux or the "Patent" issues and what have you then go somewhere else
>  like to mac or windows......sometimes you need to work for things and
>  teaching a man to fish is always better and personally while i think at
>  first you may be right the community as a whole will have less of the
>  "why the #@#@@# can't I use this or that in the development forums and
>  force the maintainers to make this more transparent and beyond that if
>  you can't grasp that minor issue then why are you on a RPM-based IT
>  linux distro much less Fedora in the blanking first place?
>  
>  
>  Corey W Sheldon
>  Owner, 1st Class Mobile Shine
>  310.909.7672
>  www.facebook.com/1stclassmobileshine
>  <http://www.facebook.com/1stclassmobileshine> 

So what you are saying is that you want people that Use Windows in some
form or MacOS in some form that actually works as installed to switch to
Linux in some form that *does not work without fudges and hacks*?  Good
luck with that.


-- 

  David

[Ian Malone]

On 1 April 2014 02:50, David <dgboles(a)gmail.com&gt; wrote:
>  On 3/31/2014 8:37 PM, Corey Sheldon wrote:
> > Whatever if they can't learn the basics and the fundamental basis of
> > Linux or the "Patent" issues and what have you then go somewhere else
> > like to mac or windows......sometimes you need to work for things and
> > teaching a man to fish is always better and personally while i think at
> > first you may be right the community as a whole will have less of the
> > "why the #@#@@# can't I use this or that in the development forums and
> > force the maintainers to make this more transparent and beyond that if
> > you can't grasp that minor issue then why are you on a RPM-based IT
> > linux distro much less Fedora in the blanking first place?
> > 
>  So what you are saying is that you want people that Use Windows in some
>  form or MacOS in some form that actually works as installed to switch to
>  Linux in some form that *does not work without fudges and hacks*?  Good
>  luck with that.
>  
Or to put it another way, does it add any value to do work to provide
an extra RPM that doesn't provide what people expect it to in almost
all cases and will just trip people up?

-- 
imalone
http://ibmalone.blogspot.co.uk

[Corey Sheldon]

power needs to come with responsibility and understanding

Corey W Sheldon
Owner, 1st Class Mobile Shine
310.909.7672
www.facebook.com/1stclassmobileshine


On Mon, Mar 31, 2014 at 9:50 PM, David <dgboles(a)gmail.com&gt; wrote:

>  On 3/31/2014 8:37 PM, Corey Sheldon wrote:
>  > Whatever if they can't learn the basics and the fundamental basis of
>  > Linux or the "Patent" issues and what have you then go somewhere else
>  > like to mac or windows......sometimes you need to work for things and
>  > teaching a man to fish is always better and personally while i think at
>  > first you may be right the community as a whole will have less of the
>  > "why the #@#@@# can't I use this or that in the development forums and
>  > force the maintainers to make this more transparent and beyond that if
>  > you can't grasp that minor issue then why are you on a RPM-based IT
>  > linux distro much less Fedora in the blanking first place?
>  >
>  >
>  > Corey W Sheldon
>  > Owner, 1st Class Mobile Shine
>  > 310.909.7672
>  > www.facebook.com/1stclassmobileshine
>  > <http://www.facebook.com/1stclassmobileshine>
>
>
>  So what you are saying is that you want people that Use Windows in some
>  form or MacOS in some form that actually works as installed to switch to
>  Linux in some form that *does not work without fudges and hacks*?  Good
>  luck with that.
>
>
>  --
>
>    David
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Richard W.M. Jones]

On Mon, Mar 31, 2014 at 05:17:02PM -0700, Adam Williamson wrote:
>  On Mon, 2014-03-31 at 09:17 -0500, Rex Dieter wrote:
>  > Richard W.M. Jones wrote:
>  > 
>  > > - VLC
>  > > 
>  > > Free software video player, but with a requirement (or at least can
>  > > use if available) proprietary / patented / ugly / semi-legal codecs.
>  > > Currently packaged in RPMFusion for reasons I'm not clear on.
>  > 
>  > I've looked into this a bit, and discussed with other distro packagers and 
>  > vlc upstream.
>  > 
>  > VLC is fairly modular, and it's unencumbered bits could be brought to fedora 
>  > and the other stuff live in some -freeworld subpkg in rpmfusion. 
>  > 
>  > Implementing this would be a bit of work, but worth it in my opinion.  I 
>  
>  Well, I'm not so sure. A *lot* of people really don't understand the
>  patent issue. Like, at all. They don't understand modularity. Like, at
>  all. To a lot of people, the thing called 'vlc' is a magic black box
>  that plays every video ever. They "install VLC" and then they play
>  videos. This is the limit of their understanding. 
Right.  I think my question was too subtle :-(

It wasn't about whether VLC could go into Fedora, but if there going
to be a ring, with the Fedora name, where basically anything goes
including software of insalubrious legality (in the US).  And I guess
the answer is no.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

[Bill Nottingham]

Richard W.M. Jones (rjones(a)redhat.com) said: 
>  It wasn't about whether VLC could go into Fedora, but if there
> going
>  to be a ring, with the Fedora name, where basically anything goes
>  including software of insalubrious legality (in the US).  And I guess
>  the answer is no. 
Correct - the relaxing of requirements that might be considered on 'outer'
rings that still carry the Fedora name would be of a technical, not legal,
nature.

Bill