Re: LibreOffice packages

[Christian Schaller]

On Fri, Jun 2, 2023 at 9:40 AM Peter Robinson  wrote:

> On Fri, Jun 2, 2023 at 2:28 PM Stephen Smoogen 
> wrote:
> >
> >
> >
> > On Fri, 2 Jun 2023 at 07:20, Matthias Clasen  wrote:
> >>
> >> Lets not make this a drama.
> >>
> >> Package maintenance changes have never gone through change proposals.
> >>
> >
> > I am  sorry, but this was made into a drama by the way this was
> executed. Surprise is the opposite of engagement and dropping a ton of
> packages and their dependencies and then announcing it is absolute surprise.
> >
> > This isn't just package maintenance. This is a major change in what is
> expected to be included in the next workstation editions with the removal
> of expected functionality. If the packages are not picked up within a
> certain amount of time or can be rebuilt it means many packages will need
> to be edited. Those changes need to be researched, announced, and pushed
> through.
> >
> > It is also drama because people in the community have no idea what else
> will take place? When uncertainty and doubt are allowed into the
> conversation, people jump to the extremes so they can feel ready to deal
> with it.
> >
> > Could we try something different for future changes?
> > 1. Announce that Red Hat will be moving from owning said packages and
> dependencies on X date.
> > 2. Let people grieve about things for a short while but make it clear
> its happening. See if community members or other companies will take up the
> burden
> > 3. Do the orphan or hand over of packages to the new group.
> >
> > Instead of 3,1,2?
>
> That may not always be possible, sometimes it involves departure or
> changes of roles for people and those can be delicate and are not
> always notifiable. I'm not sure that is the case here but I do know,
> from a blog post [1], that the previous maintainer is no longer at Red
> Hat.
>
> Peter
>
> [1] https://meeksfamily.uk/~michael/blog/2023-05-15-caolan.html


Yeah, Matthias posting this email was us trying to give the community
proper notice. Caolan leaving accelerated things a lot here and also since
we felt it correct to inform people about how our plans around RHEL
informed this decision in Fedora we needed to spend some time getting
internal approval for that, as engineers we don't have the authority to
share what could be seen as Red Hat product plans publicly.

So while I understand that people like things to be announced with longer
horizons it is simply not always possible. We got this message out as soon
as we could.

Christian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Christian Schaller]

Yes, sorry about that meant now of course 

On Thu, Jun 1, 2023, 6:45 PM Demi Marie Obenour 
wrote:

> On 6/1/23 15:59, Christian Schaller wrote:
> > On Thu, Jun 1, 2023 at 2:36 PM Demi Marie Obenour  >
> > wrote:
> >> Why is a Flatpak a better choice for LibreOffice?
> >
> > There are a lot of ways to answer this, but from any upstream the
> advantage
> > of Flatpak is that it means package once and then deploy everywhere. So
> it
> > saves them work.
> >
> > From a Fedora perspective there is of course nobody telling anyone to not
> > maintain LibreOffice as RPMS or as a Fedora flatpak going forward, but
> even
> > if nobody does we have a good option available in the Flathub package,
> > especially with the Flathub package not being verified as the official
> > package of upstream LibreOffice.
>
> Did you mean “now”?  “not” seems like the opposite of your intended
> meaning.
>
> > Having things as Flatpaks is also of value for us to enable long term
> > efforts such as Fedora Silverblue.
> >
> > Hope this answers your question.
> >
> > Christian--
> Sincerely,
> Demi Marie Obenour (she/her/hers)
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Christian Schaller]

On Thu, Jun 1, 2023 at 2:36 PM Demi Marie Obenour 
wrote:

>
>
> Why is a Flatpak a better choice for LibreOffice?
> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)
>

There are a lot of ways to answer this, but from any upstream the advantage
of Flatpak is that it means package once and then deploy everywhere. So it
saves them work.

>From a Fedora perspective there is of course nobody telling anyone to not
maintain LibreOffice as RPMS or as a Fedora flatpak going forward, but even
if nobody does we have a good option available in the Flathub package,
especially with the Flathub package not being verified as the official
package of upstream LibreOffice.

Having things as Flatpaks is also of value for us to enable long term
efforts such as Fedora Silverblue.

Hope this answers your question.

Christian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Announcement: fdk-aac

[Christian Schaller]

For those interested the bugzilla request for adding this module is here:
https://bugzilla.redhat.com/show_bug.cgi?id=1501522



- Original Message -
> From: "Tom Callaway" 
> To: "Development discussions related to Fedora" 
> , le...@lists.fedoraproject.org
> Sent: Thursday, October 12, 2017 12:05:01 PM
> Subject: Announcement: fdk-aac
> 
> Hi Fedorans!
> 
> Today, a Third-Party Modified Version of the Fraunhofer FDK AAC Codec
> Library for Android has been cleared for inclusion in Fedora. This
> specific library has been modified to be useful with Linux and
> gstreamer, and provides some support for encoding and decoding of the
> AAC digital audio codec.
> 
> The package containing this library is called "fdk-aac".
> 
> No other AAC implementations (regardless of copyright license) are
> permitted in Fedora at this time.
> 
> Thanks,
> 
> Tom Callaway
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Christian Schaller]

I think this email from Owen summarizes what we need to keep in mind here.
Containers have caught on due to solving some important problems and thus
people are looking at models for what the future operating system would look
like where containers are the primary content delivery mechanism. In Fedora we 
have 
efforts arounds Docker/OCI containers and Flatpak containers and we are looking 
at image 
based OS installs with the Atomic and Atomic Workstation effort. The fact that 
we are 
developing stuff like this in Fedora is a good thing as
it means that if it does turn out to be a better model we are well positioned 
to take
advantage of the shift in the market. And if the scepticism some people have 
about containers
turns out to be well founded we still have our RPM based OS to fall back on.

So in the long term maybe we will start only shipping containers, if nothing 
else that is a
worthwhile goal for the efforts as it informs the design decisions we take for 
this like
Project Atomic. But having that as a effort goal and it actually becoming the 
reality is 
two very different things. If the model works really well, yes maybe we at some 
point (years)
into the future decide to stop doing RPMS (at least as an end user artifact), 
but in the meantime
nobody should feel threatened by the efforts done around containers or 
modularity.

And who knows maybe the future ends up being a bit of a hybrid, Colin Walters 
is doing great
work around rpm-ostree for instance.

Christian



- Original Message -
> From: "Owen Taylor" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, July 18, 2017 10:15:12 AM
> Subject: Re: F27 System Wide Change: Graphical Applications as Flatpaks
> 
> On Tue, 2017-07-18 at 08:35 +0200, nicolas.mail...@laposte.net wrote:
> > > > Even if it eventually succeeds crash-landing it in Fedora while
> > > > half
> > > > the security and management tools are lacking is a great way for
> > > > the
> > > > distribution to get an awful reputation, while others will rip
> > > > the
> > > > fruits of this work some years later.
> > > I'm entirely puzzled about how you think we could possibly land
> > > Flatpak
> > > support in Fedora well integrated with our infrastructure, and our
> > > security and management tools without starting to work on it, which
> > > is
> > > essentially what this change proposal is about
> > 
> > Working on it is fine. Improving it is fine. Proposing Fedora-
> > generated Flatpacks outside of Fedora is fine.
> 
> If Fedora community members are using Fedora infrastructure to build
> Flatpaks that's really by definition part of the Fedora project, isn't
> it?
> 
> > Planning to ship stuff as Flatpack only when basic questions such as
> > inter-component dependencies, automated deployment (kickstarts),
> > actual network and disk use (chromebooks), actual user adoption,
> > actual convenience of the security model, etc are not resolved is
> > not.
> 
> I think it's important to think ahead and be transparent about what we
> are thinking about, so in that sense we're "planning" to ship things
> Flatpak only. But I want to be clear that there is no *proposal* on the
> table to ship things Flatpak only, and *no proposed timescale*. And
> there won't be until we know how the tools work out for packagers, how
> Flatpak usage works out for users, and we have a significant body of
> Fedora packages built as Flatpaks to look at things like installed size
> and network usage.
> 
> These are things we can only get to by building out the infrastructure
> so that packagers can start trying building Flatpaks and users can
> start trying installing them.
> 
> > That's the hard and tedious stuff most people on this list care about
> > and GUI app writers, not a lot. That's the point of no easy return
> > where Flatpack is forced on users be it ready or not.
> 
> > There is not a vast amount of trust given past history and the way
> > some Flatpack proponents clearly intend to shaft the methods that
> > built Fedora (and its userbase) to jumpstart something else.
> 
> It's perfectly fine to be skeptical, it's perfectly fine to ask hard
> questions about areas you think need more work.
> 
> But the only way that we get to something that is an evolution of how
> Fedora currently works, that pays attention to the needs of current
> Fedora users, and builds on the strengths of the Fedora infrastructure
> and the people doing all the work in the Fedora community is to work on
> it within Fedora.
> 
> Your earlier mail could definitely be taken to mean that we should go
> off and work on Flatpak elsewhere, and when we have a fully working
> ecosystem elsewhere, and have (on our own, without any engagement)
> fully met all the needs of Fedora users, then we can look at
> integrating that into Fedora. That sounds hard to distinguish from
> ignoring Fedora and starting something else. :-)
> 
> Owen
> 

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Christian Schaller]

One major reason is that it enables us to move towards having the Atomic 
Workstation
version be the primary one and maybe in the (very) long run be the only one.

A bit more detail about that can be found here:
https://fedoraproject.org/wiki/Workstation/AtomicWorkstation

Or this talk from FLOCK by Patrick Uiterwijk:
https://www.youtube.com/watch?v=zduGfpfwHz4

Christian


- Original Message -
> From: "Richard W.M. Jones" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Friday, July 14, 2017 4:44:18 AM
> Subject: Re: F27 System Wide Change: Graphical Applications as Flatpaks
> 
> On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> >  F29: packagers (of graphical applications) must create Flatpaks of
> >   their applications if possible. They *may* keep standard RPM
> >   packaging.
> 
> At least we see where this is going.
> 
> If RPMs of the graphical application work fine now, what on earth is
> the point of forcing packagers to make Flatpaks?  Sandboxing isn't one
> of them - as already explained, sandboxing is orthogonal to packaging.
> 
> Rich.
> 
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines.  Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
> http://libguestfs.org/virt-v2v
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: mp3 encoding now ok

[Christian Schaller]

Hi, not sure why Spot hasn't chimed in, but yes this
has been run through legal. Tom and I where on the same
email thread with the laywers.

Of course on top of that the fact that they shut down the mp3licensing
operation is a pretty strong sign :)

Christian



- Original Message -
> From: "Jon" <jdisn...@gmail.com>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>
> Sent: Wednesday, May 3, 2017 4:57:18 PM
> Subject: Re: mp3 encoding now ok
> 
> Normally Spot would revel these kind of topics.
> 
> Where are you Spot?
> 
> Have you run this topic through RH legal?
> 
> Presumably one does not need legal sign-off when patents legally
> expire, but this topic is significant.
> 
> We can now package mp3 encoding software.
> 
> That is a big thing.
> 
> --Jon
> 
> On Wed, May 3, 2017 at 3:13 PM, Christian Schaller <cscha...@redhat.com>
> wrote:
> > Thanks, hadn't seen that. Ok, well I guess they do deserve some credit for
> > owning up to
> > their patents having expired. I am sure there are others out there who
> > would keep
> > claiming they still had IP in the hope of creating enough uncertainty to
> > get at least
> > some people to keep paying.
> >
> > Christian
> >
> >
> >
> > - Original Message -
> >> From: "Jon" <jdisn...@gmail.com>
> >> To: "Development discussions related to Fedora"
> >> <devel@lists.fedoraproject.org>
> >> Sent: Wednesday, May 3, 2017 2:59:32 PM
> >> Subject: Re: mp3 encoding now ok
> >>
> >> From the source:
> >>
> >> """
> >> On April 23, 2017, Technicolor's mp3 licensing program for certain mp3
> >> related patents and software of Technicolor and Fraunhofer IIS has
> >> been terminated.
> >> """
> >>
> >> https://www.iis.fraunhofer.de/en/ff/amm/prod/audiocodec/audiocodecs/mp3.html
> >>
> >> --Jon
> >>
> >> On Wed, May 3, 2017 at 1:29 PM, Denise Dumas <ddu...@redhat.com> wrote:
> >> > Congratulations!!!
> >> >
> >> >> On May 3, 2017, at 1:45 PM, Christian Schaller <cscha...@redhat.com>
> >> >> wrote:
> >> >>
> >> >> Hi,
> >> >> So just wanted everyone to know that we now have the go ahead to ship
> >> >> mp3
> >> >> encoding in Fedora too. So anyone involved with packaging
> >> >> mp3 encoders can now start migrating them to the Fedora repositories.
> >> >> We
> >> >> are still in the process of evaluating other codecs.
> >> >>
> >> >> Christian
> >> >> ___
> >> >> devel mailing list -- devel@lists.fedoraproject.org
> >> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >> > ___
> >> > devel mailing list -- devel@lists.fedoraproject.org
> >> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >>
> >>
> >>
> >> --
> >>
> >> -Jon Disnard
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org
> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >>
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> 
> 
> --
> 
> -Jon Disnard
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: mp3 encoding now ok

[Christian Schaller]

Thanks, hadn't seen that. Ok, well I guess they do deserve some credit for 
owning up to 
their patents having expired. I am sure there are others out there who would 
keep 
claiming they still had IP in the hope of creating enough uncertainty to get at 
least 
some people to keep paying.

Christian



- Original Message -
> From: "Jon" <jdisn...@gmail.com>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>
> Sent: Wednesday, May 3, 2017 2:59:32 PM
> Subject: Re: mp3 encoding now ok
> 
> From the source:
> 
> """
> On April 23, 2017, Technicolor's mp3 licensing program for certain mp3
> related patents and software of Technicolor and Fraunhofer IIS has
> been terminated.
> """
> 
> https://www.iis.fraunhofer.de/en/ff/amm/prod/audiocodec/audiocodecs/mp3.html
> 
> --Jon
> 
> On Wed, May 3, 2017 at 1:29 PM, Denise Dumas <ddu...@redhat.com> wrote:
> > Congratulations!!!
> >
> >> On May 3, 2017, at 1:45 PM, Christian Schaller <cscha...@redhat.com>
> >> wrote:
> >>
> >> Hi,
> >> So just wanted everyone to know that we now have the go ahead to ship mp3
> >> encoding in Fedora too. So anyone involved with packaging
> >> mp3 encoders can now start migrating them to the Fedora repositories. We
> >> are still in the process of evaluating other codecs.
> >>
> >> Christian
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org
> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> 
> 
> --
> 
> -Jon Disnard
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

mp3 encoding now ok

[Christian Schaller]

Hi,
So just wanted everyone to know that we now have the go ahead to ship mp3 
encoding in Fedora too. So anyone involved with packaging
mp3 encoders can now start migrating them to the Fedora repositories. We are 
still in the process of evaluating other codecs.

Christian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: YAST for Fedora?

[Christian Schaller]

Actually isn't Cockpit our 'YAST', I mean it is not a 1to1 thing, but
for a lot of things Cockpit provides the featureset a sysadmin would
want.

Christian



- Original Message -
> From: "Adam Williamson" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, April 13, 2017 2:02:57 AM
> Subject: Re: YAST for Fedora?
> 
> On Thu, 2017-04-13 at 04:05 +, Farhad Mohammadi Majd wrote:
> > Hello, SUSE distributions have a system control panel that can configure
> > many aspects of the system. It is the best feature I saw in SUSE, it is
> > very interesting, useful and beneficial for all users.
> > 
> > * Why Fedora does not have such tool?
> 
> Because we think it's fundamentally a wrong approach. Several years
> ago, Fedora decided it really wasn't the right approach for
> distributions to build unique layers of configuration tools, and we've
> been systematically *removing* the tools we used to provide along those
> lines (system-config-*) in favour of:
> 
> i) just getting things right so we don't need a giant pile of
> configuration tools
> ii) tools written at more appropriate layers, mainly desktop
> environments
> 
> > * How much money is need to develop such tool from scratch or port it from
> > SUSE to Fedora/RHEL?
> 
> It's not really a question of resources, but of not thinking this is
> the correct approach.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: The glvnd + mesa update for F25

[Christian Schaller]

- Original Message -
> From: "Rich Mattes" <richmat...@gmail.com>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>
> Sent: Tuesday, February 7, 2017 12:33:45 PM
> Subject: Re: The glvnd + mesa update for F25
> 
> On Tue, Feb 7, 2017 at 6:00 AM, Hans de Goede <hdego...@redhat.com> wrote:
> > Hi,
> >
> > On 06-02-17 23:01, Jan Pokorný wrote:
> >>
> >> On 06/02/17 15:13 -0500, Christian Schaller wrote:
> >>>
> >>> There has been a lot of discussions for the last few years about glvnd on
> >>> the mesa-devel list and at XDC. This is not Fedora specific technology,
> >>> but
> >>> a change in how Mesa will work everywhere and thus there has not been a
> >>> lot
> >>> of discussions about it here on Fedora-devel. But that is true for most
> >>> stuff,
> >>> we do not discuss major new kernel features here that much either as one
> >>> example.
> >>
> >>
> >> I don't think that's a fair point.  If there was an artificial
> >> intermediate level put in front of libc that would only be to
> >> solve issues with some hardware component, and it would be forcibly
> >> implanted into Fedora unnecessarily for all audience, then it would
> >> be comparable.
> >>
> >> But even then, I doubt it would happen without questioning such
> >> aspects.
> >>
> >> Forcing glvnd for all is Fedora specific, as far as I can tell.
> >
> >
> > I just got asked a bunch of question by the Debian X / mesa
> > maintainer about glvnd since he is working on moving Debian over
> > to this too. Really there is nothing Fedora specific about this.
> >
> 
> The change to mesa isn't fedora specific.  How and when we test and
> integrate that change (and other large, potentially breaking changes)
> with the rest of the software in the distribution is what's fedora
> specific.  That's what needs to be discussed on the list, and it's why
> the change process exists.

I fully agree, but my response was not to an email arguing about timing,
but one questioning the legitimacy of the change and the level of community
vetting it had seen.


> Kernel changes are a bad example to prove your point, for a number of
> reasons.  The kernel is specifically exempted from the stable update
> guidelines, and can be updated at any time.  Kernel upstream has a
> policy about not breaking userspace, so most changes that aren't bugs
> are just extended functionality.  That said, the kernel team has been
> emailing the devel list lately with their plans for when major kernel
> releases will hit each branch.
> 
> Rich
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: The glvnd + mesa update for F25

[Christian Schaller]

There has been a lot of discussions for the last few years about glvnd on
the mesa-devel list and at XDC. This is not Fedora specific technology, but 
a change in how Mesa will work everywhere and thus there has not been a lot
of discussions about it here on Fedora-devel. But that is true for most stuff,
we do not discuss major new kernel features here that much either as one 
example.

Christian



- Original Message -
> From: "Jan Pokorný" 
> To: devel@lists.fedoraproject.org
> Sent: Monday, February 6, 2017 2:32:35 PM
> Subject: Re: The glvnd + mesa update for F25
> 
> On 06/02/17 05:06 +0100, Kevin Kofler wrote:
> > Hans de Goede wrote:
> >> libglvnd is a solution for this it is a vendor neutral
> >> implementation of libGL.so.1 which acts as a dispatcher
> >> to one or more glvnd enabled libGL implementations
> >> installed on the systems.
> > 
> > By doing so, it decreases performance for all the users of the Mesa
> > drivers by adding an unnecessary layer of indirection. I do not see
> > performance being addressed at all in any of your communication, did
> > you even try to measure the impact of the added indirection layer?
> 
> These are the thoughts that crossed my mind as well, I'll admit.
> 
> Do we have any sort of measurements or at least the related theoretical
> backgrounds, such as "indirection will impose a small slowdown, but
> only at the very initial phase of execution till all the necessary
> symbols are resolved, no effect since then"?  Is it in fact worse?
> 
> The fact there was no serious discussion about the change is rather
> unsettling, IMHO.
> 
> --
> Jan (Poki)
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: The glvnd + mesa update for F25

[Christian Schaller]

- Original Message -
> From: "Kevin Kofler" 
> To: devel@lists.fedoraproject.org
> Sent: Sunday, February 5, 2017 11:06:36 PM
> Subject: Re: The glvnd + mesa update for F25
> 
> Hans de Goede wrote:
> > First the what: ever since AMD and NVIDIA started shipping
> > their own Linux drivers we have had multiple competing
> > implementations of libGL.so.1 (and friends) where the way
> > the linker works means that there can be only one.
> > This has made installing AMD or NVIDIA's drivers harder
> > then it has any rights to be and this has been hurting
> > out users, some of which want to use the vendor supplied
> > drivers. It often causes broken systems and makes
> > switching between drivers unnecessarily hard.
> 
> Whoever wants to use proprietary blobs that do not make use of the driver
> infrastructure in the distribution is on their own. All the drivers we ship
> in Fedora use the Mesa libGL, so there is no need for any "dispatcher".

Sorry, the real world doesn't work this way. Since we have a goal for Fedora
Workstation to actually have users we want to try solve the problems our users
actually have rather than just pontificate to the five people who failed to 
leave
the room quick enough.


> If only the time wasted on making this work had been spent on making Nouveau
> better instead…

Or in other words if people like yourself actually bothered contributing to
Nouveau instead of wasting their time other projects.

If you want Nouveau to be more widely used then the way to make that happen it
to work with us making Nouveau better. Bitching that the people already putting
a ton of resources into Nouveau are not putting even more resources into it 
is just coming across as a someone lacking any kind of self awareness, who
condemns others for failing to live up to a measurement he fails to living up
to himself.

Christian
Christia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 25 defaults to X instead of wayland

[Christian Schaller]

My guess is that you have a system with hybrid graphics,
we made it default to X since the support for hybrid graphics
is not available fully in Wayland yet. We hope to land that for
F26.

Christian



- Original Message -
> From: "Timothy Ward" 
> To: devel@lists.fedoraproject.org
> Sent: Sunday, February 5, 2017 5:40:33 AM
> Subject: Fedora 25 defaults to X instead of wayland
> 
> Just wanted the links to more information on what will cause gdm and
> session manager to default to X instead of wayland.
> 
> Have a laptop and desktop with fully updated system with debug package
> repos active and both systems default to X and will not start on
> wayland.
> 
> This was not he case with Fedora 24 where you could select in the gdm
> login screen and end up with the chosen session.
> 
> At the moment both gdm and and session default to X under gnome.
> 
> Gdm debug log confirm the fallback but does not provide descriptive
> error messages why.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support

[Christian Schaller]

While most desktop applications have migrated to 64 bit at this point there are
still many that hasn't. Steam for instance is still 32-bit afaict. So doing a 
clean
cutover like this feel a bit to drastic to me and I am not sure we have the 
market power
to 'force' vendors to quickly migrate to containers.

Christian



- Original Message -
> From: "Stephen Gallagher" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, January 5, 2017 11:03:50 AM
> Subject: Proposal: Rethink Fedora multilib support
> 
> # Overview
> 
> For many years, Fedora has supported multilib by carrying
> parallel-installable
> libraries in /usr/lib[64]. This was necessary for a very long time in order
> to
> support 32-bit applications running on a 64-bit deployment. However, in
> today's
> new container world, there is a whole new option.
> 
> I'd like to propose that we consider moving away from our traditional
> approach
> to multilib in favor of recommending the use of a 32-bit container runtime
> when
> needed on a 64-bit host.
> 
> 
> ## Advantages
> 
> * Simplification of build-tree creation. We wouldn't have to maintain the
> lists
> and hacks that are required to make sure that multilib packages land in the
> correct repositories.
> 
> * Less duplication of content in the mirror networks.
> 
> * It will be simpler to create module content without having to reimplement
> all
> the multilib hacks of above. This is directly relevant to the Base Runtime
> module, whose prototype is today intentionally limited to the primary
> architecture (no multilib).
> 
> * Requires us to maintain and keep up-to-date the 32-bit container base
> images.
> 
> 
> ## Disadvantages
> 
> * If we eliminate multilib entirely, all applications that use 32-bit libs
> will
> have to either install a 32-bit host OS or install into a container. This may
> be
> a difficult transition for some users.
>   * Mitigation: develop and maintain tools to ease this transition.
> 
> * It is unlikely that any clean upgrade path would exist. (We could make it
> *technically* possible, but likely not without breaking 32-bit software not
> installed by RPM.
> 
> * Requires us to maintain and keep up-to-date the 32-bit container base
> images.
> (Yes, this is both an advantage and disadvantage.)
> 
> 
> ## Open Questions (non-exhaustive):
> 
> * Can SSSD and systemd's 32-bit name-service modules work from within a
> container, talking to their host's service? Without that, 32-bit containers
> won't be able to resolve users, groups or hostnames.
> 
> * Can we have 32-bit containers communicate with other local system APIs such
> as
> D-BUS on the host?
> 
> * Do we need to care about 32-bit GUI applications on a 64-bit system? Should
> we
> decide that flatpak is the official answer for such cases?
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GSequencer upstream wants to package for fedora

[Christian Schaller]

That is a lot of different things mashed into one here, and while
I can not even begin to understand how you can bash our commitment to
Free Software and at the same time be an argent backer of 
Shuttleworths Snappy is beyond me, but I am sure is somehow makes sense
to you.

Also I don't think it is true in any way or form that the Working
Group is discouraging people from making RPMS, in fact I have personally
talked to a lot of different companies and people over the last year
encouraging to them to make RPMS. And Bastien Nocera who was the one
on this thread encouraging making a Flatpak is not a Working Group member,
in fact he is just a community member doing what he has every right to do,
which is to advocate the solution he thinks is best for the problem at hand.
And you of course have every right to advocate for a different approach, but
I don't see why you think slagging the Workstation Working Group somehow is the
correct response.

The proposals you misrepresent so wonderfully was a general issue of how do we 
deal with the same application being available in multiple formats, which is not
even limited to RPM and Flatpak. Offering users 10 versions of the same 
application
at the same version number with the only difference being the package technology
used is confusing and stupid. And we need to have a policy for dealing with it 
and
dealing with the fact that the recommended packaged version of an application 
might
change their package format over time. This could go both ways, but of course 
since we
have mostly RPMS these days the likelyhood is that at least in the beginning 
the 
most common case will mostly be away from RPMS. And to be clear the working 
group isn't 
spending time trying to figure out how we can offer the Gimp as a Flatpak for
example, just because it is not a very interesting problem to solve, since we 
already 
have the Gimp as an RPM. Instead we are focusing on using Flatpaks as a method 
for 
bringing new  applications to the Fedora ecosystem.

Christian

- Original Message -
> From: "Neal Gompa" <ngomp...@gmail.com>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>
> Sent: Wednesday, December 14, 2016 10:52:37 AM
> Subject: Re: GSequencer upstream wants to package for fedora
> 
> On Wed, Dec 14, 2016 at 10:27 AM, Christian Schaller
> <cscha...@redhat.com> wrote:
> > That is not 100% correct. You can make a non-sandboxed Flatpak and
> > it would work just as well as an RPM in terms of hardware access.
> > Enabling sandboxing however would need some thought and development
> > for a lot of such applications, but we are slowly but surely working
> > on it through things like the PulseAudio and Pinos work that Wim Taymans
> > is doing, and through the work that Alex Larsson has been doing with
> > OpenGL.
> 
> There's also the fact that the runtimes provided also crash on most of
> my computers, but hey, that's just a small thing, right?
> 
> Speaking with my Fedora and Mageia hats, there's nothing that stops
> ANYONE from making portable RPMs (I've done it fairly easily myself).
> Flatpak, AppImage, Snappy, etc. do not provide any material advantages
> without some sandboxing. In fact, they just make applications more
> bloated for little to no benefit at that point.
> 
> IMO, the only reason that we're starting to see this is because we're
> increasingly giving up on Free Software (note capital letters). These
> systems primarily benefit nonfree/proprietary software developers.
> 
> Speaking with my Snappy hat on, the concept of making it possible for
> people to make applications that work everywhere and anywhere is a
> very nice dream. But it's important to realize that the integration
> work has to happen somewhere. Flatpak is moving too slowly in this
> regard, and while Snappy has this functionality in spades, it requires
> much deeper integration into the distribution than Flatpak does. The
> main things keeping snaps from being a first class citizen on Fedora
> are the inability to produce snaps based on a Fedora base and Fedora
> packages (that's being worked on) and the lack of SELinux integration
> (also being worked on).
> 
> I've personally been working on these things for the Snappy system,
> but the Flatpak guys seem to be doing *nothing* about it. I'm very
> disappointed in the progress of the Flatpak system.
> 
> To date, it is still not possible to install Flatpaks through Plasma
> Discover like it is through GNOME Software. It is not possible to
> build Flatpaks from RPMs in such a manner where Fedora-based runtimes
> could power software. (Hint: both GNOME and KDE app stores support
> Snappy!) There is no evangelism from the people working on Flatpak to
> demonstrate the technology and drive any usef

Re: GSequencer upstream wants to package for fedora

[Christian Schaller]

That is not 100% correct. You can make a non-sandboxed Flatpak and
it would work just as well as an RPM in terms of hardware access.
Enabling sandboxing however would need some thought and development 
for a lot of such applications, but we are slowly but surely working
on it through things like the PulseAudio and Pinos work that Wim Taymans
is doing, and through the work that Alex Larsson has been doing with OpenGL.

Christian



- Original Message -
> From: "Neal Gompa" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, December 14, 2016 10:21:32 AM
> Subject: Re: GSequencer upstream wants to package for fedora
> 
> On Wed, Dec 14, 2016 at 10:17 AM, Bastien Nocera  wrote:
> > You're right, it's better :)
> >
> 
> Not really. Flatpak is incredibly limited in its abilities.
> Applications that interface with hardware directly are out of the
> question, for example. That means lots of pro-AV applications simply
> won't work properly in that environment.
> 
> 
> 
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora captive portal page changed output :(

[Christian Schaller]

Actually, I was told that Debarshi committed a fix for the TLS error in captive 
portal just last 
week and has pushed a fix for it.

Christian



- Original Message -
> From: "Michael Catanzaro" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, December 5, 2016 1:16:08 PM
> Subject: Re: Fedora captive portal page changed output :(
> 
> On Mon, 2016-12-05 at 09:59 -0500, Paul Wouters wrote:
> > Right now, the situation leads me to having to close the gnome window
> > which only displays "TLS certificate invalid" or some text like that,
> > and still use my firefox and a new tab/window to get through the
> > captive portal.
> 
> Good point. I guess ignoring TLS errors might mean better overall
> safety here. :/ At least for the next couple of years.
> 
> Ideally we would fix this bug before making any changes to that:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=749197
> 
> It's assigned to me, which means I'll do it eventually for some value
> of eventually; help always welcome
> 
> > In which case we are exposing the full firefox with
> > all my privacy settings and cookies to the captive portal, instead of
> > (what I hope to be) some "private window" gnome web browser that has
> > no access to any of my personal data. So I'd rather see the gnome
> > window ignoring the TLS error and proceeding.
> 
> Unfortunately you hoped too much, looks like it's using default WebKit
> data directories. I think it probably can't read your cookies from
> other apps as cookies work a bit differently, but it is getting
> everything else from the default WebKit data dirs. It really should use
> a private data dir, which is very easy to fix; then that would avoid
> any concerns about caching as well. Modified bug report:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=775639
> 
> BTW, full portal helper bug list:
> 
> https://bugzilla.gnome.org/buglist.cgi?quicksearch=component:portal-helper%20product:"gnome-shell"%20_id=173288
> 
> Michael
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: wayland in rawhide

[Christian Schaller]

- Original Message -
> From: "Josh Boyer" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, November 11, 2015 8:05:27 PM
> Subject: Re: wayland in rawhide
> 
> On Wed, Nov 11, 2015 at 7:58 PM, David Airlie  wrote:
> >
> >> That's fine.  I don't have a problem adding "GNOME on Xorg" option to
> >> the session
> >> menu in the interim. I'll do it tomorrow.
> >
> > This is what the feature page said would happen in the first place. So
> > I'm also confused why you didn't just do that.
> >
> >>
> >> I will say you're coming off (to me anyway) as somewhat combative.  We're
> >> on
> >> the same team here.  Let's keep it constructive and friendly?
> >
> > Okay, I'll try and be a little less pissed off at disabling features users
> > use, that we've spent years implementing in X/GNOME.
> >
> > The fact you are requesting wayland by default while we still have the
> > following list:
> >
> > Close all remaining feature parity gaps between the Wayland and the X11
> > session:
> >
> > input methods
> > on-screen keyboard
> > hi-dpi support
> > clipboard proxy for xwayland
> > attached modal dialogs
> > tablet support
> > startup notification
> > touch proxy for xwayland
> > accessibility features
> > output rotation
> >
> > These are just the missing features (never mind dialog boxes in wierd
> > places bugs)
> > and it doesn't even contain the USB output hotplugging, or secondary GPU
> > output use cases.
> >
> > So maybe I'm getting old, but I thought we were over shoving half-baked
> > onto users now,
> > Maybe implement all those features, get them into the non-default wayland
> > session,
> > then go lobby for enabling the wayland session by default, otherwise I feel
> > you are
> > putting the cart before the horse.
> 
> Is the concern mostly about switching to it by default and then
> somehow users won't know how to switch back to X to get their missing
> features?
> 
> I'll admit that given some of the target audience we've pushed for
> where they expect things to "just work", that might be a valid
> concern.  If they log into an F24 Gnome session and the above things
> don't work, they won't view it as "oh Wayland."   They'll view it as
> "oh, regression" and likely not look at "X/Gnome" as a choice to fix
> all of it.
> 
> There is definitely a degree of lower-level understanding required to
> get back to a "normal" state in that case.  And it isn't like people
> are going to use many of those features in GDM heavily enough that
> they'd edit the conf file to switch GDM itself to X.
> 
> I have no idea if it's possible to detect usage of the above features
> in existing installs and not default to Wayland in that case.  Or if
> it's possible to switch to X if a user turns on one of the features on
> a new install.

We do expect to get all of these resolved during the Fedora 23 lifecycle,
the reason we are switching Rawhide is to push more people to get involved
with finding and fixing the issues we do not know about yet. This is a major 
change for us as a project and we need to take collective ownership of it,
if we expect to be able to sit back and let a few dedicated people pull the 
load alone here we are setting ourselves up for failure.

And let it be clearly said if we do not get these items resolved in time for 
Fedora 24 we will not switch to Wayland as default in Fedora 24. 

There are some items, like binary driver support, that are not likely to be 
resolved for Fedora 24, but for those the automatic X fallback should kick 
inn.

Christian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: fedup for F23 and beyond

[Christian Schaller]

Sounds great, I know Allan and Richard has some mockups for
how they want to do upgrades in GNOME Software, so hopefully
this will make it even easier to implement.

Christian

- Original Message -
From: Will Woods wwo...@redhat.com
To: devel@lists.fedoraproject.org
Sent: Thursday, May 28, 2015 11:42:56 AM
Subject: fedup for F23 and beyond

[tl;dr: fedup is going away and should be re-implemented by the system
packaging tools.]

Hey all,

F22 is the fifth release we've handled with fedup. A lot has changed
since F17, and we've learned some valuable lessons about how upgrades
work (and how they fail).

We've come to the conclusion that the current design is unsupportable,
mostly due to upgrade.img, which turns out to cause more problems than
it solves[1].

So! For F23, fedup needs to be redesigned. Here's how it should work:

1) Download packages for the new system
2) Use the systemd Offline Updates[2] facility to install packages

This is really simple - simple enough that it should probably be
provided by the system packaging tools themselves.

As a proof-of-concept, I've implemented it as a DNF plugin, which you
can see here[3]: https://github.com/wgwoods/dnf-plugin-fedup

This behavior could also be implemented by PackageKit, which would make
it easy to write a proper GUI.

So that's the plan: drop upgrade.img, move upgrade support into the
system packaging tools. Sometimes simpler is better.

-w

[1] For example, here are three F22 release-blockers, all caused by
upgrade.img:
  https://bugzilla.redhat.com/show_bug.cgi?id=1185604
  https://bugzilla.redhat.com/show_bug.cgi?id=1209941
  https://bugzilla.redhat.com/show_bug.cgi?id=1207251
That first one is a nasty crash inside systemd, which led to a
mailing-list discussion[1a] where Lennart concludes that the
double-switchroot thing we're doing with upgrade.img is just not
supportable[1b]. And I totally agree.
[1a] http://lists.freedesktop.org/archives/systemd-devel/2015-March/029030.html
[1b] http://lists.freedesktop.org/archives/systemd-devel/2015-April/031013.html
[2] http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/
[3] It works just fine in F21, if you're feeling brave..

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Testing request: gdm-on-Wayland on hybrid graphics laptops (esp. Macbooks)

[Christian Schaller]

Hi William, please add yourself to the bug and of course provide any 
information you
can provide. We need to know more about the scope of this to be able to 
determine 
if its a blocker or not. Of course our challenge is that until we have a way to
reproduce on a system our devs can look at or get logs that helps us understand
what is happening it is hard to fix.

Christian



- Original Message -
 From: William will...@firstyear.id.au
 To: devel@lists.fedoraproject.org
 Sent: Thursday, May 14, 2015 7:39:10 PM
 Subject: Re: Testing request: gdm-on-Wayland on hybrid graphics laptops   
 (esp. Macbooks)
 
 On Thu, 2015-05-14 at 13:01 -0700, Adam Williamson wrote:
  Hi folks!
  
  We have a somewhat-worrying proposed blocker for F22:
  
  https://bugzilla.redhat.com/show_bug.cgi?id=1218787
  
  it appears that after a successful installation of Workstation on the
  affected system, GDM-on-Wayland fails to start correctly but also
  does
  not fall through (as it should) to GDM-on-X, leaving the user with a
  black screen and no obvious way to proceed. This is obviously a bad
  bug, but so far it has only been observed on one test system (a
  Macbook
  Pro 8,2) by one tester. A few other testers have tried to reproduce
  on
  other hybrid graphics systems, but have not been able to.
 
 
 This has affected my MacbookPro 8,2 for about a year. I want to see
 this as a blocker, so that it is taken seriously as the issue has gone
 otherwise ignored. This affects straight Xorg, not just Wayland.
 
 --
 William will...@firstyear.id.au
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation Product defaults to wide-open firewall

[Christian Schaller]

- Original Message -
 From: Robert Marcano rob...@marcanoonline.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Tuesday, December 9, 2014 8:57:51 AM
 Subject: Re: Workstation Product defaults to wide-open firewall
 
 On 12/09/2014 08:53 AM, Reindl Harald wrote:
 
 
  Am 09.12.2014 um 14:16 schrieb Bastien Nocera:
  On Tue, Dec 09, 2014 at 12:54:59PM +0100, Gerd Hoffmann wrote:
  Why we can't have something like this?  And if you don't want a popup
  asking, have something in the NetworkManager applet menu, where people
  can easily find the switch without having to search for it?  A [x]
  allow sharing checkbox?  A firewall zone selector?
 
  We can — we just need someone to design and write it.
 
  A design for something that we don't want to implement.
 
  and that is the point - you do not want and care because you seem to
  think users are too stupid to make their own decisions - you know what
  Linus said to that in direction of GNOME?
 
  This was one of the
  options when implementing the feature, one that we didn't pursue. We
  chose
  instead to use user intent as a way to do this.
 
  If you start sharing something on a network, then we consider it safe
  to share.
 
  the problem is that you don't know *who* or *what* opened the port
 
 Exactly, I think some people think we already reached the utopic world,
 when everyone install FLOSS applications from the repositories, and no
 one uses closed source applications, or worse where all sharing is done
 using GNOME control panel, and there isn't applications that doesn't
 take into account the GNOME way of doing things.
 
 What I see frequently are applications that are installed from outside
 the Fedora repositories, that can be forced to behave like Fedora
 packaging rules, with secure defaults before sharing, being installed
 and the user that don't know much about firewall settings but understand
 that the firewall is active, then think: I feel secure because I know
 the firewall is blocking external requests.

Speaking from personal experience my thoughts was never 'I feel so safe', 
instead
I just felt annoyed that for the gazilliont time things didn't work due to the 
firewall 
blocking the application or service or I was trying to run. And after trying to 
Google and 
only finding Ubuntu specific commands that never seemed to work or commands 
which was only relevant 
to Fedora 12, I tended to disable the firewall while asking myself while after 
all these years things
still sucked as much.

Christian


 and then in that utopic world things fail, for example, Fedora packaging
 rules prefer that packages are installed with sensitive defaults, I
 reported a bug about all cron email output being sent by default and it
 was discarded as a security bug (pulled by an update)
 
 https://bugzilla.redhat.com/show_bug.cgi?id=1157727
 https://bugzilla.redhat.com/show_bug.cgi?id=1158493
 https://lists.fedoraproject.org/pipermail/devel/2014-October/203781.html
 
 This is no open port, but shows that packages can have bugs and
 something that is closed by default today, can in the future be pulled
 as an update and start sharing things. Those are bugs, true, but the
 idea of opening the firewall entirely defeats the measure of defense
 already in place. To me it sounds like disabling SELinux on workstation
 because people find it difficult and decide to disable it instead.
 
 The problem that is being tried to solve is that people choose to
 disable the firewall, Why not add a simple option to the GNOME sharing
 tools to change the firewall zone to this one where ports 1024 are open
 when the user decide to share something. with the possibility to
 selecting no for those people that only want to open the only the needed
 ports?
 
 Note: I hope to not be called a troll here (joke, someone will understand)
 
 
  If you connect to a public unencrypted Wi-Fi, you won't have the
  option to. If
  you connect to an encrypted Wi-Fi where sharing your holiday photos
  isn't acceptable
  then it won't, because you didn't ask it to in the first place
 
  besides suspend / move machine
 
  a sane firewall design (sadly Windows has that in the meantime) is that
  if i open a port in my homenetwork, supsend the machine and wake it up
  in a foreign network ports are closed until i decide to open them there
  too, but Fedora goes the easy way who cares how and why as long things
  appear to work
 
  *who* told you that people don't share things *unintentional* by a wrong
  click which is *not* a problem until you decide to open ports
 
 
 
 
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation Product defaults to wide-open firewall

[Christian Schaller]

- Original Message -
 From: Brian Wheeler bdwhe...@indiana.edu
 To: devel@lists.fedoraproject.org
 Sent: Tuesday, December 9, 2014 9:18:47 AM
 Subject: Re: Workstation Product defaults to wide-open firewall
 
 On 12/09/2014 08:50 AM, Richard Hughes wrote:
 
 
 
 On 9 December 2014 at 13:39, Michael Catanzaro mcatanz...@gnome.org wrote:
 
 
 
 So your challenge is to find an alternative default that
 supports it.
 I'd go even further. I don't think the people writing the vast number
 of lengthy posts on this thread actually want to *use* workstation,
 with the possible exception of Bastien who's having to defend
 something he shouldn't have to. Reindl probably should just use the
 server spin, or be prepared to actually configure his box to do what
 he wants to be 100% paranoid and unusable for anything less than a
 technical user. If you don't like what workstation has decided to do,
 use another target, or a different distro entirely (like CentOS). If
 you want to change how workstation is designed, join the working group
 and please actually talk to people there. I think it's misguided to
 think that hurling insults here is going to achieve change.
 
 I think a lot of people also need to remember that workstation isn't
 built for them, and that's okay. If you know how to configure iptables
 then that's fine, but I'm happy to admit I don't, and normally just
 switch off the firewall entirely so I can get stuff done. F21 will be
 more secure for me, not less.
 
 Ok, so what product/spin am I supposed to use? I'm a RHEL sysadmin but I use
 Fedora on my desktop  laptop. I expect the firewall to be on so when I
 evaluate a new piece of software or do a bit of network development I don't
 inadvertently increase my exposure. I also expect things to work with the
 minimum amount of fuss.
 
 So it looks like my choices boil down to:
 * Use the workstation project and spend a bunch of time locking it down to
 what would be reasonable default for the networks I use -- and hope I don't
 miss anything.

Well I think it is hard for anyone to guess what would be reasonable defaults 
for 
you specifically, any default is by its nature just targeting an generic 
person, which might or might not be a lot like you. 

But if you are aware and understand the finer details here then it isn't that 
big a job to change it, you should be able to go into the network manager, 
choose your 
connection, choose 'identity' (should probably be moved to be under security?) 
and change 
the zone for your network to whatever suits you better. 

Christian

 * Use the server product and manually configure all of the workstation stuff
 so I get a usable system
 
 Neither of those choices seem reasonable to me, especially compared to the
 status quo: a fully configured workstation where I open new ports as I
 increase functionality.
 
 
 
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation Product defaults to wide-open firewall

[Christian Schaller]

- Original Message -
 From: Gerd Hoffmann kra...@redhat.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Tuesday, December 9, 2014 10:22:01 AM
 Subject: Re: Workstation Product defaults to wide-open firewall
 
 On Di, 2014-12-09 at 08:16 -0500, Bastien Nocera wrote:
  
  - Original Message -
   On Tue, Dec 09, 2014 at 12:54:59PM +0100, Gerd Hoffmann wrote:
Why we can't have something like this?  And if you don't want a popup
asking, have something in the NetworkManager applet menu, where people
can easily find the switch without having to search for it?  A [x]
allow sharing checkbox?  A firewall zone selector?
   
   We can — we just need someone to design and write it.
  
  A design for something that we don't want to implement. This was one of the
  options when implementing the feature, one that we didn't pursue. We chose
  instead to use user intent as a way to do this.
  
  If you start sharing something on a network, then we consider it safe to
  share.
  If you connect to a public unencrypted Wi-Fi, you won't have the option to.
  If
  you connect to an encrypted Wi-Fi where sharing your holiday photos isn't
  acceptable
  then it won't, because you didn't ask it to in the first place.
 
 That assumes all applications behave that way.  Which simply isn't true,
 there is a world outside gnome.  You apparently choose to ignore that,
 which is a bad idea IMO.

Well we are not shipping by default anything which doesn't conform to this,
and if you go out of your way to install something I don't think it is far
fetched to assume you want that thing to work.

Christian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation Product defaults to wide-open firewall

[Christian Schaller]

- Original Message -
 From: Reindl Harald h.rei...@thelounge.net
 To: devel@lists.fedoraproject.org
 Sent: Tuesday, December 9, 2014 10:04:46 AM
 Subject: Re: Workstation Product defaults to wide-open firewall
 
 
 Am 09.12.2014 um 15:57 schrieb Christian Schaller:
  Well I think it is hard for anyone to guess what would be reasonable
  defaults for
  you specifically, any default is by its nature just targeting an generic
  person, which might or might not be a lot like you.
 
  But if you are aware and understand the finer details here then it isn't
  that
  big a job to change it, you should be able to go into the network manager,
  choose your
  connection, choose 'identity' (should probably be moved to be under
  security?) and change
  the zone for your network to whatever suits you better.
 
 and why can't you do the same if you want it open instead start
 wide-open and expect from people to secure their system

I think the part of the sentence you probably missed was if you are aware 
and understand the finer details here, because for anyone who doesn't
understand the finer details here you are suggesting we default the system to 
'broken'.


 how long do you think does it take until someone is so audacious and
 installs mysql and apache with the intention just to develop some
 webscripts on his workstation *beause* he want only play around with it
 not imaging that his mysqld is open to the world and not just localhost?
 
 the same applies for *any* other service in /etc/services with a port
 number above 1024 - ship unsecure defaults and expect users to secure
 their machines is pervert - that won't happen, sooner or later damage
 will happen and nobody feels responsible
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Tasklist for the Fedora Workstation

[Christian Schaller]

Hi everyone,
As we are ramping up the development effort around the workstation we wanted to 
help increase transparency and enable more community participation in the 
Fedora Workstation 
effort by providing a more detailed view of the various tasks underway as 
derived from the more high level PRD and Technical Specification documents. You 
can find the current
version of the tasklist here - http://fedoraproject.org/wiki/Workstation - but 
we hope to expand on it in the coming days and weeks to be even more 
comprehensive and also include more explanations around the motivation for each 
task.

The list enumerates the various efforts that is being undertaken around the 
Fedora Workstation effort and also puts a name next to many of the items.
If you are interested in helping out with any of these efforts please get in 
touch by reaching out either to the Working group board members or to
the people listed next to the tasks in question. For those of you not familiar 
with the working group we have contact information and board membership 
information
available on this page:
http://fedoraproject.org/wiki/Workstation

If you are getting this email you probably already know about the mailing list, 
but the working group can also be reached on IRC on #fedora-workstation on 
freenode.
Looking forward to discussing our plans with both new and old contributors to 
the workstation product effort.

Feel free to ask questions about the various tasks as I realize that the list 
is quite low on detail atm., and not all items might be self explanatory and as 
mentioned we do hope to add more detailed information to each item in the next 
few days.

Sincerely,
Christian Schaller
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: The Forgotten F: A Tale of Fedora's Foundations

[Christian Schaller]

Well my point is I spoke to Red Hat legal before I even posted the 
original proposal to open up to more 3rd party repositories some
Months ago. There are a lot of repositories that it is perfectly 
fine for Fedora to include from a legal perspective. But they will 
need to be reviewed by legal on a case to case basis, going to legal 
up front and saying 'hey can I include a hypothetical repository'
will only yield you the answer 'depends on the repository'.

So decisions need to be general to allow us to look for a variety of options 
to fulfill them. Lets say Fedora decided we want to make it 
easier for our users to get more multimedia codecs. We would not get the 
go ahead from legal to include a repository which contains ffmpeg for 
instance, but legal would probably be perfectly fine with including a 
repository containing the Cisco H264 package or the Fluendo Mp3 plugin.

So in the end this is not a legal question which needs the involvement
of the lawyers at this point, but a question of the overall goals and values
 of Fedora, and how we best achieve those goals and values.

Basically we first need to agree on the 'design' before distracting ourselves
with 'implementation'. 

Christian



- Original Message -
 From: drago01 drag...@gmail.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Wednesday, April 23, 2014 4:37:40 PM
 Subject: Re: The Forgotten F: A Tale of Fedora's Foundations
 
 On Wed, Apr 23, 2014 at 4:24 PM, Stephen John Smoogen smo...@gmail.com
 wrote:
 
 
 
  On 23 April 2014 02:29, Christian Schaller cscha...@redhat.com wrote:
 
  Hi Mairin,
  Not sure exactly where you are coming from in terms of wanting legal
  to weigh in, but in general I don't think legals opinion is very relevant
  and this point. The first step here should always be us as a project
  deciding what
  user experience we want to offer our users, then once that is done go to
  legal
  and try to work with them to figure out how it can be done.
 
 
  The reason was that Legal was the big reason the rules are in place in the
  first place. They are not just in place because of software patents. They
  are in place because of different national laws on copyright, what is
  considered to be infringement or redistribution by even linking, trademark
  use (also dependent on nation etc), competition rules, and a probably
  another dozen other factors.
 
 All of this applies to any software regardless whether it is free or
 not (as I said in the other mail).
 Copyright law does not differentiate between free and non free software.
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: The Forgotten F: A Tale of Fedora's Foundations

[Christian Schaller]

- Original Message -
 From: Stephen John Smoogen smo...@gmail.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Thursday, April 24, 2014 6:46:03 PM
 Subject: Re: The Forgotten F: A Tale of Fedora's Foundations
 
 
 
 
 On 24 April 2014 09:56, Stephen Gallagher  sgall...@redhat.com  wrote:
 
 
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 04/24/2014 11:01 AM, Stephen John Smoogen wrote:
  
  
  
  On 24 April 2014 02:49, Christian Schaller  cscha...@redhat.com
  mailto: cscha...@redhat.com  wrote:
  
  Well my point is I spoke to Red Hat legal before I even posted the
  original proposal to open up to more 3rd party repositories some
  Months ago. There are a lot of repositories that it is perfectly
  fine for Fedora to include from a legal perspective. But they will
  need to be reviewed by legal on a case to case basis, going to
  legal up front and saying 'hey can I include a hypothetical
  repository' will only yield you the answer 'depends on the
  repository'.
  
  
  OK cool. What is the plan for when repositories change what they
  are carrying and add stuff that may be legal for them but not for
  others? Will there be periodic reviews to make sure that this
  hasn't happened or some way that we roll back what repositories we
  recommend?
  
 
 
 At the risk of being glib: What's the plan for periodically
 re-reviewing every package in Fedora to make sure that its sources
 always remain legal?
 
 It's the same problem and it can only realistically be dealt with by
 If someone notices, deal with it then.
 
 There are a couple of differences. If we find that dvdcss was added to a
 package, we can rip out that package, put an update in the repository and
 people who do updates get a package without dvdcss. A third party repository
 is one we don't have any control over. If code that the 3rd party has no
 legal right to ship or fill in problem here, what is our remediation to our
 users? Are we in contributary infringement because we gave the users a way
 access to pirated software that we never intended in the first place? Is
 there an agreement between us and the third party that they are to be
 offering X, that they are legally able to offer X, and that if they are not
 they are to take all liability of offering X?
 
 These were things that people were wondering when this came up in the past.

Once again this is becoming a debate about hypotheticals which rarely leads 
anywhere
constructive. 

To take a concrete case instead. Are you really worried about Google starting 
to ship
dvdcss as part of their Chrome repository? Do you really think that is a 
question 
keeping our lawyers up at night?

Are there repositories out there where we can not trust the person or company 
behind
it enough to include it by default for legal reasons? Sure there is, but you 
can't say 
that just because we would not want to risk shipping the rpm-warez.tor.net repo 
by default 
all 3rd party repos are high risk and something our lawyers would be concerned 
about. Because 
that is the argument you in practice is making when you are posing hypothetical 
questions about 
the risk of 3rd party repos.

Christian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: The Forgotten F: A Tale of Fedora's Foundations

[Christian Schaller]

Hi Mairin,
Not sure exactly where you are coming from in terms of wanting legal 
to weigh in, but in general I don't think legals opinion is very relevant
and this point. The first step here should always be us as a project deciding 
what
user experience we want to offer our users, then once that is done go to legal
and try to work with them to figure out how it can be done.

A lawyers job is to worry, so if we make lawyers not being worried at all a 
pre-requisite to even thinking about something we should probably not be doing
software at all. The brokenness of the US patent system combined with more
brokenness in how the US legal system handles software patents probably means
a lawyer would advice you to not be involved with software making at all due to 
the
legal risks :)

Christian



- Original Message -
 From: Máirín Duffy du...@fedoraproject.org
 To: Stephen Gallagher sgall...@redhat.com, devel@lists.fedoraproject.org
 Sent: Tuesday, April 22, 2014 4:10:49 PM
 Subject: Re: The Forgotten F: A Tale of Fedora's Foundations
 
 On 04/22/2014 09:13 AM, Stephen Gallagher wrote:
  So one of the key questions here is whether the current policy on
  essentially hiding (protecting?) the user from these external software
  sources is truly in keeping with our Foundations, Mission and general
  project health.
 
 To be honest, I'm fairly uncomfortable discussing this without Fedora
 Legal weighing in. I don't see any problem with re-visiting the
 decisions made along this path, but I also am pretty confident the folks
 who decided things had to be this way are really smart and had good
 reasons.
 
 ~m
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Workstation: Disable firewall

[Christian Schaller]

- Original Message -
 From: Liam l...@fightingcrane.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Monday, April 21, 2014 10:10:13 PM
 Subject: Re: F21 System Wide Change: Workstation: Disable firewall
 
 
 
 
 On Apr 21, 2014 4:32 AM, drago01  drag...@gmail.com  wrote:
  
  On Mon, Apr 21, 2014 at 3:49 AM, Liam  l...@fightingcrane.com  wrote:
   Sent from mYphone
   
   
   On Apr 20, 2014 7:02 PM, drago01  drag...@gmail.com  wrote:
   
   On Mon, Apr 21, 2014 at 12:39 AM, Reindl Harald  h.rei...@thelounge.net
   
   wrote:
   
There have been other suggestions in this thread that are helpful
like
the network zones thing (but we still have too many zones) or
enabling
services should make them work i.e
just enable the firewall rules.

which make sense
   
   Oh finally you seem to understand what this is all about (a few mails
   ago this was supposed to be strongly prohibited ...)
   Now please goolge for Psychological Acceptability and Security you
   will find tons of scientific papers (read them) explaining about why
   it is wrong to silently break stuff or ask yes / no question or
   arguing with this is not a blackbox the user should learn nonsense.
   
   There is difference between a software developer, a sysadmin and a
   user that simply wants to share his music with his family. The latter
   should not have to learn about computer security to do it,
   while for the former it does not matter that much as you said because
   they ought to know what to do or where to get that information from.
   
   The later isn't the target for Workstation, I don't believe.
  
  Not the *primary* target but still one see the Other users section in the
  PRD.
  --
 That's fine, but that's not who we need to be optimizing the experience for.
 We need to be focusing on our primary target. After that others can be
 considered.
 A developer can handle this if it is presented well, but we shouldn't let
 secondary users harm, at all, the experience of the primary user. If we do,
 then this reorganization isn't working, IMHO.

I think this is a misunderstanding of who a developer might be and why they 
choose
a system. Those of my friends and acquaintances, who are developers and who 
over the 
years have decided to switch their development laptops from Linux to 
predominantly 
MacOS X, has not done so because they had things they wanted to do that was 
'impossible' to do with Linux or that they thought they could not figure out 
how to 
do with linux. Instead they moved because they got tired of spending time 
trying to 
make their system 'work'. This is in no way limited to dealing with the 
challenges 
of a firewall, but if we want to attract developers or any kind of user to our 
system we need to make it usable without needing daily google searches
to figure out how you can do something and make parts of your system work.

As a sidenote, there has been a lot of discussions on this an other Fedora lists
over the last few Months where people have loudly come out against what they see
as infringements on the Freedom part of the four F's. Having seen this thread I 
am disappointed to see that nobody has come out in defense of the Friends part 
of the four F's, because the language and tone used by some people on this 
thread
has been beyond pale, accusing the other participants in the thread of 
stupidity,
incompetence and general maliciousness. If this doesn't change maybe the time 
has come 
for a board ticket to change that F from Friends to Flames?

Christian

  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Workstation: Disable firewall

[Christian Schaller]

- Original Message -
 From: Thomas Woerner twoer...@redhat.com
 To: devel@lists.fedoraproject.org
 Sent: Tuesday, April 22, 2014 11:23:46 AM
 Subject: Re: F21 System Wide Change: Workstation: Disable firewall
 
 On 04/21/2014 12:22 AM, drago01 wrote:
  On Mon, Apr 21, 2014 at 12:02 AM, Reindl Harald h.rei...@thelounge.net
  wrote:
 
  * there are network services enabled by default
 
  Again that's a bug and a viloation of the guidelines. Which services
  are you talking about?
  Please file bugs.
 
  * avahi is one of them
 
  You keep listing this as an example but avahi is not only installed
  and enabled by default
  but also allowed configured to work in the default firewall setup
  since F18 [1] ...
 
  So the current default firewall won't protect you against avahi flaws.
 
 This has been added only because of a FESCo decision:
 
 https://fedoraproject.org/wiki/Features/AvahiDefaultOnDesktop
 

Thank you for digging that ticket up Thomas. I think that ticket mentions 
something maybe 
a bit overlooked in this thread so far, Real world security. I recommend 
everyone 
following this thread to watch this video of a talk by Russ Doty from Red Hat 
at this 
years DevConf in Brno.  His talk is about real world security, especially in 
the context of 
enterprise computing, but the issues he articulate forms the underlaying 
challenges of this 
thread too.

I think if everyone here see this talk we could hopefully move this thread into 
a more 
constructive format.

Christian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: The Forgotten F: A Tale of Fedora's Foundations

[Christian Schaller]

- Original Message -
 From: Nikos Roussos comzer...@fedoraproject.org

 There is also a third group, somewhere in between, who believe that's ok
 to ship Free Software that connects and interops with proprietary
 services (gtalk, aws, etc), but it's not ok to ship proprietary
 software, metadata about proprietary software or advertise proprietary
 services through our main UI tools.
 
 You should also keep in mind that Functional is very subjective and I
 don't see how it can walk through such debates. People will still align
 the Functional foundation to align with their point of view ;)
 
So this group believes it is ok to ship an open source twitter client in Fedora 
as long
as the client doesn't know how to connect to twitter or has any metadata 
mentioning it can
be used to connect to twitter? ;)

Christian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Workstation: Disable firewall

[Christian Schaller]

- Original Message -
 From: Stephen Gallagher sgall...@redhat.com
 To: devel@lists.fedoraproject.org
 Sent: Tuesday, April 22, 2014 1:40:05 PM
 Subject: Re: F21 System Wide Change: Workstation: Disable firewall
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 04/22/2014 05:43 AM, Christian Schaller wrote:
  
  
  
  
  - Original Message -
  From: Thomas Woerner twoer...@redhat.com To:
  devel@lists.fedoraproject.org Sent: Tuesday, April 22, 2014
  11:23:46 AM Subject: Re: F21 System Wide Change: Workstation:
  Disable firewall
  
  On 04/21/2014 12:22 AM, drago01 wrote:
  On Mon, Apr 21, 2014 at 12:02 AM, Reindl Harald
  h.rei...@thelounge.net wrote:
  
  * there are network services enabled by default
  
  Again that's a bug and a viloation of the guidelines. Which
  services are you talking about? Please file bugs.
  
  * avahi is one of them
  
  You keep listing this as an example but avahi is not only
  installed and enabled by default but also allowed configured to
  work in the default firewall setup since F18 [1] ...
  
  So the current default firewall won't protect you against avahi
  flaws.
  
  This has been added only because of a FESCo decision:
  
  https://fedoraproject.org/wiki/Features/AvahiDefaultOnDesktop
  
  
  Thank you for digging that ticket up Thomas. I think that ticket
  mentions something maybe a bit overlooked in this thread so far,
  Real world security. I recommend everyone following this thread
  to watch this video of a talk by Russ Doty from Red Hat at this
  years DevConf in Brno.  His talk is about real world security,
  especially in the context of enterprise computing, but the issues
  he articulate forms the underlaying challenges of this thread too.
  
  I think if everyone here see this talk we could hopefully move this
  thread into a more constructive format.
 
 
 Since you missed the link: https://www.youtube.com/watch?v=jYGgVUYjXQ8

oops, thanks for that, I had the link ready to be pasted, but forgot to actually
paste it :)

Christian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Workstation: Disable firewall

[Christian Schaller]

- Original Message -
 From: Reindl Harald h.rei...@thelounge.net
 To: devel@lists.fedoraproject.org
 Sent: Tuesday, April 15, 2014 11:40:20 AM
 Subject: Re: F21 System Wide Change: Workstation: Disable firewall
 
 
 Am 15.04.2014 11:32, schrieb drago01:
  On Tue, Apr 15, 2014 at 11:18 AM, Reindl Harald h.rei...@thelounge.net
  wrote:

 allow any random application to open a unprivlieged
 port which is reachable from outside is dangerous
 
We already allow that and have for a long while. Any application bothering to 
support the firewalld dbus interface can open any port 
they wish to.

There was a long thread about this on the desktop mailing list, and I was not 
in the 'disable the firewall' camp in that discussion,
but nobody in that thread or here have articulated how the firewall exactly 
enhance security in the situation where we at the 
same time need to allow each user to have any port they desire opened for 
traffic to make sure things like DLNA or Chromecast works.

The thread discussing this ended up with mostly being a discussion if the 
firewall would be a useful way to help users from accidentally 
oversharing on a public network. Which is important and something we want to 
work on, but a lot less so than security issues.

Christian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Workstation: Disable firewall

[Christian Schaller]

- Original Message -
 From: Simo Sorce s...@redhat.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Tuesday, April 15, 2014 4:37:38 PM
 Subject: Re: F21 System Wide Change: Workstation: Disable firewall
 
 On Tue, 2014-04-15 at 10:28 -0400, Christian Schaller wrote:
  - Original Message -
   From: Reindl Harald h.rei...@thelounge.net
   To: devel@lists.fedoraproject.org
   Sent: Tuesday, April 15, 2014 11:40:20 AM
   Subject: Re: F21 System Wide Change: Workstation: Disable firewall
   
   
   Am 15.04.2014 11:32, schrieb drago01:
On Tue, Apr 15, 2014 at 11:18 AM, Reindl Harald
h.rei...@thelounge.net
wrote:
  
   allow any random application to open a unprivlieged
   port which is reachable from outside is dangerous
   
  We already allow that and have for a long while. Any application bothering
  to support the firewalld dbus interface can open any port
  they wish to.
  
  There was a long thread about this on the desktop mailing list, and I was
  not in the 'disable the firewall' camp in that discussion,
  but nobody in that thread or here have articulated how the firewall exactly
  enhance security in the situation where we at the
  same time need to allow each user to have any port they desire opened for
  traffic to make sure things like DLNA or Chromecast works.
  
  The thread discussing this ended up with mostly being a discussion if the
  firewall would be a useful way to help users from accidentally
  oversharing on a public network. Which is important and something we want
  to work on, but a lot less so than security issues.
 
 There is plenty of prior art here.

 What you need is clearly different zones that the user can configure
 and associate to networks, with the default being that you trust nothing
 and everything is firewalled when you roam a new network.
 
 firewalld should grow a NetworkManager plugin so that configuration can
 be changed on the fly based on which network NM tells firewalld a
 specific interface is connected to.
 
 Applications need to be prevented from being able to arbitrarily open
 ports, that should be allowed only for a trusted zone. User
 intervention should be needed to mark a zone as trusted, in all other
 zones the user will have to select explicitly what applications are
 allowed.
 
 So the big work here is in the UI you need to build to present these
 configurations to the user.
 
 Until then you can present a very simplified UI that just has a big
 button/switch that turns everything from untrusted to trusted, with
 the default being untrusted of course.

All of this are points I actually made myself in the corresponding thread
on the desktop list. I suggest you read that to see the prior discussion on 
the subject here. 

The thread starts here:
https://lists.fedoraproject.org/pipermail/desktop/2014-February/009142.html

Christian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 Self Contained Change: Playground repository

[Christian Schaller]

To chime in here, we have been doing something like this in 
GStreamer for a long while. There is 'plugins-base' and 'plugins-good' 
plugins which is comparable to the current core Fedora repository.
Any plugin going into base or good need to conform to certain
coding standards, licensing standards and documentation standards.

Then there is 'plugins-ugly' which is more like rpmfusion. It still 
has the coding and documentation standards, but licensing can be 
of a wider variety. (Not just 'non-free' as GStreamer do not accept 
GPL plugins into the base or good repositories either due to being a 
LGPL toolkit).

Finally there is plugins-bad, which is a bit more like what I think 
Playground will be. It is a repository with plugins which for a variety 
of reasons are not ready for any of the other ones yet. This could be 
that they are not of a high enough coding quality yet or lack documentation, 
but they still 'work'. And what we found over the years, is that while 
it is good to have high standards for these plugins to stretch towards 
in order to get included in one of the other modules, having 'bad' 
available is crucial as a way to get access to plugins that might be 
critical to their usecase even if they are not up to our technical
standards yet. So while it can be frustrating that some plugins end 
up lingering in bad for a long time, it is still a much better scenario 
than people deciding GStreamer is useless for them and move somewhere else.

Christian



- Original Message -
 From: Stephen Gallagher sgall...@redhat.com
 To: devel@lists.fedoraproject.org
 Sent: Tuesday, April 8, 2014 7:04:54 PM
 Subject: Re: F21 Self Contained Change: Playground repository
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 04/08/2014 12:24 PM, Michael Cronenworth wrote:
  Jaroslav Reznik wrote:
  For now the Playground repository contains both packages that are
  destined for eventual inclusion into the main Fedora repository
  and *packages that are never going to make it there.*
  
  This sounds like a problem and not a feature. Why would packages
  never make it to Fedora, yet be available in this new repository?
  
  My intent here is to be constructive so my question is genuine. I
  don't believe Fedora should start down the path of a fragmented
  repository structure. It makes sense for RHEL and its software
  channels it can sell support for, but Fedora is different.
  RPMFusion being an exception as it is a legal necessity.
 
 My interpretation here is that there exists plenty of genuinely
 open-source software out there for which it will likely never be
 possible to package fully according to Fedora's packaging guidelines
 due to bundling or similar issues (the obvious example being the
 oft-requested Chromium).
 
 Similarly, there are a great many useful Ruby libraries and
 applications out there for which unbundling them would be an exercise
 in futility. Ask yourself which is more important to most users:
 1) My OS is perfectly maintainable by engineers.
 or
 2) My OS lets me install the software I need without hassle.
 
 Offering users a slightly-less stringent repository such as this makes
 sense.
 
 Also packages that are never going to make it there should probably
 have been phrased more politically: Even if the reality of the
 situation is that perfect adherence to the Fedora packaging guidelines
 is infeasible.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
 
 iEYEARECAAYFAlNELDYACgkQeiVVYja6o6MoCACggkj5lqoAtzbDxboz94/bxXma
 wH4AoI33Q7n/z2W+q6+9baU1ohhR7iXg
 =IzBI
 -END PGP SIGNATURE-
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Christian Schaller]

- Original Message -
 From: Matthew Miller mat...@fedoraproject.org
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Friday, March 21, 2014 12:59:01 PM
 Subject: Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
 
 On Fri, Mar 21, 2014 at 10:28:26AM +0100, Marcela Mašláňová wrote:
  I agree with Jaroslav. I was looking forward to have a fourth
  product to those three. KDE can help define what is needed for new
  product, what must be done by all teams, how much work it will be
  ... I guess we should speak more about addition of new product and
  don't kill the idea at the start.
 
 Like I said, I'm skeptical, but listening. :)
 

While opinions differ on if we should 'ever' have more than 3 products, 
personally am very skeptical 
to the idea of product proliferation, I think that as a minimum common sense 
measure we should not even consider
any further products before we have the current 3 products released and our 
infrastructure updated to handle
them.

Christian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

[Christian Schaller]

- Original Message -
 From: Przemek Klosowski przemek.klosow...@nist.gov
 To: devel@lists.fedoraproject.org
 Sent: Friday, February 14, 2014 10:43:16 PM
 Subject: Re: Heads up; F22 will require applications to ship appdata to be
 listed in software center
 
 On 02/14/2014 01:41 PM, Adam Williamson wrote:
 
 
 
 On Fri, 2014-02-14 at 13:02 -0500, Przemek Klosowski wrote:
 
 
 
 On 01/28/2014 03:12 PM, Richard Hughes wrote:
 
 
 
 On 28 January 2014 18:43, Przemek Klosowski przemek.klosow...@nist.gov
 wrote:
 
 
 
 There are two separate issues here: 'abandonment', and 'GUIness'. As to the
 latter, I think it's a mistake to have a primary application installation
 tool that only deals with GUI apps, because it relegates text-based tools,
 such as 'units', to a second-class status of being hard to find and to
 install.
 That's not the tool we've designed and built. We've built a GUI
 application installer, not a package installer.
 While it's not the fault of the installer,  I am concerned about that
 distinction. For better or worse, a lot of useful tools seem to be out
 of scope for a 'GUI application installer'. GCC, perl, git, octave, R,
 units, mysql/sqlite3,  this kind of thing.
 Do you actually want to use a tool like Software to install gcc?
 
 I just can't see why you would. You know gcc is what you want. You don't
 need a shiny description and some screenshots and user reviews on a 1-5
 star scale. 'yum install gcc' seems a massively better fit. Who would it
 benefit to have something like gcc in Software?
 I see what you mean, but how do you install it, and other examples I
 provided? It's not just gcc:
 it's gcc-gfortran, gcc-arm, mingw64-gcc, msp430-gcc, etc.
 

Well with GCC we are assuming people will read docs and figure out the command
line parameters needed to use gcc. So expecting people to read the docs on how
to use yum or 'yum search' is not expecting to much in my opinion.

That said we should list the Developer Assistant in the Software center (or 
even have it installed by default)
and that should be the tool IMHO to install these and other developer tools.

Christian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.NEXT Products and the fate of Spins

[Christian Schaller]

The difference here is that the resources for GNOME (or anything else Red Hat 
needs for future versions of RHEL) are 
provided by Red Hat. So if you want the spins to the logically the same in 
terms of resources we should start demanding 
that any spin set up needs to provide an annual monetary contribution to help 
pay for the Fedora infrastructure and team.

Christian

- Original Message -
 From: Frank Murphy frankl...@gmail.com
 To: devel@lists.fedoraproject.org
 Sent: Thursday, January 30, 2014 9:06:24 AM
 Subject: Re: Fedora.NEXT Products and the fate of Spins
 
 On Wed, 29 Jan 2014 18:58:22 -0500
 Josh Boyer jwbo...@fedoraproject.org wrote:
 
  I consider myself squarely in the middle of those two camps.  I think
  they have value to people.  I think they fill a niche, however large
  or small it might be.  I also think they can be done by the people
  wishing to provide them without relying on Fedora resources for
  hosting and creation (outside of leveraging existing packages and
  repositories).
 
 That doesn't sound right,
 logically below would also be true.
 Gnome is a fairly big Spin,
 and can eat up quite a lot of resources.
 Maybe it should be outsourced.
 
 
 ___
 Regards,
 Frank
 www.frankly3d.com
 
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.NEXT Products and the fate of Spins

[Christian Schaller]

- Original Message -
 From: piruthiviraj natarajan piruthivi...@gmail.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Thursday, January 30, 2014 11:45:51 AM
 Subject: Re: Fedora.NEXT Products and the fate of Spins
 
 
 On Thu, Jan 30, 2014 at 4:10 PM, Christian Schaller  cscha...@redhat.com 
 wrote:
 
 
 
 The difference here is that the resources for GNOME (or anything else Red Hat
 needs for future versions of RHEL) are
 provided by Red Hat. So if you want the spins to the logically the same in
 terms of resources we should start demanding
 that any spin set up needs to provide an annual monetary contribution to help
 pay for the Fedora infrastructure and team.
 
 So you mean to say the software(already existing in the repos) which is not
 of interest for red hat should pay to stay for fedora infrastructure and
 Team to stay in the fedora repos?
 
 This looks like clear business motive and no point in calling it a community
 project at all.
 

What I mean to say is that Red Hat has a business motive to support the Fedora 
community,
if supporting Fedora was a pure act of charity then I think organizations like 
the Red Cross
or Unicef would have a much better chance of getting the money.

So if the Fedora community wants to not care about why Red Hat invests in 
Fedora they are of course free to do so,
but it becomes quite disingenuous to later be surprised if Red Hat loses 
interest in Fedora.

Christian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.NEXT Products and the fate of Spins

[Christian Schaller]

My statements was directly targeted at the often repeated attitude on this list 
which
seems to be that Red Hat should shut up and pay for whatever the given poster 
think should be payed
for without having any expectations or requirements of the Fedora community in 
return.

The relationship between Red Hat and Fedora is very different from that of for 
instance Debian and Ubuntu,
with Red Hat being a lot more directly involved in both contributing to Fedora 
and paying for the
general upkeep of Fedora. Personally I always felt that this symbiotic 
relationship was a big part of
what made Fedora interesting.

So in regards to the spins, which my original response didn't really try to 
address, I think they should all become remixes
and I think we should try to build an infrastructure where doing a remix is as 
easy as possible.
For example, in theory I think the Fedora project could provide some kind of 
web hosting space for the remixes, to reduce the burden/threshold
for remix maintainers, but I do also see that there are legal and 
administrative reasons for why that could be a bad idea, but I am sure that with
some discussion and investigation there are solutions that can be found to 
these practical challenges.


Christian


- Original Message -
 From: piruthiviraj natarajan piruthivi...@gmail.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Thursday, January 30, 2014 12:29:43 PM
 Subject: Re: Fedora.NEXT Products and the fate of Spins
 
 
 On Thu, Jan 30, 2014 at 4:21 PM, Christian Schaller  cscha...@redhat.com 
 wrote:
 
 
 
 What I mean to say is that Red Hat has a business motive to support the
 Fedora community,
 if supporting Fedora was a pure act of charity then I think organizations
 like the Red Cross
 or Unicef would have a much better chance of getting the money.
 
 So if the Fedora community wants to not care about why Red Hat invests in
 Fedora they are of course free to do so,
 but it becomes quite disingenuous to later be surprised if Red Hat loses
 interest in Fedora.
 
 well this kind of strategy towards the community is not very inspiring for
 the new contributors, is it?
 I think there is interest in the fedora community for Gnome as well as other
 DE which RHEL doesn't ship.
 But since this thread has been moving in a direction where the Fedora spins
 are under threat to exist in the repos doesn't bode well for the packages
 that is not of interest to red hat.
 
 
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.NEXT Products and the fate of Spins

[Christian Schaller]

- Original Message -
 From: Jaroslav Reznik jrez...@redhat.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Thursday, January 30, 2014 1:25:10 PM
 Subject: Re: Fedora.NEXT Products and the fate of Spins
 
 - Original Message -
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  Apologies for the slightly alarmist $SUBJECT, but I want to make sure
  that this gets read by the appropriate groups.
  
  During today's FESCo meeting, there was the start of a discussion on
  how to approve new Products into the Fedora family. As part of this,
  it naturally strayed into discussion of what we do about Spins as they
  currently exist.
  
  Several ideas were raised (which I'll go through below), but we didn't
  feel that this was something that FESCo should answer on its own. We'd
  prefer community input on how to handle spins going forward.
  
  So, in no particular order (because it's difficult to say which
  questions are the most important):
  
  1) Are Spins useful as they currently exist? There are many problems
  that have been noted in the Spins process, most notably that it is
  very difficult to get a Spin approved and then has no ongoing
  maintenance requiring it to remain functional. We've had Spins at
  times go through entire Fedora release cycles without ever being
  functional.
 
 Spins are useful especially as they makes our community inclusive,
 one thing we should be proud about (and sometimes it was harder, could
 cause issues but everything is solvable).
 
 For spins quality - it differs, it will differ but recent changes to
 process were for good, more updates are still needed. Long time ago
 we released what was build, I like how big step we did last few years.
 It's not reason it wasn't functional before to ban spins.
 
 If there's interest in spins like product, someone is willing to lead
 this effort, I think in some way, it can stay.
 
  2) Should Spins be eliminated entirely in favor of Fedora Remixes[1].
  The effect here would be that Spins are no longer an official part of
  The Fedora Project but are instead projects unto themselves which are
  permitted to consume (possibly large) portions of our tools, packages
  and ecosystem. Maintenance and upkeep of these spins then becomes
  entirely the responsibility of the downstream community that
  constructs them and has no mandatory draw on Fedora's marketing,
  ambassadors or quality assurance resources.
 
 It's possible but much more resource hungry. The way how spins are set
 helps these sub-projects deliver interesting piece of software.
 
 But there are two questions:
 - does every single spin makes sense as standalone spin? I really liked
 the idea of Fedora Formulas, it's exactly the way we should go. If for
 some reason formulas would not be enough for desired use case - remix.
 
 aka products + add-ons as formulas = spin
 
 For people who missed it https://fedoraproject.org/wiki/Fedora_formulas

Well I think this idea is interesting and we have discussed something along 
these
lines in the Workstation working group. I mean at the end of the day we all 
want as much 
software as possible packaged for Fedora/Product. The question to me lies in 
the details
of how this is done. For instance the idea we hope to explore are we develop 
the technical 
specification for the workstation is what kind of rules should apply to these 
potential
'formulas'. There are some obvious ones like, you can't for instance in a 
'formula' to  replace a package 
that would break the core product for instance due to replacing a version of a 
package with one that
got a different ABI. (This specific idea is quite well covered in existing 
Fedora guidelines, but I wanted to
avoid derailing this discussion by choosing an example that I hope would 
generate discussion in itself :)


 - or we could go even further and ask ourselves, do we want to call
 products Fedora? Or do we want products as remixes too? Based on
 underlying Fedora infrastructure? This could for example solve issues
 with our values - 3rd party repos etc.

Using the Fedora brand to only define a set of 'white box' packagesets is an 
option, 
but in some sense it means the end of 'Fedora' as a user facing brand.

  3) Should Spins be considered Products-in-development? In other words,
  should we only approve Spins that are targeted or destined for
  promotion to a fully-supported Fedora Product? This is a nuanced
  question, as it means different things for different Spins, for
  example Spins focusing on a target-audience (Security Spin, Design
  Suite Spin) vs. Spins focusing on a technology (LXDE Spin, MATE-Compiz
  Spin).
 
 For target audience spins, see above Formulas. And once we have this,
 I think spins as we know them right now could go then.
 
 I'd like to avoid calling LXDE/MATE other tech spins as products in
 development but we would have to product categories
 
 - Release blocking products
 - Non release 

Re: Fedora.NEXT Products and the fate of Spins

[Christian Schaller]

- Original Message -
 From: Jaroslav Reznik jrez...@redhat.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Thursday, January 30, 2014 1:34:45 PM
 Subject: Re: Fedora.NEXT Products and the fate of Spins
 
 - Original Message -
  My statements was directly targeted at the often repeated attitude on this
  list which
  seems to be that Red Hat should shut up and pay for whatever the given
  poster
  think should be payed
  for without having any expectations or requirements of the Fedora community
  in return.
  
  The relationship between Red Hat and Fedora is very different from that of
  for instance Debian and Ubuntu,
  with Red Hat being a lot more directly involved in both contributing to
  Fedora and paying for the
  general upkeep of Fedora. Personally I always felt that this symbiotic
  relationship was a big part of
  what made Fedora interesting.
 
 +1 and I still think it works pretty well - Red Hat has a nice space to
 do work on the future RHELs in open way (not like other so called open
 companies), community can contribute where there's interest.
 
 Btw. I'm not saying there are no issues, or sometimes more misunderstandings
 that always could be resolved.
 
  So in regards to the spins, which my original response didn't really try to
  address, I think they should all become remixes
  and I think we should try to build an infrastructure where doing a remix is
  as easy as possible.
  For example, in theory I think the Fedora project could provide some kind
  of
  web hosting space for the remixes, to reduce the burden/threshold
  for remix maintainers
 
 And we call these spins now.

Not exactly, to be clear what I was talking about here was fedora providing
hosting for someone to point their 'SuperDuperLinux.org' domain to. So that the
remixes wouldn't need to find separate web hosting. But as I think you also 
refer
to in your response, if we do that then there are probably similar legal 
restrictions
put on the remixes as are currently put on the spins.

 
  , but I do also see that there are legal and
  administrative reasons for why that could be a bad idea, but I am sure that
  with
  some discussion and investigation there are solutions that can be found to
  these practical challenges.
 
 That's one idea behind remixes - make it as easy as possible to remix Fedora
 outside of Fedora space to avoid legal issues.
 
 Jaroslav
 
  
  Christian
  
  
  - Original Message -
   From: piruthiviraj natarajan piruthivi...@gmail.com
   To: Development discussions related to Fedora
   devel@lists.fedoraproject.org
   Sent: Thursday, January 30, 2014 12:29:43 PM
   Subject: Re: Fedora.NEXT Products and the fate of Spins
   
   
   On Thu, Jan 30, 2014 at 4:21 PM, Christian Schaller  cscha...@redhat.com
   
   wrote:
   
   
   
   What I mean to say is that Red Hat has a business motive to support the
   Fedora community,
   if supporting Fedora was a pure act of charity then I think organizations
   like the Red Cross
   or Unicef would have a much better chance of getting the money.
   
   So if the Fedora community wants to not care about why Red Hat invests in
   Fedora they are of course free to do so,
   but it becomes quite disingenuous to later be surprised if Red Hat loses
   interest in Fedora.
   
   well this kind of strategy towards the community is not very inspiring
   for
   the new contributors, is it?
   I think there is interest in the fedora community for Gnome as well as
   other
   DE which RHEL doesn't ship.
   But since this thread has been moving in a direction where the Fedora
   spins
   are under threat to exist in the repos doesn't bode well for the packages
   that is not of interest to red hat.
   
   
   --
   devel mailing list
   devel@lists.fedoraproject.org
   https://admin.fedoraproject.org/mailman/listinfo/devel
   Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
  --
  devel mailing list
  devel@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/devel
  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.NEXT Products and the fate of Spins

[Christian Schaller]

I can do better, I can provide you with one of these people to look at.
If you send me your postal address I will send you a mirror :)

Christian

- Original Message -
 From: Jóhann B. Guðmundsson johan...@gmail.com
 To: devel@lists.fedoraproject.org
 Sent: Thursday, January 30, 2014 1:39:11 PM
 Subject: Re: Fedora.NEXT Products and the fate of Spins
 
 
 On 01/30/2014 12:08 PM, Christian Schaller wrote:
  My statements was directly targeted at the often repeated attitude on this
  list which
  seems to be that Red Hat should shut up and pay for whatever the given
  poster think should be payed
  for without having any expectations or requirements of the Fedora community
  in return.
 
 Care to reference to what you get at here in you futile attempt of
 damage control?
 
 By all means point me to the post and the places where our community
 members are demanding anything from Red Hat.
 
 JBG
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

[Christian Schaller]

Hi Frank,
They will, although in some sense I am the wrong person to ask this question as 
it
will be up to the people developing and packaging these DE's just like it is 
now.

The difference from today here though will be that there will be some 
requirements for being available
for the workstation as the PRD states. The main one here that I foresee is that 
you can't conflict in 
terms of library requirements or binary names with the standard desktop of the 
workstation. I don't think
that has been a big problem historically so it will likely have minimal impact, 
but it is now going to 
be a formal requirement as the PRD currently stands.

I expect there will be other requirements defined too, but I want to make it 
clear that the goals of 
these requirements is not to make it impossible or even hard to package 
alternative DEs for the workstation.
But what it will mean is that for instance it will be 100% clear that the 
responsibility to stay available rests on the 
alternative DEs packagers and developers and not on the core product 
developers. Of course with this also comes extra 
responsibility of the Workstation working group to ensure that development 
plans are shared as early as possible, to give 
everyone a chance to port over in time (ref. the recent Bluez discussion).

But it all comes back to what I mentioned in an earlier email. The 3 products 
is a attempt at moving from primarily packaging
upstream projects, to having concrete independent development targets for each 
product and to have engineers work on those 
independently of upstream priorities. So in some sense when people install 
alternative DEs that will to some degree mean that 
they are no longer using the Workstation as at least a subset of the features 
developed and announced as the big new features of a given 
release will not be available simply because they where features implemented or 
bugs fixed in the primary desktop. That is of course not
specific to the Workstation product. 

Christian


- Original Message -
 From: Frank Murphy frankl...@gmail.com
 To: devel@lists.fedoraproject.org
 Sent: Thursday, November 7, 2013 4:16:58 AM
 Subject: Re: Draft Product Description for Fedora Workstation
 
 On Fri, 01 Nov 2013 10:24:20 -0400
 Christian Fredrik Kalager Schaller cscha...@redhat.com wrote:
 
 Will the other DE's still exist after workstation
 Will a dev be able to use Xfce, Lxde as graphical choice.
 
 What would encourage say an xubuntu dev  //* devs are still users */
 working on foo, to switch to Fedora Workstation?
 
 
 --
 Regards,
 Frank
 www.frankly3d.com
 
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: unaccessability

[Christian Schaller]

Hi,
The core principle of the installer is that it operates on an application level 
and not a package level. The current way it determines if something is an 
application
 is by looking for a .desktop file. So in theory you could put a bitchx.desktop 
file  into the bitchx package and it would appear in the installer. That said I 
don't 
think it is generally a bad idea if command line/terminal applications are 
installed from the command line, but there is no hard policy blocking such 
applications from making themselves available in the installer.

Christian 

- Original Message -
From: Richard Vickery richard.vicker...@gmail.com
To: Development discussions related to Fedora 
devel@lists.fedoraproject.org, Community support for Fedora users 
us...@lists.fedoraproject.org
Sent: Thursday, November 7, 2013 12:13:25 PM
Subject: unaccessability

Is / was a rather political decision to make BitchX unavailable through this 
app-market / Software GUI thing? Since having to yum install it, I am beginning 
to have a negative feeling toward the app market idea; the thought being: what 
else is being left out? 

Regards, 
Richard 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: unaccessability

[Christian Schaller]

Well the installer is work in progress and there are a lot of features missing 
still, and
there are still questions that we need to figure out the answer to in terms of 
installing various things.

We are trying to nail down the core design first before adding support for 
'everything', 
but there will be the need for a .desktop file and an appdata file for anything 
that wants to be in.
Maybe long term we want to filter terminal applications into a separate 'tab' 
or similar, but regardless of 
long term presentation if you maintain a package with a terminal application 
and want it to show up in the installer 
the solution is to create a .desktop file and a appdata file for it.

Christian



- Original Message -
 From: Rahul Sundaram methe...@gmail.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Thursday, November 7, 2013 1:09:19 PM
 Subject: Re: unaccessability
 
 Hi
 
 
 On Thu, Nov 7, 2013 at 12:56 PM, Florian Müllner  fmuell...@gnome.org 
 wrote:
 
 
 
 
 I guess the main obstacle here is that there isn't really a good
 criterion which is as clear-cut as installs a (non-NoDisplay)
 .desktop file = this is a user-visible gui application for gui
 applications - mutt certainly is a user application, sshd clearly is
 not, zsh ... maybe?
 
 Why do you want to differentiate between Mutt and sshd? If a user wants to
 install a specific piece of software, they search for it within a gui and if
 it matches, they install it and move on. If you really need some way to
 differentiate, you can have some form of tagging via fedora tagger or
 appdata which you can include in more than just gui packages.
 
 When I want some software, say Epiphany and Mutt, if I can only use the
 installer for the Epiphany but I have to use yum for Mutt, I rather just use
 yum for both where I don't have to switch between two different ways of
 getting it. I don't mind the focus on gui applications but leaving out
 command line tools altogether forces me to think about whether say htop
 would be considered a application by the installer or not which is not the
 level I want to differentiate at all. When I search for something within the
 installer and it returns nothing, is it because there is genuinely nothing
 that matches what I want within the repositories or is the installer just
 excluding it based on implementation level details like desktop files and
 appdata? How would I know? It is just too complex.
 
 Rahul
 
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: unaccessability

[Christian Schaller]

Ok, so I guess the solution would be for the launcher to do something like this:

gnome-terminal --geometry 80x37 --disable-factory --role=bitchx --class=bitchx 
--name bitchX IRC --title BitchX IRC

That said Ray mentioned that this is probably not supported yet in the Shell 
launcher. 

Anyway, as Richard says, we should have a proper design discussion around this 
and not just add a ton of .desktop files without thinking through the 
presentation
and how it will work. But feel free to file some bug reports to kick of a 
discussion.

Christian

- Original Message -
From: Richard Hughes hughsi...@gmail.com
To: Development discussions related to Fedora devel@lists.fedoraproject.org
Sent: Thursday, November 7, 2013 4:02:07 PM
Subject: Re: unaccessability




On 7 Nov 2013 17:13, Richard Vickery  richard.vicker...@gmail.com  wrote 
 Is / was a rather political decision to make BitchX unavailable through this 
 app-market / Software GUI thing? 

How do you launch bitchx from gnome-shell? If it's just a random binary without 
any desktop or appdata file, it isn't an application as far as gnome-software 
is concerned. If that needs to change, it needs to be discussed and properly 
designed in #gnome-design. 

Richard 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Workstation PRD summary and next steps

[Christian Schaller]

Hi everyone,
So on behalf of the Workstation Working Group I would like to say thank you to 
everyone who has taken the time so far to chime in. There has been a lot of 
passionate discussion happening
and that is the way we like it. So while we might not have been able to respond 
to each and every message, myself and the other working group members have read 
every message sent so far.

We will now take that feedback with us into the next working group meeting and 
come up with a second PRD draft, trying to incorporate the suggestions we have 
gotten so far when possible.

The next update of the PRD will be posted to the fedora-desktop list as that is 
the designated 'home' of the working group and product and we want to avoid 
cluttering up the general 
Fedora-devel list with product specific further discussion. The other product 
working groups have mostly kept themselves to their own mailing list so we will 
try to do the same, and leave the
general devel list to the -base group.

Also for those of you who might end up feeling that the updated PRD do not 
address you raised concerns, all I can say is that we do take all feedback 
seriously, and will try to keep the points 
made in mind as we go forward, but of course there is no perfect solutions here 
that will make absolutely everyone 110% content.

Christian


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

[Christian Schaller]

SNIP
  So sure, we can have software that will pull things in if the user has
  done some manual intervention.  We just cant, currently, do that thing
  for them.
 
  Right, that's exactly what I was saying. I just think this is all the
  _original poster_ was talking about, not any kind of automatic
  configuration of such repositories. (Or at least, you can read it that
  way).
 
 OK.  I guess that's fine, but it seems like a non-goal to me.  I mean,
 it already works that way.  All adding it to the PRD would do would
 make an easy thing to check off the list as met.

I suppose we should go back to the OP and ask for clarification of
exactly what the idea was, at this point :)

So there are 3 different cases here

1) Packaging non-free/semi-free software in Fedora - I don't think anyone is 
advocating that - ref recent openh264 thread
2) Enabling 3rd party repositories with packages that have an unclear legal 
status is major jurisdictions - This is not what the PRD was referring too, and 
we have a solution for that already
3) Easily enabling 3rd party repositories containing software that is without 
any legal uncertainty, but which contains software which might not meet the 
Fedora guidelines for stuff we would include.

So it is item 3 that the PRD is addressing. An example here would be Google 
Chrome. Google provides a yum repo for Google Chrome for Fedora and Google 
stands behind Chrome legally, so if they also do the work of putting in an 
appdata file there we should figure out a simple way for users to install 
Chrome from the GNOME Software application. The exact details of how we do that 
enablement can and should be discussed, but it should be something simpler than 
how we currently enable the (2) option, yet at the same time we probably don't 
want to give them equal billing to the Fedora packaged and 100% open source 
stuff we make available in the Fedora repository.

As a sidenote, as we delve into the details a bit more here maybe it is time to 
move these discussions to the product specific mailing list to not spam the 
general devel list?

Christian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

[Christian Schaller]

SNIP
  I would actually like to go a little further, and make it easy to enable
  'clean' third-party repositories. If we imagine a future where e.g.
  valve is hosting a repository with their steam client, or say, the
  chromium web browser is available from the a fedora people page, I would
  really like it if searching for 'steam' or 'chromium' in gnome-software
  would bring up a text that said something like: The software you are
  looking for is available from a third-party repository. Do you want to
  enable it ?
 
 That was how I understood the original proposal.  And that's the
 conversation that needs to happen at a higher level outside of the WG
 before it can really be a reality.
 
I don't think we need to push these decisions to be Fedora generic. There is no 
reason 
why the 3 products can't have different rule sets. Just because a policy would 
work
for the cloud image for instance doesn't mean it is the right one for the 
Workstation and vice versa.

Christian


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

[Christian Schaller]

The term 'Power user' is not meaningless if you use it to refer to users of
Fedora on IBM Power architecture ;)

But apart from that I do agree that the term as generally used doesn't provide 
a very clear target for development.

Christian


- Original Message -
 From: drago01 drag...@gmail.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Tuesday, November 5, 2013 6:53:15 AM
 Subject: Re: Draft Product Description for Fedora Workstation
 
 On Tue, Nov 5, 2013 at 12:35 PM, Nicolas Mailhot
 nicolas.mail...@laposte.net wrote:
 
  Le Lun 4 novembre 2013 23:02, Nicolas Mailhot a écrit :
 
  The problem is not to get code in the hands of developers. You don't need
  distros for that. The problem is to get the code to end-users and
  developers spend more time fighting the constrains it involves than trying
  to understand this problem-space.
 
  Of course the aim might not be to reach end users but to push code from
  developpers to other developers.
 
  And if that is the case, there is a huge disconnect between GNOME goals
  and Fedora Workstation goals. GNOME speakers repeat all year round their
  software is not aimed at power users, but developers are the über power
  user.
 
 Depends on what you mean by power user (I hate this meaningless
 term) if it means software developer then
 yes. If it means someone that spends his whole day in config dialogs then
 no.
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

[Christian Schaller]

Hi Ryan,
I been discussing the possibilities of doing some surveys with Langdon White, 
so hopefully yes.
We just need to rustle up the budget first :)

Christian

- Original Message -
From: Ryan Lerch rle...@redhat.com
To: Discussions about development for the Fedora desktop 
desk...@lists.fedoraproject.org, devel@lists.fedoraproject.org
Sent: Monday, November 4, 2013 11:14:21 AM
Subject: Re: Draft Product Description for Fedora Workstation

On 01/11/13 10:24, Christian Fredrik Kalager Schaller wrote: 



Hi everyone,
Attached is the draft PRD for the Workstation working group. The
proposal tries to be relatively high level and focus on goals and
principles, but I have included some concrete examples at times to try
to provide some clarity on how the goals and principles could play out
in practice.

I hope the community at large will take the time to read through it and
provide feedback so that when the working group meet next we can use
that feedback to start tuning in on the final form of the PRD.

Also in the name of openness, before I sent this here, I showed the PRD
draft to key stakeholders and decision makers inside Red Hat, to ensure
that we have the necessary support for these plans to get the kind of
engineering resources allocated from Red Hat we will need to pull this
off. 

Sincerely,
Christian F.K. Schaller

P.S. I am celebrating both our wedding anniversary and my wifes birthday
this weekend so I will not be able to be online a lot. That said I will
make the time to go online to check my email from time to time so that I
can respond to any questions that has come in, just don't expect
immediate answers from me this weekend :) 


Although i am not sure if the PRD is the place for it, But should we also think 
about conducting 
some user surveys to help define our target audience further? Also, some User 
testing on what 
we have already would also be useful for a baseline to check against in the 
future when we start 
implementing changes. 

cheers, 
ryanlerch 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

[Christian Schaller]

- Original Message -
SNIP
 
  It looks like it is designed only for developers by developers.
 
  What about graphic designers, musicians, document writers, etc.? They
  all are not mentioned as target audience.
 
 Per this document, those would fall into the Other users section.
 
 The software for much of those use cases is available in the wider
 Fedora repository, so one could install them if needed.
 
 josh
 --

In general I hope to see a lot of users of the workstation product, including 
the almost cliché usecase of the 'grandparents'.
Focusing on a specific set of usecases doesn't need to mean we should actively 
make the product unattractive to anyone else. 
A lot of the core things we need to get right is equally important to almost 
any type of user we can think of, I mean regardless
of if you are what we call a technical user or close to a computer illiterate 
you are very likely to prefer an operating system 
that doesn't crash over one that does, to make a very obvious example.

But what having these usecases here mean is that they do become an active tool 
for development prioritisation and to some degree packaging
prioritization and I think that will likely end up being the biggest change 
that these new products enact in Fedora.

Red Hat's contribution to Fedora is getting re-focused as part of this and 
these PRDs are meant to be a tool that managers such as myself 
will use to help prioritize what we focus our development resources on. So lets 
say I had to prioritize development time between improving 
terminal stacking for developers or polishing the GNOME Shell teatime extension 
to make sure our grandparent users get optimal tea. 
The PRD makes it clear that focus should go on terminal stacking. (Ok, a silly 
example, but hopefully still useful as an explanation :)

So just like all the other distributions out there we should as a community 
continue to try to have as many applications as possible available 
for our users, but the PRD should talk to where we are going to put resources 
intro trying to differentiate and be the leader. And every usecase
we add means we dilute our efforts a little more and thus make it less likely 
we achieve the goal. 

Of course once we succeed with our initial goals we should revisit the PRDs and 
see if there are new groups or areas we can and should target 
to continue growing without risking losing the gains we made.

Christian


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

[Christian Schaller]

Hi Bill,
It is a good question. It does seem a bit more detailed than the level I tried 
to put this document on, so
maybe should a style guide would be part of second stage working group output. 
But what probably would belong in this 
document would be a paragraph saying we intend to come up with such a 
sub-document.

Christian

- Original Message -
From: Bill Nottingham nott...@redhat.com
To: Development discussions related to Fedora devel@lists.fedoraproject.org
Cc: desk...@lists.fedoraproject.org
Sent: Friday, November 1, 2013 2:43:37 PM
Subject: Re: Draft Product Description for Fedora Workstation

Christian Fredrik Kalager Schaller (cscha...@redhat.com) said: 
 Hi everyone,
 Attached is the draft PRD for the Workstation working group. The
 proposal tries to be relatively high level and focus on goals and
 principles, but I have included some concrete examples at times to try
 to provide some clarity on how the goals and principles could play out
 in practice.
 
 I hope the community at large will take the time to read through it and
 provide feedback so that when the working group meet next we can use
 that feedback to start tuning in on the final form of the PRD.
 
 Also in the name of openness, before I sent this here, I showed the PRD
 draft to key stakeholders and decision makers inside Red Hat, to ensure
 that we have the necessary support for these plans to get the kind of
 engineering resources allocated from Red Hat we will need to pull this
 off. 

Something that doesn't seem specified here is any sort of a design style or
guide for how apps used in the Workstation should generally be built and
function.  Is there intended to be that sort of standard?

Bill
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

[Christian Schaller]

The PRD avoids these questions by design. To often open source discussions end 
up
being discussions about the merits of the means as opposed to the actual goals.

It should be a sobering notion that for all the years when the community 
discussed
if the a successful desktop should be implemented in C or C++ we ended up 
having our 
collective thunder stolen by a desktop written in Objective-C. There are some 
lessons
to be learned from that (and to be clear I don't think the lesson is that 
Objective-C is
a 'better' language).

So while of course there does come a point for drilling down into 
implementation detail,
the suggestion I got from various FeSCO members, and which I thought very 
sensible,
 was to avoid that being the starting point.

Christian


- Original Message -
 From: Kevin Kofler kevin.kof...@chello.at
 To: devel@lists.fedoraproject.org
 Sent: Saturday, November 2, 2013 1:14:15 PM
 Subject: Re: Draft Product Description for Fedora Workstation
 
 Bill Nottingham wrote:
  Something that doesn't seem specified here is any sort of a design style
  or guide for how apps used in the Workstation should generally be built
  and function.  Is there intended to be that sort of standard?
 
 Indeed, the document carefully eschews this question, which goes hand in
 hand with the question of WHAT desktop environment(s) the Workstation is
 supposed to include. If the goal is (and I think it should be, because
 that's what users expect) a traditional desktop with a panel (containing at
 least the standard items: menu button, task bar, system tray, digital
 clock), a menu (popping up from the menu button in the panel), and a desktop
 displaying the xdg-user-dir for DESKTOP in some place (spread over the
 entire desktop or in a widget, Plasma can do either as desired), then it is
 clear that gnome-shell does NOT qualify.
 
 Kevin Kofler
 
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

[Christian Schaller]

Funnily enough I had a discussion last week where it turned out the
disagreement wasn't so much a disagreement, but a different contextualisation 
of the word 'support'.

And I think that will be the crux here too. To me the main part of 'supporting'
something here will be in handling our ABI story better, not about writing 
custom 
work arounds for various 3rd party software.

There are of course many aspects to the ABI story, but one technology I think 
will be 
an important part of improving this is the LinuxApps proposal from Lennart 
Poettering.
He did a talk about it at GUADEC which you can find here:
http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome

(The talk is not only about ABI for applications, but it is part of the talk, 
and despite the talk title
it is not GNOME specific in any way.)

Christian

- Original Message -
 From: Kevin Kofler kevin.kof...@chello.at
 To: devel@lists.fedoraproject.org
 Sent: Saturday, November 2, 2013 12:20:30 PM
 Subject: Re: Draft Product Description for Fedora Workstation
 
 Christian Fredrik Kalager Schaller wrote:
  Attached is the draft PRD for the Workstation working group.
 
 Quoting from the draft:
  Ability to play 3D games from commercial publishers distributing games for
  Linux
 and later:
  3rd party software
  Fedora Workstation will work with partners and ISVs to ensure that their
  software can be easily installed on the system after installation.  This
  work will for instance include working with for instance hardware partners
  to ensure users can install needed drivers directly from these vendors.
  Fedora will not include any non-free software by default or host any non-
  free software in our repositories.
 
 I think it is a very bad idea to try to explicitly and officially support
 third-party software, especially proprietary third-party software. We have
 no control over that software, its quality, the obsolete APIs and ABIs it
 uses etc. Supporting them officially:
 * puts us in a position where we need to try to fix issues with software we
   cannot actually fix,
 * opens the door to really crappy workarounds degrading the quality of
   Fedora (and possibly negatively affecting other applications, even our
   own) just to make some proprietary program work (e.g., just look at all
   the ugly make Flash work workarounds that have been shipped by various
   distributions and upstreams),
 * may require shipping loads of compatibility libraries (with old sonames)
   that nothing in Fedora would need (e.g., do you really want to install qt3
   by default? The current LSB 4.1 still requires it, next to Qt 4 which is
   also in the process of becoming legacy. And some other legacy libraries
   that proprietary software requires would not even have to be packaged
   otherwise),
 * may lock us into outdated versions of core software (kernel, X11 etc.)
   just so some third-party driver (or even application, but the drivers are
   routine offenders) keeps working, defeating one of Fedora's strongest
   points (being First) and making it worse (also by delaying Features) for
   everyone who does NOT use the offending third-party driver(s).
 
 Kevin Kofler
 
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct