Draft Product Description for Fedora Workstation

[Christian Schaller]

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 :)

[Markus Mayer]

On 11/01/2013 03:24 PM, 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 :)
>
>
>  
Hi Christian,

thank you for writting up the product description.

Here are some things that came to my mind while reading it:

- What about watching films, listening to music? I think it is a basic 
requirement for students (at least for me).

Maybe we should add a that a student should be able to play videos and 
listen to music. It should be easy to install required codes 
(free/nonfree/patente) if they are available in the repositories (yes, I 
mean rpmfusion)

- You often refere to 'development environment with the latest web 
development tools'.

Is there a reaseon why 'web development tools' are listed seperatly? 
What about C/C++ development tools? Are they just 2nd grade tools?

Am I assuming correctly that 'development environment' includes IDEs, 
SCM-Systems, editors, ...?

- Maybe we should add a statement, that it should be easy to install/use 
server components on a workstation install. Many developers need server 
components to test their code


Regards

Markus

[Josh Boyer]

On Fri, Nov 1, 2013 at 11:15 AM, Markus Mayer <lotharlutz(a)gmx.de&gt; wrote:
>  On 11/01/2013 03:24 PM, 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 :)
> >
> >
> >
>
>  Hi Christian,
>
>  thank you for writting up the product description.
>
>  Here are some things that came to my mind while reading it:
>
>  - What about watching films, listening to music? I think it is a basic
>  requirement for students (at least for me).
>
>  Maybe we should add a that a student should be able to play videos and
>  listen to music. It should be easy to install required codes
>  (free/nonfree/patente) if they are available in the repositories (yes, I
>  mean rpmfusion) 
This would require approval beyond the WG, as it goes against Fedora's
policies.  Note, I am not saying you are incorrect, just that it's a
conversation to be had elsewhere first.

>  - You often refere to 'development environment with the latest
> web
>  development tools'.
>
>  Is there a reaseon why 'web development tools' are listed seperatly? What
>  about C/C++ development tools? Are they just 2nd grade tools? 
No, but they're already implicitly included considering every possible
DE used for the base of Workstation requires them to build.  They also
aren't nearly as rapidly released as other tools.

>  Am I assuming correctly that 'development environment'
> includes IDEs,
>  SCM-Systems, editors, ...? 
The actual specifics of the software installed aren't covered in this document.

>  - Maybe we should add a statement, that it should be easy to
> install/use
>  server components on a workstation install. Many developers need server
>  components to test their code 
Can't they can install the Fedora Server product in a virtual machine?
 This document already explicitly mentions easy to configure virtual
machines as a goal.  Trying to come up with something specifically
scoped while saying "oh, but you should also be able to morph it into
something else" isn't going to lead to a well defined product.  That
isn't to say it isn't possible, or that it can't be done, but it isn't
necessarily a use case either.

josh

[Kevin Kofler]

Josh Boyer wrote:

>  On Fri, Nov 1, 2013 at 11:15 AM, Markus Mayer
> <lotharlutz(a)gmx.de&gt; wrote:
> > Is there a reaseon why 'web development tools' are listed seperatly? What
> > about C/C++ development tools? Are they just 2nd grade tools?
>  
>  No, but they're already implicitly included considering every possible
>  DE used for the base of Workstation requires them to build.  They also
>  aren't nearly as rapidly released as other tools. 
The stuff required to build things is only a subset of the tools needed to 
actually develop them. As Markus writes:

> > Am I assuming correctly that 'development environment'
> includes IDEs,
> > SCM-Systems, editors, ...? 
All that stuff is not required for mere builds, but developers will most 
definitely expect it.

For example, a KDE Platform 4 build environment includes:
g++
cmake
qt(4)-devel
kdelibs(4)-devel
and possibly kde-workspace-devel and the like, and that's all.

A KDE Platform 4 DEVELOPMENT environment, on the other hand, includes all 
that plus at least KDevelop (and its dependencies, which include git). Some 
users may also expect Qt Creator, KDbg (standalone GDB frontend), Valgrind 
(with or without the Alleyoop GTK+/GNOME GUI), KCachegrind, standalone git 
GUI frontends (git-cola, qgit), Kdesvn, offline API documentation (qt-doc, 
kdelibs-apidocs, …) etc. (And that does not even include tools for 
translations etc.)

>  Trying to come up with something specifically scoped while saying
> "oh, but
>  you should also be able to morph it into something else" isn't going to
>  lead to a well defined product. 
That's one of the biggest flaws with the Products approach. Fedora used to 
be a consistent and flexible product where you could mix and match whatever 
you wanted, it was all in the same repository and working well together. You 
sound as if it were unreasonable to expect this in the future.

IMHO, the Spins were actually a better approach than this new Products idea.

        Kevin Kofler

[Adam Williamson]

On Fri, 2013-11-01 at 14:22 -0400, Josh Boyer wrote:

>  > - What about watching films, listening to music? I think it is a
> basic
>  > requirement for students (at least for me).
>  >
>  > Maybe we should add a that a student should be able to play videos and
>  > listen to music. It should be easy to install required codes
>  > (free/nonfree/patente) if they are available in the repositories (yes, I
>  > mean rpmfusion)
>  
>  This would require approval beyond the WG, as it goes against Fedora's
>  policies.  Note, I am not saying you are incorrect, just that it's a
>  conversation to be had elsewhere first. 
Ensuring that it's possible/easy to install plugins from third party
repositories when appropriate if those third party repositories are
defined is not, I don't believe, against any policies, or we could not
have the automatic codec installation mechanisms in Totem and Rhythmbox.
(Which, as I read it, is the kind of thing this comment was about).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Josh Boyer]

On Tue, Nov 5, 2013 at 2:58 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  On Fri, 2013-11-01 at 14:22 -0400, Josh Boyer wrote:
>
> > > - What about watching films, listening to music? I think it is a basic
> > > requirement for students (at least for me).
> > >
> > > Maybe we should add a that a student should be able to play videos and
> > > listen to music. It should be easy to install required codes
> > > (free/nonfree/patente) if they are available in the repositories (yes, I
> > > mean rpmfusion)
> >
> > This would require approval beyond the WG, as it goes against Fedora's
> > policies.  Note, I am not saying you are incorrect, just that it's a
> > conversation to be had elsewhere first.
>
>  Ensuring that it's possible/easy to install plugins from third party
>  repositories when appropriate if those third party repositories are
>  defined is not, I don't believe, against any policies, or we could not
>  have the automatic codec installation mechanisms in Totem and Rhythmbox.
>  (Which, as I read it, is the kind of thing this comment was about). 
The codec search only works if you have repositories configured that
have packages that match the Provides (as far as I understand).
Fedora policy says that we do not promote or install such
repositories.  This is the "don't talk about RPMFusion" rule.

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.

josh

[drago01]

On Tue, Nov 5, 2013 at 9:23 PM, Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:
>  On Tue, Nov 5, 2013 at 2:58 PM, Adam Williamson
> <awilliam(a)redhat.com&gt; wrote:
> > On Fri, 2013-11-01 at 14:22 -0400, Josh Boyer wrote:
> >
> >> > - What about watching films, listening to music? I think it is a basic
> >> > requirement for students (at least for me).
> >> >
> >> > Maybe we should add a that a student should be able to play videos and
> >> > listen to music. It should be easy to install required codes
> >> > (free/nonfree/patente) if they are available in the repositories (yes, I
> >> > mean rpmfusion)
> >>
> >> This would require approval beyond the WG, as it goes against Fedora's
> >> policies.  Note, I am not saying you are incorrect, just that it's a
> >> conversation to be had elsewhere first.
> >
> > Ensuring that it's possible/easy to install plugins from third party
> > repositories when appropriate if those third party repositories are
> > defined is not, I don't believe, against any policies, or we could not
> > have the automatic codec installation mechanisms in Totem and Rhythmbox.
> > (Which, as I read it, is the kind of thing this comment was about).
>
>  The codec search only works if you have repositories configured that
>  have packages that match the Provides (as far as I understand).
>  Fedora policy says that we do not promote or install such
>  repositories.  This is the "don't talk about RPMFusion" rule. 
And I still think this kind of "censorship" is a bit to paranoid but IANAL.

[Adam Williamson]

On Tue, 2013-11-05 at 15:23 -0500, Josh Boyer wrote:
>  On Tue, Nov 5, 2013 at 2:58 PM, Adam Williamson
> <awilliam(a)redhat.com&gt; wrote:
>  > On Fri, 2013-11-01 at 14:22 -0400, Josh Boyer wrote:
>  >
>  >> > - What about watching films, listening to music? I think it is a basic
>  >> > requirement for students (at least for me).
>  >> >
>  >> > Maybe we should add a that a student should be able to play videos and
>  >> > listen to music. It should be easy to install required codes
>  >> > (free/nonfree/patente) if they are available in the repositories (yes, I
>  >> > mean rpmfusion)
>  >>
>  >> This would require approval beyond the WG, as it goes against Fedora's
>  >> policies.  Note, I am not saying you are incorrect, just that it's a
>  >> conversation to be had elsewhere first.
>  >
>  > Ensuring that it's possible/easy to install plugins from third party
>  > repositories when appropriate if those third party repositories are
>  > defined is not, I don't believe, against any policies, or we could not
>  > have the automatic codec installation mechanisms in Totem and Rhythmbox.
>  > (Which, as I read it, is the kind of thing this comment was about).
>  
>  The codec search only works if you have repositories configured that
>  have packages that match the Provides (as far as I understand).
>  Fedora policy says that we do not promote or install such
>  repositories.  This is the "don't talk about RPMFusion" rule.
>  
>  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).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Josh Boyer]

On Tue, Nov 5, 2013 at 4:29 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  On Tue, 2013-11-05 at 15:23 -0500, Josh Boyer wrote:
> > On Tue, Nov 5, 2013 at 2:58 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
> > > On Fri, 2013-11-01 at 14:22 -0400, Josh Boyer wrote:
> > >
> > >> > - What about watching films, listening to music? I think it is a basic
> > >> > requirement for students (at least for me).
> > >> >
> > >> > Maybe we should add a that a student should be able to play videos and
> > >> > listen to music. It should be easy to install required codes
> > >> > (free/nonfree/patente) if they are available in the repositories (yes,
> I
> > >> > mean rpmfusion)
> > >>
> > >> This would require approval beyond the WG, as it goes against Fedora's
> > >> policies.  Note, I am not saying you are incorrect, just that it's a
> > >> conversation to be had elsewhere first.
> > >
> > > Ensuring that it's possible/easy to install plugins from third party
> > > repositories when appropriate if those third party repositories are
> > > defined is not, I don't believe, against any policies, or we could not
> > > have the automatic codec installation mechanisms in Totem and Rhythmbox.
> > > (Which, as I read it, is the kind of thing this comment was about).
> >
> > The codec search only works if you have repositories configured that
> > have packages that match the Provides (as far as I understand).
> > Fedora policy says that we do not promote or install such
> > repositories.  This is the "don't talk about RPMFusion" rule.
> >
> > 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".

josh

[Adam Williamson]

On Tue, 2013-11-05 at 16:32 -0500, Josh Boyer wrote:
>  On Tue, Nov 5, 2013 at 4:29 PM, Adam Williamson
> <awilliam(a)redhat.com&gt; wrote:
>  > On Tue, 2013-11-05 at 15:23 -0500, Josh Boyer wrote:
>  >> On Tue, Nov 5, 2013 at 2:58 PM, Adam Williamson <awilliam(a)redhat.com&gt;
> wrote:
>  >> > On Fri, 2013-11-01 at 14:22 -0400, Josh Boyer wrote:
>  >> >
>  >> >> > - What about watching films, listening to music? I think it is a
> basic
>  >> >> > requirement for students (at least for me).
>  >> >> >
>  >> >> > Maybe we should add a that a student should be able to play videos
> and
>  >> >> > listen to music. It should be easy to install required codes
>  >> >> > (free/nonfree/patente) if they are available in the repositories
> (yes, I
>  >> >> > mean rpmfusion)
>  >> >>
>  >> >> This would require approval beyond the WG, as it goes against
> Fedora's
>  >> >> policies.  Note, I am not saying you are incorrect, just that it's
> a
>  >> >> conversation to be had elsewhere first.
>  >> >
>  >> > Ensuring that it's possible/easy to install plugins from third party
>  >> > repositories when appropriate if those third party repositories are
>  >> > defined is not, I don't believe, against any policies, or we could not
>  >> > have the automatic codec installation mechanisms in Totem and Rhythmbox.
>  >> > (Which, as I read it, is the kind of thing this comment was about).
>  >>
>  >> The codec search only works if you have repositories configured that
>  >> have packages that match the Provides (as far as I understand).
>  >> Fedora policy says that we do not promote or install such
>  >> repositories.  This is the "don't talk about RPMFusion" rule.
>  >>
>  >> 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 :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[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

[Richard Hughes]

On 6 November 2013 15:14, Christian Schaller <cschalle(a)redhat.com&gt; wrote:
>  so if they also do the work of putting in an appdata file there...
Note, we can easily ship a google-chrome.appdata.xml file in the
fedora-appstream project. This has a quite a few appdata files for
important applications that are awaiting upstream releases. If you
want me to add one that points to a specific HTML page ["how to enable
the repo"] when clicked on, just yell.

Richard.

[Kevin Kofler]

Christian Schaller wrote:
>  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, 
Why? IMHO, getting proprietary crap (3) should definitely NOT be easier than 
getting Free stuff we won't ship (2). I understand why we don't make (2) any 
easier, but that just means (3) should not get any easier either.

        Kevin Kofler

[Markus Mayer]

On 11/05/2013 10:33 PM, Adam Williamson wrote:
>  On Tue, 2013-11-05 at 16:32 -0500, Josh Boyer wrote:
> > On Tue, Nov 5, 2013 at 4:29 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
> >> On Tue, 2013-11-05 at 15:23 -0500, Josh Boyer wrote:
> >>> On Tue, Nov 5, 2013 at 2:58 PM, Adam Williamson <awilliam(a)redhat.com&gt;
> wrote:
> >>>> On Fri, 2013-11-01 at 14:22 -0400, Josh Boyer wrote:
> >>>>
> >>>>>> - What about watching films, listening to music? I think it is a
> basic
> >>>>>> requirement for students (at least for me).
> >>>>>>
> >>>>>> Maybe we should add a that a student should be able to play
> videos and
> >>>>>> listen to music. It should be easy to install required codes
> >>>>>> (free/nonfree/patente) if they are available in the repositories
> (yes, I
> >>>>>> mean rpmfusion)
> >>>>>
> >>>>> This would require approval beyond the WG, as it goes against
> Fedora's
> >>>>> policies.  Note, I am not saying you are incorrect, just that
> it's a
> >>>>> conversation to be had elsewhere first.
> >>>>
> >>>> Ensuring that it's possible/easy to install plugins from third party
> >>>> repositories when appropriate if those third party repositories are
> >>>> defined is not, I don't believe, against any policies, or we could
> not
> >>>> have the automatic codec installation mechanisms in Totem and Rhythmbox.
> >>>> (Which, as I read it, is the kind of thing this comment was about).
> >>>
> >>> The codec search only works if you have repositories configured that
> >>> have packages that match the Provides (as far as I understand).
> >>> Fedora policy says that we do not promote or install such
> >>> repositories.  This is the "don't talk about RPMFusion" rule.
> >>>
> >>> 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 :)
>  
All I was asking for is the status quo. 3rd party repositories must be 
installed manually, but once they are installed automated codec 
installation should work.

[Matthias Clasen]

On Tue, 2013-11-05 at 16:32 -0500, Josh Boyer wrote:

>  > 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 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 ?

Matthias

[Kevin Kofler]

Matthias Clasen wrote:
>  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 ? 
I think users will not understand why all the vendor repositories with non-
free crap are there and the stuff they are actually looking for is not.

        Kevin Kofler

[Olav Vitters]

On Wed, Nov 06, 2013 at 12:35:59AM +0100, Kevin Kofler wrote:
>  I think users will not understand why all the vendor repositories
> with non-
>  free crap are there and the stuff they are actually looking for is not. 
Whether or not proprietary is crap or not is offtopic.

-- 
Regards,
Olav

[Josh Boyer]

On Tue, Nov 5, 2013 at 5:02 PM, Matthias Clasen <mclasen(a)redhat.com&gt; wrote:
>  On Tue, 2013-11-05 at 16:32 -0500, Josh Boyer wrote:
>
> > > 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 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.

josh

[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

[Josh Boyer]

On Wed, Nov 6, 2013 at 10:19 AM, Christian Schaller <cschalle(a)redhat.com&gt; wrote:
>  <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. 
I don't think we need to force the same policy across all 3 products.
I DO think we need to discuss adjusting the policy with the people
that set the current policy though.  That would be FESCo and the
Board.  I'm going to guess they have reasons for not allowing third
party repositories to be automatically installed/enabled for reasons
and they oversee the WGs, so bringing it up with them is the correct
thing to do.

I'd be happy to open a FESCo ticket to discuss this.

josh

[Josh Boyer]

On Wed, Nov 6, 2013 at 10:26 AM, Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:
>  On Wed, Nov 6, 2013 at 10:19 AM, Christian Schaller
> <cschalle(a)redhat.com&gt; wrote:
> > <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.
>
>  I don't think we need to force the same policy across all 3 products.
>  I DO think we need to discuss adjusting the policy with the people
>  that set the current policy though.  That would be FESCo and the
>  Board.  I'm going to guess they have reasons for not allowing third
>  party repositories to be automatically installed/enabled for reasons
>  and they oversee the WGs, so bringing it up with them is the correct
>  thing to do.
>
>  I'd be happy to open a FESCo ticket to discuss this. 
https://fedorahosted.org/fesco/ticket/1195

josh

[Kevin Kofler]

Josh Boyer wrote:
>  I don't think we need to force the same policy across all 3
> products.
>  I DO think we need to discuss adjusting the policy with the people
>  that set the current policy though.  That would be FESCo and the
>  Board.  I'm going to guess they have reasons for not allowing third
>  party repositories to be automatically installed/enabled for reasons
>  and they oversee the WGs, so bringing it up with them is the correct
>  thing to do. 
Having a list of third-party repositories which does not include RPM Fusion 
is just a really bad joke, beyond useless. If we can't include RPM Fusion 
(and Livna) in the list, it's better to not have such a list at all and let 
users find the real, complete list on their own.

        Kevin Kofler

[Markus Mayer]

On 11/01/2013 03:24 PM, 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 :)
>
>
>  
And here comes the next tought...

A small business developer, will also need (at least twice a year) basic 
image processing. Creating Icons, placeholder graphics...

[drago01]

On Fri, Nov 1, 2013 at 4:25 PM, Markus Mayer <lotharlutz(a)gmx.de&gt; wrote:
>  On 11/01/2013 03:24 PM, 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 :)
> >
> >
> >
>
>  And here comes the next tought...
>
>  A small business developer, will also need (at least twice a year) basic
>  image processing. Creating Icons, placeholder graphics... 
Well I don't think we can / should list every possible use case in the
document. Some examples to show the overall direction should be enough
imo.

[Mateusz Marzantowicz]

On 01.11.2013 15: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. 
>   
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.



Mateusz Marzantowicz

[Josh Boyer]

On Fri, Nov 1, 2013 at 12:35 PM, Mateusz Marzantowicz
<mmarzantowicz(a)osdf.com.pl&gt; wrote:
>  On 01.11.2013 15: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.
> >
>
>  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

[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

[Mateusz Marzantowicz]

On 01.11.2013 19:15, Josh Boyer wrote:
>  On Fri, Nov 1, 2013 at 12:35 PM, Mateusz Marzantowicz
>  <mmarzantowicz(a)osdf.com.pl&gt; wrote:
> > On 01.11.2013 15: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.
> >>
> >
> > 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.
>   
Is it wise to put 90% of use cases in "other users" section? Maybe I
don't understand intention of this document but judging based on it's
content Workstation product only (mostly) embraces software development.

>  The software for much of those use cases is available in the wider
>  Fedora repository, so one could install them if needed.
>   
I'm aware that this Fedora devel process revolution shouldn't result in
mass package removal but I'm really worried that goals are set so
narrowly and this might result in functionality degradation. Now we have
all packages for different use cases but no progress is stagnation and
finally death.



Mateusz Marzantowicz

[Jaroslav Reznik]

----- Original Message -----
>  On Fri, Nov 1, 2013 at 12:35 PM, Mateusz Marzantowicz
>  <mmarzantowicz(a)osdf.com.pl&gt; wrote:
>  > On 01.11.2013 15: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.
>  >>
>  >
>  > 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. 
Yes, these are there but I'm not sure such strict message - Fedora Workstation
is for developers DOT (and that's my feeling from current PRD) - is something
we want.

So I'd like to have a bit more higher level audience as described above - 
free/libre content creators, where developers are one big, important subset. If
someone is going to invest there, it's great, it will definitely help all content
creators audience but let's not frighten them just by sending wrong message.
I agree it's harder to aim on the group one level up, we already wanted to aim on
this group but so far we failed. Myabe not because it wasn't well defined, just
nobody cared about it (or our hands were tied by our upstreams).

And ultimate goal where should desktop Fedora end would be not only to be base
for content creators but also part of this ecosystem. I hate this word but it's
definitely changing the whole industry. Create content on Fedora and Fedora can 
help with distribution of free content. As we currently do with software. Libre
music, videos, books - let's have a store for that too! It'll also help with
that problem - I installed Fedora I can't play my mp3s I download, movies - 
point users to libre replacements, help them to understand our values and say
yes - these you can play with stock Fedora!

But yeah, forget my dream in the last paragraph and let's concentrate on the
second one - the third one will come with content creators coming :).

Jaroslav

>  The software for much of those use cases is available in the wider
>  Fedora repository, so one could install them if needed.
>  
>  josh
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Josh Boyer]

On Fri, Nov 1, 2013 at 10:24 AM, Christian Fredrik Kalager Schaller
<cschalle(a)redhat.com&gt; 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. 
Thanks.  I'll take some time this weekend to read this over.

josh

[Bill Nottingham]

Christian Fredrik Kalager Schaller (cschalle(a)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

[Ryan Lerch]

On Fri 01 Nov 2013 14:43:37 EDT, Bill Nottingham wrote:
>  Christian Fredrik Kalager Schaller (cschalle(a)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 
The opening sentence is great, it provides a concise statement of 
intent:

"The Fedora Workstation working group aims to create  a reliable, 
user-friendly and powerful operating system for laptops and PC 
hardware."

All the plans and goals under this should have a clear defined goal of 
how it contributes back to the main statement of intent.

However, should the document also define what some of the terms in that 
statement actually mean? How do we define "reliable", "user-friendly"

and "powerful" (and even "laptops" and "PC hardware")  in
relation to 
the Fedora Workstation.

--ryanlerch

[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" <notting(a)redhat.com&gt;
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org&gt;
Cc: desktop(a)lists.fedoraproject.org
Sent: Friday, November 1, 2013 2:43:37 PM
Subject: Re: Draft Product Description for Fedora Workstation

Christian Fredrik Kalager Schaller (cschalle(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Kevin Kofler]

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

[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.kofler(a)chello.at&gt;
>  To: devel(a)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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Kevin Kofler]

Christian Schaller wrote:
>  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. 
Well, I disagree about the basic decision of whether we want a standard 
desktop UI or something, uh, "different", being only "about the merits of 
the means".

>  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. 
That really didn't have anything to do with the merits of Objective C, or 
even of the desktop, but only with marketing. If Objective C were that 
great, we'd all be using GNUstep.

        Kevin Kofler

[Christian Schaller]

On Sun, 2013-11-03 at 14:42 +0100, Kevin Kofler wrote:
>  Christian Schaller wrote:
>  > 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.
>  
>  Well, I disagree about the basic decision of whether we want a standard 
>  desktop UI or something, uh, "different", being only "about the merits of
>
>  the means".
>  
>  > 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.
>  
>  That really didn't have anything to do with the merits of Objective C, or 
>  even of the desktop, but only with marketing. If Objective C were that 
>  great, we'd all be using GNUstep. 
Which was my point too, we spend way to much time arguing the merits of
programming languages and similar and to little trying to focus on the
things that the rest of the world actually care about. I think the most
extreme example I can remember of this was someone trying to convince me
once to use a web browser that didn't have any of the features I
actually needed, like https support, 'because it had cleaner code'. 
So I am not saying that clean code and maintainability and ease of
development is not important, but I think being a community dominated by
coders we tend to put way to much emphasis on these things compared to
actually solving peoples needs.

Christian

[Reindl Harald]

Am 03.11.2013 15:43, schrieb Christian Fredrik Kalager Schaller:
>  So I am not saying that clean code and maintainability and ease of
>  development is not important, but I think being a community dominated by
>  coders we tend to put way to much emphasis on these things compared to
>  actually solving peoples needs 
the community *are* the people

so no, focus in the imaginary "people" outside the community is plain
wrong, Fedora does not need to make marketing like Apple and Microsoft

a free distribution is in the position making technical correct
decisions without take care about marketing and try to get every
single person out there as user with all bad impact of the
needed compromises

so please be careful with "peoples needs" to not throw away
the advantage of a Linux distribution while fulfill needs of
imaginary people while tend ignore the existing userbase

[Richard Marko]

On 11/03/2013 03:43 PM, Christian Fredrik Kalager Schaller wrote:
>  On Sun, 2013-11-03 at 14:42 +0100, Kevin Kofler wrote:
>
> > That really didn't have anything to do with the merits of Objective C, or 
> > even of the desktop, but only with marketing. If Objective C were that 
> > great, we'd all be using GNUstep.
>  Which was my point too, we spend way to much time arguing the merits of
>  programming languages and similar and to little trying to focus on the
>  things that the rest of the world actually care about. I think the most
>  extreme example I can remember of this was someone trying to convince me
>  once to use a web browser that didn't have any of the features I
>  actually needed, like https support, 'because it had cleaner code'. 
>  So I am not saying that clean code and maintainability and ease of
>  development is not important, but I think being a community dominated by
>  coders we tend to put way to much emphasis on these things compared to
>  actually solving peoples needs.
>  
If we were a community dominated by coders than yes, it might look like
too much. Fortunately, we are also a community of software developers
that value stuff like stability and quality more than features for the
rest of the world that actually doesn't care about us that much.

Currently, even your extreme example doesn't seem so extreme to me
considering that it's quite hard to find browser that gives priority to
improving its speed, stability and privacy instead of adding new
features to keep up with the cool guys.

-- 
Richard Marko

[Kevin Kofler]

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

[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.kofler(a)chello.at&gt;
>  To: devel(a)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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Kevin Kofler]

Christian Schaller wrote:
>  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. 
That still implies shipping legacy libraries and sometimes even withholding 
upgrades (kernel, X11 etc.) and is thus still an unacceptable burden to 
commit to.

>  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 
Ewww! As I wrote in another thread, this would be a HUGE step backwards. 

What we have now is:
* a free-of-charge repository with central QA ensuring that everything works
  together,
* a commitment of that repository to ship only Free Software and active
  auditing to ensure that,
* client tooling automatically resolving dependencies, avoiding the need to
  bundle libraries (see also
  https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries),
* ergo, an installation procedure of "fire up 'Apper (Software Management)',
  enter the package name or some search terms or browse the categories for
  the package, click Install, confirm, (enter root password) (*), use the
  application", as user-friendly as it can get.

What we would have in an "app" world would be:
* every upstream attempting to distribute applications themselves, forcing
  users to hunt down their websites one by one to get software,
* no control whatsoever over licensing, not even a way to check that what
  claims to be "open source" really is (our auditing has found all sorts of
  licenses with bad terms, bundled code under non-free licenses, etc.),
* giving more viability to all sorts of payware models and the proprietary
  license restrictions (no redistribution etc.) that are usually used to
  enforce payment,
* massive bundling and the resulting disk space and security issues.

We DON'T want Apple-like "apps"!

        Kevin Kofler

(*) depending on what PolicyKit permissions are set for the user – AFAIK, we
    now default to not requiring any password for admin (wheel group) users

[Mateusz Marzantowicz]

On 03.11.2013 15:10, Kevin Kofler wrote:
>  
>  We DON'T want Apple-like "apps"! 
This is exactly what is going to happen with "Sandboxed applications for
GNOME" (GNOME, Fedora, Linux - whatever you want). Sadly this idea is
promoted and developed by some RH employees.



Mateusz Marzantowicz

[Chris Murphy]

On Nov 3, 2013, at 7:10 AM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:

>  Christian Schaller wrote:
> > 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.
>  
>  That still implies shipping legacy libraries and sometimes even withholding 
>  upgrades (kernel, X11 etc.) and is thus still an unacceptable burden to 
>  commit to.
>  
> > 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
>  
>  Ewww! As I wrote in another thread, this would be a HUGE step backwards. 
>  
>  What we have now is:
>  * a free-of-charge repository with central QA ensuring that everything works
>   together,
>  * a commitment of that repository to ship only Free Software and active
>   auditing to ensure that,
>  * client tooling automatically resolving dependencies, avoiding the need to
>   bundle libraries (see also
>   https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries),
>  * ergo, an installation procedure of "fire up 'Apper (Software
> Management)',
>   enter the package name or some search terms or browse the categories for
>   the package, click Install, confirm, (enter root password) (*), use the
>   application", as user-friendly as it can get.
>  
>  What we would have in an "app" world would be:
>  * every upstream attempting to distribute applications themselves, forcing
>   users to hunt down their websites one by one to get software,
>  * no control whatsoever over licensing, not even a way to check that what
>   claims to be "open source" really is (our auditing has found all sorts of
>   licenses with bad terms, bundled code under non-free licenses, etc.),
>  * giving more viability to all sorts of payware models and the proprietary
>   license restrictions (no redistribution etc.) that are usually used to
>   enforce payment,
>  * massive bundling and the resulting disk space and security issues.
>  
>  We DON'T want Apple-like "apps"! 
Right, because that's a model for success that shouldn't be either emulated or
improved upon, it's better for each little fiefdom's paradise to erect walls to
ensure cross influence isn't happening.

And that word we you keep using? I don't think it means, what you think it means. Try
to find the huevos to use the word I, seeing as that's what you mean.

What you're arguing for is no one should like, or should have the choice of liking let
alone having "Apple-like" apps, or better. Yes, let's have no choice for
apps that are sometimes complete blackboxes, that run contained from each other, from a
monostore that collects a perpetual 30% finder's fee, and also no options to improve
upon this model without the tie in.

You're proposing a continuation of the adolescent state of Linux on the Desktop with
its barriers to growing the market. Yes, let's build artificial walls keeping out new
users and developers who don't agree with the existing community worldview who might,
duh, change the platform to meet their needs. That's just too scary.

Essentially all you're arguing for is a different version of closed that just so
happens to cost no money. OH WAIT, OS X is now free! So in reality it's just a
different take on closed. That's not innovative.

Making it easier for free and non-free apps to actually work on a platform isn't going
to kill it. It's like fertilizer. Instead of advocating platform sabotage as your
comforting pacifier, how about you just not use, support, or advocate whatever apps you
don't like for whatever subjective reasons you don't like them?

Know what I want? A platform that works. A platform that has apps I want to use. A
platform that isn't poking developers or users in the eyeballs when they want to do
something unique, innovative, necessary for their own success. If Adobe were to want
Photoshop on a linux desktop, I think that would be great news. It would be hugely
disruptive.


Chris Murphy

[Reindl Harald]

Am 03.11.2013 18:28, schrieb Chris Murphy:
>  On Nov 3, 2013, at 7:10 AM, Kevin Kofler
> <kevin.kofler(a)chello.at&gt; wrote:
> > What we have now is:
> > * a free-of-charge repository with central QA ensuring that everything works
> >  together,
> > * a commitment of that repository to ship only Free Software and active
> >  auditing to ensure that,
> > * client tooling automatically resolving dependencies, avoiding the need to
> >  bundle libraries (see also
> >  https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries),
> > * ergo, an installation procedure of "fire up 'Apper (Software
> Management)',
> >  enter the package name or some search terms or browse the categories for
> >  the package, click Install, confirm, (enter root password) (*), use the
> >  application", as user-friendly as it can get.
> >
> > What we would have in an "app" world would be:
> > * every upstream attempting to distribute applications themselves, forcing
> >  users to hunt down their websites one by one to get software,
> > * no control whatsoever over licensing, not even a way to check that what
> >  claims to be "open source" really is (our auditing has found all sorts of
> >  licenses with bad terms, bundled code under non-free licenses, etc.),
> > * giving more viability to all sorts of payware models and the proprietary
> >  license restrictions (no redistribution etc.) that are usually used to
> >  enforce payment,
> > * massive bundling and the resulting disk space and security issues.
> >
> > We DON'T want Apple-like "apps"!
>  
>  Right, because that's a model for success that shouldn't be either emulated or
> improved upon 
if success is

 * to have no centralized updates
 * have most applicatons and tools never updated at all
 * have the weakest security model even compared to Windows these days
 * have a standards violating OS
 * have a unstable OS

and all above points are taken from Apple workstations surrounding me
then indeed i prefer to keep that unsuccesfull as Fedora was while
doing a great job for me the last 7 years as for many others

since it is a free operating system it does not need to be commerical
successfull and so it needs to satisfy it's *existing* and potential userbase
but not obsessive attrative for *everybody*

fit for everybodys needs often at the end of the day means you can do
anything but nothing really good - that's a bad target - keep focused
and doing that things *really good* is the better attitude in doubt

[Rahul Sundaram]

Hi


On Sun, Nov 3, 2013 at 12:44 PM, Reindl Harald  wrote:if success is

>   * to have no centralized updates
>   * have most applicatons and tools never updated at all
>   * have the weakest security model even compared to Windows these days
>   * have a standards violating OS
>   * have a unstable OS
>
>  and all above points are taken from Apple workstations surrounding me
>  then indeed i prefer to keep that unsuccesfull
>  
You assume that sandboxed apps means we get all the negatives and none of
the benefits.  That is unwarranted.  We can adopt the good parts and
improve upon it based on the lessons learned from adoption of app stores
across multiple operating systems and mobile devices that serve a much
broader audience.  We should be willing to let competent contributors who
are interested in doing that try it and provide useful feedback when
necessary instead of dismissing it on bad assumptions as a knee jerk
reaction on our experiences with proprietary software or bad conduct of
particular companies.

For a server oriented user those sandboxed apps might not be relevant and
they might be contend to get their apps from the distribution but sandboxes
apps are a fine tradeoff for others who prefer to be not locked in to a
narrow channel for all their needs.

Lets not pretend that commercial sucess doesn't matter as well. Fedora
might be free for you but it is certainly not free for say Red Hat and
their continued participation is dependent on Fedora being more successful
as well.  I for one, consider this a good thing.

Rahul

[Mateusz Marzantowicz]

On 03.11.2013 19:15, Rahul Sundaram wrote:
>  Hi
>  
>  
>  On Sun, Nov 3, 2013 at 12:44 PM, Reindl Harald wrote:if success is
>  
>  
>       * to have no centralized updates
>       * have most applicatons and tools never updated at all
>       * have the weakest security model even compared to Windows these days
>       * have a standards violating OS
>       * have a unstable OS
>  
>      and all above points are taken from Apple workstations surrounding me
>      then indeed i prefer to keep that unsuccesfull
>  
>  
>  You assume that sandboxed apps means we get all the negatives and none
>  of the benefits.  That is unwarranted.  We can adopt the good parts and
>  improve upon it based on the lessons learned from adoption of app stores
>  across multiple operating systems and mobile devices that serve a much
>  broader audience.  We should be willing to let competent contributors
>  who are interested in doing that try it and provide useful feedback when
>  necessary instead of dismissing it on bad assumptions as a knee jerk
>  reaction on our experiences with proprietary software or bad conduct of
>  particular companies.
>  
>  For a server oriented user those sandboxed apps might not be relevant
>  and they might be contend to get their apps from the distribution but
>  sandboxes apps are a fine tradeoff for others who prefer to be not
>  locked in to a narrow channel for all their needs.
>  
>  Lets not pretend that commercial sucess doesn't matter as well. Fedora
>  might be free for you but it is certainly not free for say Red Hat and
>  their continued participation is dependent on Fedora being more
>  successful as well.  I for one, consider this a good thing.
>   
Just one question: what exact problem are trying to resolve sandboxed
applications?



Mateusz Marzantowicz

[drago01]

On Sun, Nov 3, 2013 at 7:33 PM, Mateusz Marzantowicz
<mmarzantowicz(a)osdf.com.pl&gt; wrote:
>  On 03.11.2013 19:15, Rahul Sundaram wrote:
> > Hi
> >
> >
> > On Sun, Nov 3, 2013 at 12:44 PM, Reindl Harald wrote:if success is
> >
> >
> >      * to have no centralized updates
> >      * have most applicatons and tools never updated at all
> >      * have the weakest security model even compared to Windows these days
> >      * have a standards violating OS
> >      * have a unstable OS
> >
> >     and all above points are taken from Apple workstations surrounding me
> >     then indeed i prefer to keep that unsuccesfull
> >
> >
> > You assume that sandboxed apps means we get all the negatives and none
> > of the benefits.  That is unwarranted.  We can adopt the good parts and
> > improve upon it based on the lessons learned from adoption of app stores
> > across multiple operating systems and mobile devices that serve a much
> > broader audience.  We should be willing to let competent contributors
> > who are interested in doing that try it and provide useful feedback when
> > necessary instead of dismissing it on bad assumptions as a knee jerk
> > reaction on our experiences with proprietary software or bad conduct of
> > particular companies.
> >
> > For a server oriented user those sandboxed apps might not be relevant
> > and they might be contend to get their apps from the distribution but
> > sandboxes apps are a fine tradeoff for others who prefer to be not
> > locked in to a narrow channel for all their needs.
> >
> > Lets not pretend that commercial sucess doesn't matter as well. Fedora
> > might be free for you but it is certainly not free for say Red Hat and
> > their continued participation is dependent on Fedora being more
> > successful as well.  I for one, consider this a good thing.
> >
>
>  Just one question: what exact problem are trying to resolve sandboxed
>  applications? 
Have a way for thrid parties to distribute applications which does not
have to be tied to a specific version
of fedora and "just works" while at the same time (as the app must not
be from fedora) have some level of
sandboxing to prevent it from doing what is not supposed to do. [1]

It also makes it easier for user to install applications without
having to affect other users.

1: http://blogs.gnome.org/alexl/2013/02/01/developer-hackfest-status/

[Mateusz Marzantowicz]

On 03.11.2013 19:40, drago01 wrote:
>  On Sun, Nov 3, 2013 at 7:33 PM, Mateusz Marzantowicz
>  <mmarzantowicz(a)osdf.com.pl&gt; wrote:
> > On 03.11.2013 19:15, Rahul Sundaram wrote:
> >> Hi
> >>
> >>
> >> On Sun, Nov 3, 2013 at 12:44 PM, Reindl Harald wrote:if success is
> >>
> >>
> >>      * to have no centralized updates
> >>      * have most applicatons and tools never updated at all
> >>      * have the weakest security model even compared to Windows these days
> >>      * have a standards violating OS
> >>      * have a unstable OS
> >>
> >>     and all above points are taken from Apple workstations surrounding me
> >>     then indeed i prefer to keep that unsuccesfull
> >>
> >>
> >> You assume that sandboxed apps means we get all the negatives and none
> >> of the benefits.  That is unwarranted.  We can adopt the good parts and
> >> improve upon it based on the lessons learned from adoption of app stores
> >> across multiple operating systems and mobile devices that serve a much
> >> broader audience.  We should be willing to let competent contributors
> >> who are interested in doing that try it and provide useful feedback when
> >> necessary instead of dismissing it on bad assumptions as a knee jerk
> >> reaction on our experiences with proprietary software or bad conduct of
> >> particular companies.
> >>
> >> For a server oriented user those sandboxed apps might not be relevant
> >> and they might be contend to get their apps from the distribution but
> >> sandboxes apps are a fine tradeoff for others who prefer to be not
> >> locked in to a narrow channel for all their needs.
> >>
> >> Lets not pretend that commercial sucess doesn't matter as well. Fedora
> >> might be free for you but it is certainly not free for say Red Hat and
> >> their continued participation is dependent on Fedora being more
> >> successful as well.  I for one, consider this a good thing.
> >>
> >
> > Just one question: what exact problem are trying to resolve sandboxed
> > applications?
>  
>  Have a way for thrid parties to distribute applications which does not
>  have to be tied to a specific version
>  of fedora and "just works" while at the same time (as the app must not
>  be from fedora) have some level of
>  sandboxing to prevent it from doing what is not supposed to do. [1]
>  
>  It also makes it easier for user to install applications without
>  having to affect other users.
>  
>  1: http://blogs.gnome.org/alexl/2013/02/01/developer-hackfest-status/
>   
Do I understand correctly that first problem could be solved by
stabilizing APIs used in various Linux projects? Because developers
don't want stabilizationt they invent workarounds like sandboxes?
Wouldn't it be easier to have stable API for some period of time?

There are some large Opens Source projects that don't change everything
in API with each new release. Maybe Fedora/GNOME could do the same?

I don't see how maintaining local instance of each application is going
to make things easier. It was done this way in MS DOS.


Mateusz Marzantowicz

[Rahul Sundaram]

Hi


On Sun, Nov 3, 2013 at 1:57 PM, Mateusz Marzantowicz

Do I understand correctly that first problem could be solved by

>  stabilizing APIs used in various Linux projects? Because developers
>  don't want stabilizationt they invent workarounds like sandboxes?
>  Wouldn't it be easier to have stable API for some period of time?
>  
You mean ABI and not API but your question is answered already in the
comments at
http://blogs.gnome.org/alexl/2013/02/01/developer-hackfest-status/

" Ideally we *do* want most app to share the system libs, but only those,
not the non-core libraries of varying ABI stability and quality. This way
we can work hard to make the core 100% ABI backwards"

Rahul

[Mateusz Marzantowicz]

On 03.11.2013 20:25, Rahul Sundaram wrote:
>  Hi
>  
>  
>  On Sun, Nov 3, 2013 at 1:57 PM, Mateusz Marzantowicz
>  
>  Do I understand correctly that first problem could be solved by
>  
>      stabilizing APIs used in various Linux projects? Because developers
>      don't want stabilizationt they invent workarounds like sandboxes?
>      Wouldn't it be easier to have stable API for some period of time?
>  
>  
>  You mean ABI and not API but your question is answered already in the
>  comments at
>  http://blogs.gnome.org/alexl/2013/02/01/developer-hackfest-status/
>  
>  " Ideally we *do* want most app to share the system libs, but only
>  those, not the non-core libraries of varying ABI stability and quality.
>  This way we can work hard to make the core 100% ABI backwards"
>   
http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries



Mateusz Marzantowicz

[Bastien Nocera]

That's fine. The apps would ship directly from upstream, not from Fedora :)

----- Original Message -----
>  On 03.11.2013 20:25, Rahul Sundaram wrote:
>  > Hi
>  > 
>  > 
>  > On Sun, Nov 3, 2013 at 1:57 PM, Mateusz Marzantowicz
>  > 
>  > Do I understand correctly that first problem could be solved by
>  > 
>  >     stabilizing APIs used in various Linux projects? Because developers
>  >     don't want stabilizationt they invent workarounds like sandboxes?
>  >     Wouldn't it be easier to have stable API for some period of time?
>  > 
>  > 
>  > You mean ABI and not API but your question is answered already in the
>  > comments at
>  > http://blogs.gnome.org/alexl/2013/02/01/developer-hackfest-status/
>  > 
>  > " Ideally we *do* want most app to share the system libs, but only
>  > those, not the non-core libraries of varying ABI stability and quality.
>  > This way we can work hard to make the core 100% ABI backwards"
>  > 
>  
>  http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
>  
>  
>  
>  Mateusz Marzantowicz
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Ralf Corsepius]

On 11/04/2013 10:45 AM, Bastien Nocera wrote:
>  That's fine. The apps would ship directly from upstream, not from
> Fedora :)
>  
I realize Fedora throwing overboard it basic working principles (open 
source) and trying to implement the working principles which for decades 
have been responsible for other OSes unreliabilty and saftety issues.

[drago01]

On Mon, Nov 4, 2013 at 10:57 AM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  On 11/04/2013 10:45 AM, Bastien Nocera wrote:
> >
> > That's fine. The apps would ship directly from upstream, not from Fedora
> > :)
> >
>
>  I realize Fedora throwing overboard it basic working principles (open
>  source) 
Apps shipping from upstream direcly does not have to be closed source.
Firefox for instance could use that, or libreoffice, or eclipse. If a
user needs a newer version (or nightly build) without having upstream
worry about the specific distribution.

>  and trying to implement the working principles which for decades
>  have been responsible for other OSes unreliabilty and saftety issues. 
Read Alex's blog post re safety.

[Florian Müllner]

On Mon, Nov 4, 2013 at 11:03 AM, drago01 <drago01(a)gmail.com&gt; wrote:
>  Firefox for instance could use that, or libreoffice, or eclipse. If
> a
>  user needs a newer version (or nightly build) without having upstream
>  worry about the specific distribution. 
... or users having to update their *entire* system to
unstable/experimental versions if they want to try the lastest
Firefox/Libreoffice/Eclipse

[Kevin Kofler]

Florian Müllner wrote:
>  ... or users having to update their *entire* system to
>  unstable/experimental versions if they want to try the lastest
>  Firefox/Libreoffice/Eclipse 
Then either upstream or the Fedora packager should just build the unstable 
version against the stable Fedora in a PPA. See e.g. kde-unstable for KDE 
betas. We just need to get that COPR stuff (the Fedora PPAs) done so that 
setting up such a repository becomes easy. That makes much more sense than 
throwing the whole repository system overboard and going back to bundling 
crap.

        Kevin Kofler

[Florian Müllner]

On Mon, Nov 4, 2013 at 6:57 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  Florian Müllner wrote:
> > ... or users having to update their *entire* system to
> > unstable/experimental versions if they want to try the lastest
> > Firefox/Libreoffice/Eclipse
>
>  Then either upstream or the Fedora packager should just build the unstable
>  version against the stable Fedora in a PPA. See e.g. kde-unstable for KDE
>  betas. 
This does not work if the unstable package depends on an unstable
version of a dependency shared with the stable system, e.g. if kate
depends on an experimental Qt version, your current choice is to not
test it or have all of KDE use an unstable version of Qt.

[Mateusz Marzantowicz]

On 04.11.2013 19:25, Florian Müllner wrote:
>  On Mon, Nov 4, 2013 at 6:57 PM, Kevin Kofler
> <kevin.kofler(a)chello.at&gt; wrote:
> > Florian Müllner wrote:
> >> ... or users having to update their *entire* system to
> >> unstable/experimental versions if they want to try the lastest
> >> Firefox/Libreoffice/Eclipse
> >
> > Then either upstream or the Fedora packager should just build the unstable
> > version against the stable Fedora in a PPA. See e.g. kde-unstable for KDE
> > betas.
>  
>  This does not work if the unstable package depends on an unstable
>  version of a dependency shared with the stable system, e.g. if kate
>  depends on an experimental Qt version, your current choice is to not
>  test it or have all of KDE use an unstable version of Qt.
>   
This sounds like a good use case for virtualization. You test your
unstable apps in your test environment with other unstable software and
don't need to destroy your workstation. If I were using Kate (to follow
your example) for my daily work I wouldn't risk making it unusable on my
system.



Mateusz Marzantowicz

[Rahul Sundaram]

Hi


On Mon, Nov 4, 2013 at 1:37 PM, Mateusz Marzantowicz

> > This sounds like a good use case for virtualization. You test
> your 
>  unstable apps in your test environment with other unstable software
> and
>  don't need to destroy your workstation. If I were using Kate (to follow
>  your example) for my daily work I wouldn't risk making it unusable on my
>  system.
>  
The risk wouldn't exist with sandboxed applications since they are self
contained and it is much less overhead than full blown virtualization.

Rahul

[Nicolas Mailhot]

Le Lun 4 novembre 2013 19:48, Rahul Sundaram a écrit :
>  Hi
>
>
>  On Mon, Nov 4, 2013 at 1:37 PM, Mateusz Marzantowicz
>
> >> This sounds like a good use case for virtualization. You test your
>
> > unstable apps in your test environment with other unstable software and
> > don't need to destroy your workstation. If I were using Kate (to follow
> > your example) for my daily work I wouldn't risk making it unusable on my
> > system.
> >
>
>  The risk wouldn't exist with sandboxed applications since they are self
>  contained and it is much less overhead than full blown virtualization. 
As all such schemes it works as long as you ignore the fact that apps
process data and communicate with other apps.


-- 
Nicolas Mailhot

[Olav Vitters]

On Mon, Nov 04, 2013 at 11:05:21PM +0100, Nicolas Mailhot wrote:
>  As all such schemes it works as long as you ignore the fact that
> apps
>  process data and communicate with other apps. 
That's not being overlooked. Probably the presentation already addresses
this concern.

-- 
Regards,
Olav

[Reindl Harald]

Am 04.11.2013 19:25, schrieb Florian Müllner:
>  On Mon, Nov 4, 2013 at 6:57 PM, Kevin Kofler
> <kevin.kofler(a)chello.at&gt; wrote:
> > Florian Müllner wrote:
> >> ... or users having to update their *entire* system to
> >> unstable/experimental versions if they want to try the lastest
> >> Firefox/Libreoffice/Eclipse
> >
> > Then either upstream or the Fedora packager should just build the unstable
> > version against the stable Fedora in a PPA. See e.g. kde-unstable for KDE
> > betas.
>  
>  This does not work if the unstable package depends on an unstable
>  version of a dependency shared with the stable system, e.g. if kate
>  depends on an experimental Qt version, your current choice is to not
>  test it or have all of KDE use an unstable version of Qt. 
and in that case you think you da anybody a favor looking at the big
picture by having 2,3,4,5 different versions of libraries statically
linked and nobody cares about security updates of the bundles?

in a perfect world they would get updates because the bundeled libraries
in the real life *nobody* will care as long the app runs

[Kevin Kofler]

Florian Müllner wrote:
>  This does not work if the unstable package depends on an unstable
>  version of a dependency shared with the stable system, e.g. if kate
>  depends on an experimental Qt version, your current choice is to not
>  test it or have all of KDE use an unstable version of Qt. 
Well, yes, if new libraries are needed, the kde-unstable updates will also 
upgrade those libraries. (It doesn't usually happen with Qt, but it is the 
norm for kdelibs and can also happen with some other libraries.) I still 
think this is less of a mess than having BOTH the stable/legacy AND the 
unstable/new library on the system.

        Kevin Kofler

[Rahul Sundaram]

Hi


On Mon, Nov 4, 2013 at 12:57 PM, Kevin Kofler  wrote:

>  Then either upstream or the Fedora packager should just build the unstable
>  version against the stable Fedora in a PPA. See e.g. kde-unstable for KDE
>  betas. We just need to get that COPR stuff (the Fedora PPAs) done so that
>  setting up such a repository becomes easy. That makes much more sense than
>  throwing the whole repository system overboard and going back to bundling
>  crap.
>  
Good thing we are not doing that.  Fedora is not going to neither throwing
away repositories or start bundling libraries.  Sandboxed applications will
be provided by upstream directly and not by the distribution and they may
or may not choose to bundle libraries.  Users already use a variety of
installation tools outside the distro repo model (language specific tools
like pip for example).  This is just another choice for certain use cases.

Rahul

[Frank Murphy]

On Mon, 4 Nov 2013 11:03:45 +0100
drago01 <drago01(a)gmail.com&gt; wrote:


>  Apps shipping from upstream direcly does not have to be closed
>  source. Firefox for instance could use that, or libreoffice, or
>  eclipse. If a user needs a newer version (or nightly build) without
>  having upstream worry about the specific distribution.
>  
>  
I haven't read every post in the thread.
Confused are use asking users to build nightlies 
(or other ver) from src?

-- 
Regards,
Frank 
www.frankly3d.com

[drago01]

On Mon, Nov 4, 2013 at 11:11 AM, Frank Murphy <frankly3d(a)gmail.com&gt; wrote:
>  On Mon, 4 Nov 2013 11:03:45 +0100
>  drago01 <drago01(a)gmail.com&gt; wrote:
>
>
> > Apps shipping from upstream direcly does not have to be closed
> > source. Firefox for instance could use that, or libreoffice, or
> > eclipse. If a user needs a newer version (or nightly build) without
> > having upstream worry about the specific distribution.
> >
> >
>  I haven't read every post in the thread.
>  Confused are use asking users to build nightlies
>  (or other ver) from src? 
No we are just creating a way to allow those upstreams to create those
builds for users (as Florian said without having them to update to
rawhide or wait six months for the next release).

[Mateusz Marzantowicz]

On 04.11.2013 11:13, drago01 wrote:
>  On Mon, Nov 4, 2013 at 11:11 AM, Frank Murphy
> <frankly3d(a)gmail.com&gt; wrote:
> > On Mon, 4 Nov 2013 11:03:45 +0100
> > drago01 <drago01(a)gmail.com&gt; wrote:
> >
> >
> >> Apps shipping from upstream direcly does not have to be closed
> >> source. Firefox for instance could use that, or libreoffice, or
> >> eclipse. If a user needs a newer version (or nightly build) without
> >> having upstream worry about the specific distribution.
> >>
> >>
> > I haven't read every post in the thread.
> > Confused are use asking users to build nightlies
> > (or other ver) from src?
>  
>  No we are just creating a way to allow those upstreams to create those
>  builds for users (as Florian said without having them to update to
>  rawhide or wait six months for the next release).
>   
The average user don't use nightly builds and should not be interested
in such experimental software. Only developer could benefit from gaining
access to latest builds in order to participate in project development.

Users would be more than happy to use the same software version as long
as they can. I meet users that ask me the same boring question: why do
we need to upgrade to the new version and why do we need to learn using
this software again and again and ....? They understand the need of
fixing bugs and happily welcome some minor improvements but are not
interested in applications as such.

Software is like hammer - it's a tool. People don't care about hammers
unless they can build what they want. People don't want to install
software - they want to use it!



Mateusz Marzantowicz

[Bastien Nocera]

Unless the hammer has a cool new feature that you want to try out, or
a bug that was hampering your work has been fixed and you want to
test that the problem's solved.

You can see that analogies only get us so far...

----- Original Message -----
>  On 04.11.2013 11:13, drago01 wrote:
>  > On Mon, Nov 4, 2013 at 11:11 AM, Frank Murphy <frankly3d(a)gmail.com&gt; wrote:
>  >> On Mon, 4 Nov 2013 11:03:45 +0100
>  >> drago01 <drago01(a)gmail.com&gt; wrote:
>  >>
>  >>
>  >>> Apps shipping from upstream direcly does not have to be closed
>  >>> source. Firefox for instance could use that, or libreoffice, or
>  >>> eclipse. If a user needs a newer version (or nightly build) without
>  >>> having upstream worry about the specific distribution.
>  >>>
>  >>>
>  >> I haven't read every post in the thread.
>  >> Confused are use asking users to build nightlies
>  >> (or other ver) from src?
>  > 
>  > No we are just creating a way to allow those upstreams to create those
>  > builds for users (as Florian said without having them to update to
>  > rawhide or wait six months for the next release).
>  > 
>  
>  The average user don't use nightly builds and should not be interested
>  in such experimental software. Only developer could benefit from gaining
>  access to latest builds in order to participate in project development.
>  
>  Users would be more than happy to use the same software version as long
>  as they can. I meet users that ask me the same boring question: why do
>  we need to upgrade to the new version and why do we need to learn using
>  this software again and again and ....? They understand the need of
>  fixing bugs and happily welcome some minor improvements but are not
>  interested in applications as such.
>  
>  Software is like hammer - it's a tool. People don't care about hammers
>  unless they can build what they want. People don't want to install
>  software - they want to use it!
>  
>  
>  
>  Mateusz Marzantowicz
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Michael Scherer]

Le lundi 04 novembre 2013 à 12:21 +0100, Mateusz Marzantowicz a écrit :
>  On 04.11.2013 11:13, drago01 wrote:
>  > On Mon, Nov 4, 2013 at 11:11 AM, Frank Murphy <frankly3d(a)gmail.com&gt; wrote:
>  >> On Mon, 4 Nov 2013 11:03:45 +0100
>  >> drago01 <drago01(a)gmail.com&gt; wrote:
>  >>
>  >>
>  >>> Apps shipping from upstream direcly does not have to be closed
>  >>> source. Firefox for instance could use that, or libreoffice, or
>  >>> eclipse. If a user needs a newer version (or nightly build) without
>  >>> having upstream worry about the specific distribution.
>  >>>
>  >>>
>  >> I haven't read every post in the thread.
>  >> Confused are use asking users to build nightlies
>  >> (or other ver) from src?
>  > 
>  > No we are just creating a way to allow those upstreams to create those
>  > builds for users (as Florian said without having them to update to
>  > rawhide or wait six months for the next release).
>  > 
>  
>  The average user don't use nightly builds and should not be interested
>  in such experimental software. Only developer could benefit from gaining
>  access to latest builds in order to participate in project development. 
Developers are also interested into getting feedback and tests from
users, and so if they can tell to people "use this version, see if the
bug is fixed, or tell me what you think of the UI", this benefit free
software as a whole.

-- 
Michael Scherer

[Frank Murphy]

On Mon, 04 Nov 2013 12:21:23 +0100
Mateusz Marzantowicz <mmarzantowicz(a)osdf.com.pl&gt; wrote:

>  The average user don't use nightly builds and should not be
>  interested in such experimental software. 
They do if they believe version N+, will fix\give 
feature X that is nice to have.
and give feedback to upstream on use.

-- 
Regards,
Frank 
www.frankly3d.com

[Adam Williamson]

On Mon, 2013-11-04 at 11:13 +0100, drago01 wrote:
>  On Mon, Nov 4, 2013 at 11:11 AM, Frank Murphy
> <frankly3d(a)gmail.com&gt; wrote:
>  > On Mon, 4 Nov 2013 11:03:45 +0100
>  > drago01 <drago01(a)gmail.com&gt; wrote:
>  >
>  >
>  >> Apps shipping from upstream direcly does not have to be closed
>  >> source. Firefox for instance could use that, or libreoffice, or
>  >> eclipse. If a user needs a newer version (or nightly build) without
>  >> having upstream worry about the specific distribution.
>  >>
>  >>
>  > I haven't read every post in the thread.
>  > Confused are use asking users to build nightlies
>  > (or other ver) from src?
>  
>  No we are just creating a way to allow those upstreams to create those
>  builds for users (as Florian said without having them to update to
>  rawhide or wait six months for the next release). 
Haven't read the whole thread yet, but in case it hasn't been said:

"Build a way" would be great. I've said a few times that it'd be nice
for there to be a cross-distro framework for third-party app
distribution.

"Promote as the Proper Way To Get Apps On GNOME / Fedora Desktop" would
NOT be great. Having spent a lot of time thinking about both sides of
the debate I'm still firmly in the 'coherent distribution is the ideal
state' camp. Upstream distribution is probably never going to go away
entirely, and it'd be good to make it as painless and reliable as
possible _where it's really necessary to use it_. But it should never be
the primary/preferred method of software distribution on Fedora, in my
opinion. It should always be an exception.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Matthew Miller]

On Tue, Nov 05, 2013 at 12:44:21PM -0800, Adam Williamson wrote:
>  "Promote as the Proper Way To Get Apps On GNOME / Fedora
> Desktop" would
>  NOT be great. Having spent a lot of time thinking about both sides of
>  the debate I'm still firmly in the 'coherent distribution is the ideal
>  state' camp. Upstream distribution is probably never going to go away
>  entirely, and it'd be good to make it as painless and reliable as
>  possible _where it's really necessary to use it_. But it should never be
>  the primary/preferred method of software distribution on Fedora, in my
>  opinion. It should always be an exception. 
I really would like all my desktop applications to run in a sandbox, whether
they come from upstream directly or from us.



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Adam Williamson]

On Tue, 2013-11-05 at 16:04 -0500, Matthew Miller wrote:
>  On Tue, Nov 05, 2013 at 12:44:21PM -0800, Adam Williamson wrote:
>  > "Promote as the Proper Way To Get Apps On GNOME / Fedora Desktop" would
>  > NOT be great. Having spent a lot of time thinking about both sides of
>  > the debate I'm still firmly in the 'coherent distribution is the ideal
>  > state' camp. Upstream distribution is probably never going to go away
>  > entirely, and it'd be good to make it as painless and reliable as
>  > possible _where it's really necessary to use it_. But it should never be
>  > the primary/preferred method of software distribution on Fedora, in my
>  > opinion. It should always be an exception.
>  
>  I really would like all my desktop applications to run in a sandbox, whether
>  they come from upstream directly or from us. 
I would like that too, to be clear. That is why I used the term
"upstream distribution" and not the term "sandboxed apps". Sandboxing
is
a desirable technology for both upstream and centralized distribution,
which makes its conflation with upstream distribution unfortunate in
this debate: I think that has come about because sandboxing is arguably
more _urgently_ desirable for upstream distribution, but what we're
really arguing about here is the old 'upstream vs. distro-based'
chestnut, not sandboxing.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Matthew Miller]

On Tue, Nov 05, 2013 at 01:06:29PM -0800, Adam Williamson wrote:
>  > I really would like all my desktop applications to run in a
> sandbox, whether
>  > they come from upstream directly or from us.
>  I would like that too, to be clear. That is why I used the term
>  "upstream distribution" and not the term "sandboxed apps". Sandboxing
> is
>  a desirable technology for both upstream and centralized distribution,
>  which makes its conflation with upstream distribution unfortunate in
>  this debate: I think that has come about because sandboxing is arguably
>  more _urgently_ desirable for upstream distribution, but what we're
>  really arguing about here is the old 'upstream vs. distro-based'
>  chestnut, not sandboxing. 
In that case, I absolutely agree with your previous statement which has
been snipped from this subthread. :)


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Rahul Sundaram]

Hi


On Tue, Nov 5, 2013 at 4:06 PM, Adam Williamson wrote:

>  I would like that too, to be clear. That is why I used the term
>  "upstream distribution" and not the term "sandboxed apps". Sandboxing
> is
>  a desirable technology for both upstream and centralized distribution,
>  
I am not sure that is a good distinction either.  I mean, upstream could
provide some metadata which can be aggregated and used by a centralized
interface.  Perhaps we should use distribution packages vs upstream
packages instead?

Rahul

[Kevin Kofler]

Matthew Miller wrote:
>  I really would like all my desktop applications to run in a sandbox,
>  whether they come from upstream directly or from us. 
Why? This artificially restricts what your applications can do and also 
hurts performance. It doesn't buy us anything other than problems! And what 
about libraries? Will they get bundled into each sandbox as the "app" 
principle seems to suggest?

        Kevin Kofler
        (who has SELinux disabled)

[Alberto Ruiz]

On Tue, 2013-11-05 at 12:44 -0800, Adam Williamson wrote:
>  Haven't read the whole thread yet, but in case it hasn't been
> said:
>  
>  "Build a way" would be great. I've said a few times that it'd be nice
>  for there to be a cross-distro framework for third-party app
>  distribution.
>  
>  "Promote as the Proper Way To Get Apps On GNOME / Fedora Desktop" would
>  NOT be great. Having spent a lot of time thinking about both sides of
>  the debate I'm still firmly in the 'coherent distribution is the ideal
>  state' camp. 
And I pretty much agree, read my comments below:

>  Upstream distribution is probably never going to go away
>  entirely, and it'd be good to make it as painless and reliable as
>  possible _where it's really necessary to use it_. But it should never be
>  the primary/preferred method of software distribution on Fedora, in my
>  opinion. It should always be an exception. 
Application sandboxing/bundling is not mutually exclusive with a
coherent system and with keeping control, it's just not an RPM as we
know it. What we need to acknowledge is that delivering integral parts
of the operating system and delivering third party apps are
fundamentally two different things.

So once we have sandboxing we can (and should) propose an end user
application delivery channel for those apps so we will keep control
still. The key here is that the mechanisms to deliver an OS component
and an end user should be different. The cadence _is_ different, as an
example, at the LibreOffice team we have a hell of a time because people
complain about bugs that we already fixed and released on an ongoing
basis. In some cases, people are stuck with a specific version of Fedora
and they simply can't get the latest version of a given app eventhough
the new version doesn't require anything that is provided.

The other problem is that the upstreams don't have a channel to deploy
beta versions, or versions with a specific patch, that you can't install
concurrently because the distributions won't let you.

So all in all, the key here is to acknowledge that a system level
component (systemd, libjpeg, Qt, NetworkManager) has a completely
different nature than an end user application. The upstream has a
different focus, development cadence, nature and intent, and it is
against the interest of the upstreams and the users to keep delivering
those apps as integral parts of the _operating system_.

That doesn't mean that there shouldn't be any sort of integration or
gatkeeping, we must have a centralized Fedora/FOSS app bundle channel
that upstreams can use to "certify' their apps against Fedora, if we use
scriptless rpms and yum repositories as a transport layer, in a
different rpmdb than the system wide one, that is an implementation
detail. But the relationship with the upstream and the cadence should be
completely different than a system level rpm.

>  -- 
>  Adam Williamson
>  Fedora QA Community Monkey
>  IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
>  http://www.happyassassin.net
>   
-- 
Cheers,
Alberto Ruiz

[Simo Sorce]

On Wed, 2013-11-06 at 16:33 +0100, Alberto Ruiz wrote:
>  On Tue, 2013-11-05 at 12:44 -0800, Adam Williamson wrote:
>  > Haven't read the whole thread yet, but in case it hasn't been said:
>  > 
>  > "Build a way" would be great. I've said a few times that it'd be
> nice
>  > for there to be a cross-distro framework for third-party app
>  > distribution.
>  > 
>  > "Promote as the Proper Way To Get Apps On GNOME / Fedora Desktop" would
>  > NOT be great. Having spent a lot of time thinking about both sides of
>  > the debate I'm still firmly in the 'coherent distribution is the ideal
>  > state' camp.
>  
>  And I pretty much agree, read my comments below:
>  
>  > Upstream distribution is probably never going to go away
>  > entirely, and it'd be good to make it as painless and reliable as
>  > possible _where it's really necessary to use it_. But it should never be
>  > the primary/preferred method of software distribution on Fedora, in my
>  > opinion. It should always be an exception.
>  
>  Application sandboxing/bundling is not mutually exclusive with a
>  coherent system and with keeping control, it's just not an RPM as we
>  know it. What we need to acknowledge is that delivering integral parts
>  of the operating system and delivering third party apps are
>  fundamentally two different things.
>  
>  So once we have sandboxing we can (and should) propose an end user
>  application delivery channel for those apps so we will keep control
>  still. The key here is that the mechanisms to deliver an OS component
>  and an end user should be different. The cadence _is_ different, as an
>  example, at the LibreOffice team we have a hell of a time because people
>  complain about bugs that we already fixed and released on an ongoing
>  basis. In some cases, people are stuck with a specific version of Fedora
>  and they simply can't get the latest version of a given app eventhough
>  the new version doesn't require anything that is provided.
>  
>  The other problem is that the upstreams don't have a channel to deploy
>  beta versions, or versions with a specific patch, that you can't install
>  concurrently because the distributions won't let you.
>  
>  So all in all, the key here is to acknowledge that a system level
>  component (systemd, libjpeg, Qt, NetworkManager) has a completely
>  different nature than an end user application. The upstream has a
>  different focus, development cadence, nature and intent, and it is
>  against the interest of the upstreams and the users to keep delivering
>  those apps as integral parts of the _operating system_.
>  
>  That doesn't mean that there shouldn't be any sort of integration or
>  gatkeeping, we must have a centralized Fedora/FOSS app bundle channel
>  that upstreams can use to "certify' their apps against Fedora, if we use
>  scriptless rpms and yum repositories as a transport layer, in a
>  different rpmdb than the system wide one, that is an implementation
>  detail. But the relationship with the upstream and the cadence should be
>  completely different than a system level rpm. 
Excellent summary Alberto,
I recently felt on my skin what it means to be locked in a buggy version
of LiberOffice. Making it simple for user to install the upstream
version instead of our bundled one would help *a lot* all free software
users.
Also from an engineering pov it will make our work in Fedora less heavy
allowing us to improve the core OS.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[Kevin Kofler]

Alberto Ruiz wrote:
>  Application sandboxing/bundling is not mutually exclusive with a
>  coherent system and with keeping control, it's just not an RPM as we
>  know it. What we need to acknowledge is that delivering integral parts
>  of the operating system and delivering third party apps are
>  fundamentally two different things. 
Big -1 to that!

The fact that we have no such artificial distinction has always been one of 
the biggest strengths of GNU/Linux.

>  So once we have sandboxing we can (and should) propose an end user
>  application delivery channel for those apps so we will keep control
>  still. The key here is that the mechanisms to deliver an OS component
>  and an end user should be different. The cadence _is_ different, as an
>  example, at the LibreOffice team we have a hell of a time because people
>  complain about bugs that we already fixed and released on an ongoing
>  basis. In some cases, people are stuck with a specific version of Fedora
>  and they simply can't get the latest version of a given app eventhough
>  the new version doesn't require anything that is provided. 
We should just push the new version as an update.

>  The other problem is that the upstreams don't have a channel to
> deploy
>  beta versions, or versions with a specific patch, 
That's what testing repos (COPRs, repos.fedorapeople.org etc.) are for (see 
also kde-unstable and kde-testing for a working large-scale example).

>  that you can't install concurrently because the distributions
> won't let
>  you. 
What's the point of letting them install concurrently? If you want to test a 
patch because the installed version doesn't work properly for you, you want 
to REPLACE the installed version with one that works for you. If it is 
actually worse, you can just yum downgrade/distro-sync to the official 
version.
 
        Kevin Kofler

[Bastien Nocera]

----- Original Message -----
>  On 11/04/2013 10:45 AM, Bastien Nocera wrote:
>  > That's fine. The apps would ship directly from upstream, not from Fedora :)
>  >
>  
>  I realize Fedora throwing overboard it basic working principles (open
>  source) 
Did I say that? No, I don't believe I did.

As an application developer, I'd sure be happy if I didn't have to wait
6 months for my app to show up in the distribution I use, and for that
application to be usable on all compatible distributions.

>  and trying to implement the working principles which for decades
>  have been responsible for other OSes unreliabilty and saftety issues. 
The app store model is a couple of years old, not decades old.

I want OS updates to the level of iOS, and application updates to the
level offered by Android and iOS. I want upstream to control their distribution
of software and not be reliant on distributions shipping this or that update
(good luck if you ship an app that's in Ubuntu's core, people won't see
bug fix updates until 6 months afterwards).

[Nicolas Mailhot]

Le Lun 4 novembre 2013 11:16, Bastien Nocera a écrit :
>  I want upstream to control their
>  distribution
>  of software and not be reliant on distributions shipping this or that
>  update 
ie I don't want to make the api stabilization process in my software that
would make it safely shippable by distros, but I want it to be shipped
anyway let's have users keep the pieces

kernel folks have no problem getting their latest software shipped even in
ancient distros. Admittedly, they worked hard to reach this state

-- 
Nicolas Mailhot

[Bastien Nocera]

----- Original Message -----
>  
>  Le Lun 4 novembre 2013 11:16, Bastien Nocera a écrit :
>  > I want upstream to control their
>  > distribution
>  > of software and not be reliant on distributions shipping this or that
>  > update
>  
>  ie I don't want to make the api stabilization process in my software that
>  would make it safely shippable by distros, but I want it to be shipped
>  anyway let's have users keep the pieces 
What does that have to do with API stabilisation?

>  kernel folks have no problem getting their latest software shipped
> even in
>  ancient distros. Admittedly, they worked hard to reach this state 
You can probably re-enact that famous scene from the Wickerman building this
many strawmen.

[Nicolas Mailhot]

Le Lun 4 novembre 2013 12:26, Bastien Nocera a écrit :

>  You can probably re-enact that famous scene from the Wickerman
> building
>  this
>  many strawmen. 
Thank you for demonstrating the complete lack of respect you have for
anyone that disagrees with you.

-- 
Nicolas Mailhot

[Josh Boyer]

On Mon, Nov 4, 2013 at 6:42 AM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net&gt; wrote:
>  Le Lun 4 novembre 2013 12:26, Bastien Nocera a écrit :
>
> > You can probably re-enact that famous scene from the Wickerman building
> > this
> > many strawmen.
>
>  Thank you for demonstrating the complete lack of respect you have for
>  anyone that disagrees with you. 
Please stop it, both of you.

There are great usecases for applications and libraries being included
in a distribution.  That is why Fedora (and every other distribution)
exists in the first place.  There are ALSO usecases for shipping
containerized applications.  That is where much of the web development
and other application development has headed in recent times.
Ignoring that does us no good and leaves us sitting around with an
application deployment framework that increasingly fewer upstreams
want to care about.

Both types of application deployment need to exist.  If you think this
is somehow isolated to the Workstation product, it isn't.  It will be
on Server and Cloud.

josh

[drago01]

On Mon, Nov 4, 2013 at 1:00 PM, Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:
>  On Mon, Nov 4, 2013 at 6:42 AM, Nicolas Mailhot
>  <nicolas.mailhot(a)laposte.net&gt; wrote:
> >
> > Le Lun 4 novembre 2013 12:26, Bastien Nocera a écrit :
> >
> >> You can probably re-enact that famous scene from the Wickerman building
> >> this
> >> many strawmen.
> >
> > Thank you for demonstrating the complete lack of respect you have for
> > anyone that disagrees with you.
>
>  Please stop it, both of you.
>
>  There are great usecases for applications and libraries being included
>  in a distribution.  That is why Fedora (and every other distribution)
>  exists in the first place.  There are ALSO usecases for shipping
>  containerized applications. 
Yes exactly those are not mutually exclusive. There is always a need
for self contained applications.
Having something in the OS that works, is well designed and integrated
only has a net benefit instead
of having upstreams come up with their own solutions (installers,
tarballs and what not).

[Kevin Kofler]

Bastien Nocera wrote:
>  As an application developer, I'd sure be happy if I didn't
> have to wait
>  6 months for my app to show up in the distribution I use, and for that
>  application to be usable on all compatible distributions. 
That's a problem with the distribution's update policies, not with the 
concept of a repository.

        Kevin Kofler

[Bastien Nocera]

When my application runs on all Fedora distributions without changes? No.
I wasn't talking about core apps that are tightly integrated to the desktop,
just of the time it took for somebody to package up "office-runner" from
my 1.0 release to it being in the distribution.

----- Original Message -----
>  Bastien Nocera wrote:
>  > As an application developer, I'd sure be happy if I didn't have to wait
>  > 6 months for my app to show up in the distribution I use, and for that
>  > application to be usable on all compatible distributions.
>  
>  That's a problem with the distribution's update policies, not with the
>  concept of a repository.
>  
>          Kevin Kofler
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Kevin Kofler]

Bastien Nocera wrote:
>  When my application runs on all Fedora distributions without changes?
> No.
>  I wasn't talking about core apps that are tightly integrated to the
>  desktop, just of the time it took for somebody to package up
>  "office-runner" from my 1.0 release to it being in the distribution. 
Leaf packages are actually the ones updated most quickly if the maintainer 
is responsive. Here, you are talking about a new package though. And the 
problem here was that it had taken almost 2 years for somebody to submit it 
for review, why haven't you done that back when you wrote the tool? It's not 
like that program is hard to package.

        Kevin Kofler

[Bastien Nocera]

----- Original Message -----
>  Bastien Nocera wrote:
>  > When my application runs on all Fedora distributions without changes? No.
>  > I wasn't talking about core apps that are tightly integrated to the
>  > desktop, just of the time it took for somebody to package up
>  > "office-runner" from my 1.0 release to it being in the distribution.
>  
>  Leaf packages are actually the ones updated most quickly if the maintainer
>  is responsive. Here, you are talking about a new package though. And the
>  problem here was that it had taken almost 2 years for somebody to submit it
>  for review, why haven't you done that back when you wrote the tool? It's not
>  like that program is hard to package. 
Because I have other things to do rather than packaging? Because I already
own enough modules upstream that I don't want to burden myself with maintenance
of a tool in a Bugzilla that I don't like.

It might be easy, but it's not time-free. If there was a way that I could package
it up in such a way that it would be available for Arch, Gentoo, Ubuntu GNOME,
Fedora, or even using on GNOME's nightlies, I would gladly have done it. It's
not possible right now, and I hope it will be possible soon.

[Alberto Ruiz]

On Mon, 2013-11-04 at 19:00 +0100, Kevin Kofler wrote:
>  Bastien Nocera wrote:
>  > As an application developer, I'd sure be happy if I didn't have to wait
>  > 6 months for my app to show up in the distribution I use, and for that
>  > application to be usable on all compatible distributions.
>  
>  That's a problem with the distribution's update policies, not with the 
>  concept of a repository. 
Sure, that's why an application container would allow for application
specific repositories (a.k.a. stores) where apps can reviewed as apps
instead of system-wide swappable components.

Then you can have a policy that is more suitable to apps with a
different cadence than the system-wide (rpm/deb/...) repository, in fact
you may not need a cadence at all.

It is outrageous that it's 2013 and I still have to upgrade my whole
system just to get the latest LibreOffice version to name an example.

>  
>          Kevin Kofler
>   
-- 
Cheers,
Alberto Ruiz

[Reindl Harald]

Am 04.11.2013 19:33, schrieb Alberto Ruiz:
>  It is outrageous that it's 2013 and I still have to upgrade my
> whole
>  system just to get the latest LibreOffice version to name an example. 
no it is the reason why who have tousands of packages which are working
togehter and get security updates for all involved libraries instead
having the windows nightmare of nobody in the world is knowing which
vulernerable code sleeps in what random application

having *a distribution* is one of the best things Linux systems are
providing compared to crap like Apple/Microsoft, throwing that away
is a straight road to make Fedora obsolete at all

someoby does not like the concept -> fine, use another OS - period

[drago01]

On Mon, Nov 4, 2013 at 8:05 PM, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
>  Am 04.11.2013 19:33, schrieb Alberto Ruiz:
> > It is outrageous that it's 2013 and I still have to upgrade my whole
> > system just to get the latest LibreOffice version to name an example.
>
>  no it is the reason why who have tousands of packages which are working
>  togehter and get security updates for all involved libraries instead
>  having the windows nightmare of nobody in the world is knowing which
>  vulernerable code sleeps in what random application
>
>  having *a distribution* is one of the best things Linux systems are
>  providing compared to crap like Apple/Microsoft, throwing that away
>  is a straight road to make Fedora obsolete at all
>
>  someoby does not like the concept -> fine, use another OS - period 
Like it or not people already do use alternative distribution models
for those use cases (try to download firefox from the homepage for
instance).
Given people tools to do it properly hurts because of __ ?

[Reindl Harald]

Am 04.11.2013 20:12, schrieb drago01:
>  On Mon, Nov 4, 2013 at 8:05 PM, Reindl Harald
> <h.reindl(a)thelounge.net&gt; wrote:
> >
> > Am 04.11.2013 19:33, schrieb Alberto Ruiz:
> >> It is outrageous that it's 2013 and I still have to upgrade my whole
> >> system just to get the latest LibreOffice version to name an example.
> >
> > no it is the reason why who have tousands of packages which are working
> > togehter and get security updates for all involved libraries instead
> > having the windows nightmare of nobody in the world is knowing which
> > vulernerable code sleeps in what random application
> >
> > having *a distribution* is one of the best things Linux systems are
> > providing compared to crap like Apple/Microsoft, throwing that away
> > is a straight road to make Fedora obsolete at all
> >
> > someoby does not like the concept -> fine, use another OS - period
>  
>  Like it or not people already do use alternative distribution models
>  for those use cases (try to download firefox from the homepage for
>  instance).
>  Given people tools to do it properly hurts because of __ ? 
wasted time?

[harry@srv-rhsoft:~]$ rpm -q firefox
firefox-25.0-3.fc19.x86_64

why should somebody download Firefo from the homepage?
because he do not know how to handle his system?

then explain how to handle it instead work around while seeking
solutions for non-existing problems - guess what: i have running
no single application which si not installed with RPM and you can
be sure that my workflow covers anything from office to development

ok - two exceptions - VMware Workstation and ZendStudio
both are running since years on Fedora systems @home as
well @work on 4 different workstations

[drago01]

On Mon, Nov 4, 2013 at 8:31 PM, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:

>  ok - two exceptions - VMware Workstation and ZendStudio
>  both are running since years on Fedora systems @home as
>  well @work on 4 different workstations 
So even your specific case would be helped in such a system. Maybe for
you this are "two exceptions" but for others they might be more then
two.
Try for once to think in broader terms ... there are use cases and
users beyond your personal workstations and server infrastructure.
And even
if your stuff "worked well for years" it does not mean that is perfect
and there is no room for improvement.

[Reindl Harald]

Am 04.11.2013 20:47, schrieb drago01:
>  On Mon, Nov 4, 2013 at 8:31 PM, Reindl Harald
> <h.reindl(a)thelounge.net&gt; wrote:
> > ok - two exceptions - VMware Workstation and ZendStudio
> > both are running since years on Fedora systems @home as
> > well @work on 4 different workstations
>  
>  So even your specific case would be helped in such a system. Maybe for
>  you this are "two exceptions" but for others they might be more then
>  two.
>  Try for once to think in broader terms ... there are use cases and
>  users beyond your personal workstations and server infrastructure.
>  And even
>  if your stuff "worked well for years" it does not mean that is perfect
>  and there is no room for improvement 
nothing is perfect and will ever be for all usecases

but with the easy.click-there-and-install-a-bundle way i most likely
would not have started to build my own RPMs, cleanup anything and
make decisions to throw things away which does not fit in this concept

going only the easy way is most times wrong looking at the big picture

the result of never have a need to learn doing things the right way
would in my case never leaded in build a complete company infrastructure
based on the expierience of my personal machine for two years before

if Fedora want to do his userbase a favor it should spend more thoughts
in not breaking existing user expierience with not-ready alpha quality
software like KDE4.0, the first GNOME3 releases or say it in other words
not try to "be the first for the sake of beeing the first" without
compromises

not only once such decisions leaded even for power users like me knowing
every single configuration file of my system and understand what every
piece of software *did* in pure anger because working things was replaced
by not-ready-for-users replacements mising functions or full of bugs
and unfinished concepts

before try to please the ordianary users not care about anything Fedora
should hardly try to not repeatly spit power-users with much expierenice
in their faces with too soon big changes

after get that well done you should care about users not care about
how a operating system and distribution works at all because they
will never honor the distributions work that way users like me would
do if things not break that often

[Kevin Kofler]

drago01 wrote:
>  Like it or not people already do use alternative distribution models
>  for those use cases (try to download firefox from the homepage for
>  instance).
>  Given people tools to do it properly hurts because of __ ? 
… because it will actually get fewer applications packaged properly (in our 
repositories), see my reply elsewhere in the thread.

        Kevin Kofler

[Josh Boyer]

On Mon, Nov 4, 2013 at 2:05 PM, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
>  Am 04.11.2013 19:33, schrieb Alberto Ruiz:
> > It is outrageous that it's 2013 and I still have to upgrade my whole
> > system just to get the latest LibreOffice version to name an example.
>
>  no it is the reason why who have tousands of packages which are working
>  togehter and get security updates for all involved libraries instead
>  having the windows nightmare of nobody in the world is knowing which
>  vulernerable code sleeps in what random application 
And for lower level or more mature projects, that is a great model to
follow.  Not every upstream project is like that though.

>  having *a distribution* is one of the best things Linux systems are
>  providing compared to crap like Apple/Microsoft, throwing that away
>  is a straight road to make Fedora obsolete at all 
Nobody is throwing it away.

>  someoby does not like the concept -> fine, use another OS - period
That isn't a great attitude to carry forward.  I'd rather try and find
a good balance between the two so we don't relegate Fedora to less
than it could be.

josh

[Kevin Kofler]

Josh Boyer wrote:
>  That isn't a great attitude to carry forward.  I'd rather try
> and find
>  a good balance between the two so we don't relegate Fedora to less
>  than it could be. 
"good balance"? Buzzword alert!
http://en.wikipedia.org/wiki/False_dilemma

        Kevin Kofler

[Stephen Gallagher]

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

On 11/04/2013 03:53 PM, Kevin Kofler wrote:
>  Josh Boyer wrote:
> > That isn't a great attitude to carry forward.  I'd rather try and
> > find a good balance between the two so we don't relegate Fedora
> > to less than it could be.
>  
>  "good balance"? Buzzword alert! 
>  http://en.wikipedia.org/wiki/False_dilemma
>   
Did you read this link? It talks about exactly what you are doing:
asserting that the world must either be "distro-package only" or
"absolute chaos". Josh's perspective is that the problem is far more
nuanced, which you appear to be ignoring while pushing your false
dilemma on us.

Please, stop making ad hominem attacks and try to provide some
evidence to back up your claims.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJ4EbMACgkQeiVVYja6o6O9NwCggp/UrcG2pRkHyQ4AM3LrMAe5
> GLUAoIRRqbdw4kvKla3tCEHFxxqxd4lk
> =xs2P
> -----END PGP SIGNATURE-----

[Kevin Kofler]

Stephen Gallagher wrote:
>  Did you read this link? It talks about exactly what you are doing:
>  asserting that the world must either be "distro-package only" or
>  "absolute chaos". Josh's perspective is that the problem is far more
>  nuanced, which you appear to be ignoring while pushing your false
>  dilemma on us. 
Oops, I managed to proverbially shoot myself in the foot by posting the 
wrong link…

IMHO, there is no false dilemma here, but a true one, and the proposed 
"middle ground" actually makes no sense:
http://en.wikipedia.org/wiki/Argument_to_moderation

        Kevin Kofler

[Stephen Gallagher]

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

On 11/04/2013 05:00 PM, Kevin Kofler wrote:
>  Stephen Gallagher wrote:
> > Did you read this link? It talks about exactly what you are
> > doing: asserting that the world must either be "distro-package
> > only" or "absolute chaos". Josh's perspective is that the problem
> > is far more nuanced, which you appear to be ignoring while
> > pushing your false dilemma on us.
>  
>  Oops, I managed to proverbially shoot myself in the foot by posting
>  the wrong link…
>  
>  IMHO, there is no false dilemma here, but a true one, and the
>  proposed "middle ground" actually makes no sense: 
>  http://en.wikipedia.org/wiki/Argument_to_moderation 
Heh, we've all done that. Still, I'm not sure that this accurately
describes the situation. Particularly because (as I have noted in
other parts of this thread) what we are actually talking about doing
is simply "legitimizing" a behavior that is happening anyway and doing
so in a manner that allows us to do a better job of keeping tabs on
it. Instead of people who want a specific version of e.g. Node.js
going to the nodejs.org website and downloading the binary tarball
there, we offer them a place to download a vetted version of the same.
We can then at least minimize some of the problems inherent there,
like coordinating updates of bundled software.

The developers of the world really are split between what I call "pure
deployment" (with no bundled libraries and proper API/ABI versioning)
and "rapid deployment" (where they throw everything together as a
matched set and maintain the whole stack themselves). If we're not
addressing the second case, we're irrelevant to them and they're
probably not going to prefer to deploy on our products.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJ4QyUACgkQeiVVYja6o6MXxQCdHk97bsqejXYmm6JG7rsmhgml
> f/kAn20NhFNk3afEOTGT+BpK+Wf5Fu3R
> =8zwK
> -----END PGP SIGNATURE-----

[Kevin Kofler]

I wrote:
>  Josh Boyer wrote:
> > That isn't a great attitude to carry forward.  I'd rather try and find
> > a good balance between the two so we don't relegate Fedora to less
> > than it could be.
>  
>  "good balance"? Buzzword alert!
>  http://en.wikipedia.org/wiki/False_dilemma 
Oops, that is actually the opposite fallacy. I was thinking of this one:
http://en.wikipedia.org/wiki/Argument_to_moderation

         Kevin Kofler

[Kevin Kofler]

Alberto Ruiz wrote:
>  Then you can have a policy that is more suitable to apps with a
>  different cadence than the system-wide (rpm/deb/...) repository, in fact
>  you may not need a cadence at all. 
Such applications should just be shipped as updates to the released 
distribution.

        Kevin Kofler

[drago01]

On Mon, Nov 4, 2013 at 9:03 AM, Mateusz Marzantowicz
<mmarzantowicz(a)osdf.com.pl&gt; wrote:
>  On 03.11.2013 20:25, Rahul Sundaram wrote:
> > Hi
> >
> >
> > On Sun, Nov 3, 2013 at 1:57 PM, Mateusz Marzantowicz
> >
> > Do I understand correctly that first problem could be solved by
> >
> >     stabilizing APIs used in various Linux projects? Because developers
> >     don't want stabilizationt they invent workarounds like sandboxes?
> >     Wouldn't it be easier to have stable API for some period of time?
> >
> >
> > You mean ABI and not API but your question is answered already in the
> > comments at
> > http://blogs.gnome.org/alexl/2013/02/01/developer-hackfest-status/
> >
> > " Ideally we *do* want most app to share the system libs, but only
> > those, not the non-core libraries of varying ABI stability and quality.
> > This way we can work hard to make the core 100% ABI backwards"
> >
>
>  http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries 
See Bastien's reply you missed the point.

[Chris Murphy]

On Nov 3, 2013, at 11:57 AM, Mateusz Marzantowicz <mmarzantowicz(a)osdf.com.pl&gt;
wrote:
>  
>  Do I understand correctly that first problem could be solved by
>  stabilizing APIs used in various Linux projects? Because developers
>  don't want stabilizationt they invent workarounds like sandboxes?
>  Wouldn't it be easier to have stable API for some period of time? 
Interface stability is a continuum. Windows has extremely stable interfaces that last
seemingly decades. Legacy compatibility is a Windows mantra. 

And then Apple has little problem wholesale abandoning interfaces for entirely new ones.
The compatibility for applications between major versions, 10.7.x to 10.8.x is quite good
but it's always the case some applications don't work or have odd behaviors. It
continues to surprise me they get away with this once a year with next to no user
backlash, overwhelmingly OS X users upgrade en mass within months. And some developers are
ready on day 1 release, and others take a while to support the new OS, and that's
their choice.

In any case, the WG should pick the location on that continuum for Fedora. It needs a
suitable compromise between stability and pushing innovation, and therefore things are
going to break. But hopefully only a little broken and with some notice of more
significant breakage being anticipated.

Chris Murphy

[Kevin Kofler]

Rahul Sundaram wrote:
>  You assume that sandboxed apps means we get all the negatives and
> none of
>  the benefits.  That is unwarranted.  We can adopt the good parts and
>  improve upon it based on the lessons learned from adoption of app stores
>  across multiple operating systems and mobile devices that serve a much
>  broader audience.  We should be willing to let competent contributors who
>  are interested in doing that try it and provide useful feedback when
>  necessary instead of dismissing it on bad assumptions as a knee jerk
>  reaction on our experiences with proprietary software or bad conduct of
>  particular companies. 
The reason we are so strongly opposed to app stores is that we are fairly 
convinced that the mere fact of having them available WILL:
* reduce the number of applications actually available in our repositories
  (because some upstreams will just upload a bundle and tell you to use
  that, and nobody will want to do the work of actually getting the package
  through Fedora review),
* result in more applications adopting non-Free licenses (because one of the
  big pressure factors to adopt an acceptable license has always been to get
  into Fedora and Debian repositories – drop that and people will just use
  whatever restrictive license terms they can come up with),
* increase the number of applications that cost money (especially if you
  offer a true app store, i.e. one which allows selling apps in them – do
  you really expect that if you tell people that they can sell apps in your
  store, they will not do it?)
and thus, it is just not true that having the app store available does not 
affect those of us who opt against using it. It WILL have detrimental 
effects that will hurt all users.

        Kevin Kofler

[Matthew Miller]

On Mon, Nov 04, 2013 at 06:39:54PM +0100, Kevin Kofler wrote:
>  The reason we are so strongly opposed to app stores is that we are
> fairly 
>  convinced that the mere fact of having them available WILL:
>  * reduce the number of applications actually available in our repositories
>    (because some upstreams will just upload a bundle and tell you to use
>    that, and nobody will want to do the work of actually getting the package
>    through Fedora review), 
If they're easily available to our users, and work just as nicely or better,
why is this a problem? In fact, it kind of sounds like "everyone wins!" to
me.

>  * result in more applications adopting non-Free licenses (because one
> of the
>    big pressure factors to adopt an acceptable license has always been to get
>    into Fedora and Debian repositories – drop that and people will just use
>    whatever restrictive license terms they can come up with), 
The world has changed here. Whatever power we had to apply this kind of
pressure is shrinking. In the world of "fork us on github!", "getting into
a
distro" really isn't that important to people anymore regardless of what we
do.

In the bigger picture good news, though, free software and open source are
going on just fine in the world whether or not we are relevant.

That said, there's no inherent connection here. We certainly _could_ decide
to only have an app store which only allowed software with FLOSS licenses.


>  * increase the number of applications that cost money (especially if
> you
>    offer a true app store, i.e. one which allows selling apps in them – do
>    you really expect that if you tell people that they can sell apps in your
>    store, they will not do it?) 
I'm not sure this is a) true or b) necessarily bad even if true.

But, it's also irrelevant, because I also don't think we're planning to do
anything around collecting money (despite the use of the word "store").


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Alberto Ruiz]

On Mon, 2013-11-04 at 12:56 -0500, Matthew Miller wrote:
>  On Mon, Nov 04, 2013 at 06:39:54PM +0100, Kevin Kofler wrote:
>  > The reason we are so strongly opposed to app stores is that we are fairly 
>  > convinced that the mere fact of having them available WILL:
>  > * reduce the number of applications actually available in our repositories
>  >   (because some upstreams will just upload a bundle and tell you to use
>  >   that, and nobody will want to do the work of actually getting the package
>  >   through Fedora review),
>  
>  If they're easily available to our users, and work just as nicely or better,
>  why is this a problem? In fact, it kind of sounds like "everyone wins!" to
>  me. 
Indeed, this is a relief to the distro community, suddenly you don't
have the burden of maintaining all these apps in your system image,
avoiding any potential problems on upgrades.

It also removes the pressure for the user to have to upgrade his/her
whole system just because they want the latest version of an app.

It also allows for parallel versions of an app, which means that to test
a beta version of, say,  LibreOffice, you don't need the beta version of
your whole operating system.

And the application developer suddenly gains back control on how and
when his app gets delivered to users.

The only downside is that we are going to have to rewire our brains to
stop using yum/dnf to browse/install/remove end user desktop apps.
(This, I think, is why this idea gets so much pushback from the distro
communities)

And, by the way, we've been supporting this kind of model with pip and
gem already, so I really don't get why all the fuss when suddenly we
want to do it with the desktop applications.

-- 
Cheers,
Alberto Ruiz

[Stephen Gallagher]

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

On 11/04/2013 01:54 PM, Alberto Ruiz wrote:
>  On Mon, 2013-11-04 at 12:56 -0500, Matthew Miller wrote:
> > On Mon, Nov 04, 2013 at 06:39:54PM +0100, Kevin Kofler wrote:
> >> The reason we are so strongly opposed to app stores is that we
> >> are fairly convinced that the mere fact of having them
> >> available WILL: * reduce the number of applications actually
> >> available in our repositories (because some upstreams will just
> >> upload a bundle and tell you to use that, and nobody will want
> >> to do the work of actually getting the package through Fedora
> >> review),
> > 
> > If they're easily available to our users, and work just as nicely
> > or better, why is this a problem? In fact, it kind of sounds like
> > "everyone wins!" to me.
>  
>  Indeed, this is a relief to the distro community, suddenly you
>  don't have the burden of maintaining all these apps in your system
>  image, avoiding any potential problems on upgrades.
>  
>  It also removes the pressure for the user to have to upgrade
>  his/her whole system just because they want the latest version of
>  an app.
>   
Alternately, it avoids forcing unstable backports of applications into
the older releases.


>  It also allows for parallel versions of an app, which means that to
>  test a beta version of, say,  LibreOffice, you don't need the beta
>  version of your whole operating system.
>   

This seems a little bit of a thin justification, but if we're getting
it for free alongside the other features... hooray?


>  And the application developer suddenly gains back control on how
>  and when his app gets delivered to users.
>  
>  The only downside is that we are going to have to rewire our brains
>  to stop using yum/dnf to browse/install/remove end user desktop
>  apps. (This, I think, is why this idea gets so much pushback from
>  the distro communities) 

That's not necessarily true. It's entirely plausible that we could
integrate these two approaches simply by creating an RPM wrapper that
would pull down the appropriate application object (whatever that
format happens to be).


>  
>  And, by the way, we've been supporting this kind of model with pip
>  and gem already, so I really don't get why all the fuss when
>  suddenly we want to do it with the desktop applications.
>   
Please don't use pip and gem as "positive" examples... they have a
habit of conflicting with the installed system that is an additional
problem we may hope to solve with this.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJ37vIACgkQeiVVYja6o6OjPwCfTJwqr9Kquwt+817zkHWZ7Gn3
> RS4An3VNyyI/O6+YKBWYdBcS6U29HF7u
> =P03q
> -----END PGP SIGNATURE-----

[Josh Boyer]

On Mon, Nov 4, 2013 at 2:01 PM, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
> > And, by the way, we've been supporting this kind of model
> with pip
> > and gem already, so I really don't get why all the fuss when
> > suddenly we want to do it with the desktop applications.
> >
>
>  Please don't use pip and gem as "positive" examples... they have a
>  habit of conflicting with the installed system that is an additional
>  problem we may hope to solve with this. 
It's worth pointing out that they're positive examples to the
developers using them.  They want to work on their applications and
not have to fight against the distro's versions.  And those developers
are particularly the ones being targeted with containerized apps.  So
equating the two in a positive light probably isn't a bad idea.  Those
developers care about their apps.  They don't care about the distros.
Maybe just phrase it as "this is like pip and gem, but without the
conflict headaches."

josh

[Stephen Gallagher]

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

On 11/04/2013 02:15 PM, Josh Boyer wrote:
>  On Mon, Nov 4, 2013 at 2:01 PM, Stephen Gallagher
>  <sgallagh(a)redhat.com&gt; wrote:
> >> And, by the way, we've been supporting this kind of model with
> >> pip and gem already, so I really don't get why all the fuss
> >> when suddenly we want to do it with the desktop applications.
> >> 
> > 
> > Please don't use pip and gem as "positive" examples... they have
> > a habit of conflicting with the installed system that is an
> > additional problem we may hope to solve with this.
>  
>  It's worth pointing out that they're positive examples to the 
>  developers using them.  They want to work on their applications
>  and not have to fight against the distro's versions.  And those
>  developers are particularly the ones being targeted with
>  containerized apps.  So equating the two in a positive light
>  probably isn't a bad idea.  Those developers care about their apps.
>  They don't care about the distros. Maybe just phrase it as "this is
>  like pip and gem, but without the conflict headaches." 
Sorry, I phrased that poorly (and you covered what I meant to say).

I basically just meant "don't hold these up as the ideals for what
we're trying to do".

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJ38rwACgkQeiVVYja6o6OAjgCfXy4liGhrV4hi7TO3G7QETE6G
> sm8AoLGNWfEYFAWbdkB0nzJELS5iOe7X
> =xncG
> -----END PGP SIGNATURE-----

[Nicolas Mailhot]

Le Lun 4 novembre 2013 20:15, Josh Boyer a écrit :
>  On Mon, Nov 4, 2013 at 2:01 PM, Stephen Gallagher
> <sgallagh(a)redhat.com&gt;
>  wrote:
> >> And, by the way, we've been supporting this kind of model with pip
> >> and gem already, so I really don't get why all the fuss when
> >> suddenly we want to do it with the desktop applications.
> >>
> >
> > Please don't use pip and gem as "positive" examples... they have a
> > habit of conflicting with the installed system that is an additional
> > problem we may hope to solve with this.
>
>  It's worth pointing out that they're positive examples to the
>  developers using them.  They want to work on their applications and
>  not have to fight against the distro's versions.  And those developers
>  are particularly the ones being targeted with containerized apps.  So
>  equating the two in a positive light probably isn't a bad idea.  Those
>  developers care about their apps.  They don't care about the distros. 
… till they have a customer that forces them to reinvent the deployment
processes distros standardised.

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 developpers. Let's stop pretending doing products
then. Be honest and admit you want a demo scene.

-- 
Nicolas Mailhot

[Josh Boyer]

On Mon, Nov 4, 2013 at 5:02 PM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net&gt; wrote:
>  Le Lun 4 novembre 2013 20:15, Josh Boyer a écrit :
> > On Mon, Nov 4, 2013 at 2:01 PM, Stephen Gallagher <sgallagh(a)redhat.com&gt;
> > wrote:
> >>> And, by the way, we've been supporting this kind of model with pip
> >>> and gem already, so I really don't get why all the fuss when
> >>> suddenly we want to do it with the desktop applications.
> >>>
> >>
> >> Please don't use pip and gem as "positive" examples... they have a
> >> habit of conflicting with the installed system that is an additional
> >> problem we may hope to solve with this.
> >
> > It's worth pointing out that they're positive examples to the
> > developers using them.  They want to work on their applications and
> > not have to fight against the distro's versions.  And those developers
> > are particularly the ones being targeted with containerized apps.  So
> > equating the two in a positive light probably isn't a bad idea.  Those
> > developers care about their apps.  They don't care about the distros.
>
>  … till they have a customer that forces them to reinvent the deployment
>  processes distros standardised.
>
>  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 developpers. Let's stop pretending doing products
>  then. Be honest and admit you want a demo scene. 
I want a stable base platform (aka the OS) that allows for people to
use it for development of interesting things (aka applications).  I
want that same platform to be usable by people to install interesting
things and us them.  I don't see a contradiction here that would force
one or the other, nor do I see how it reduces the product to a demo
scene.

If you want to reduce everything to absolutes, be my guest.  It will
get you a rock solid, well crafted distro that reaches a certain set
of people.  I'm interested in reaching more than just that set of
people.

josh

[Josh Boyer]

On Mon, Nov 4, 2013 at 8:26 PM, Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:
>  On Mon, Nov 4, 2013 at 5:02 PM, Nicolas Mailhot
>  <nicolas.mailhot(a)laposte.net&gt; wrote:
> >
> > Le Lun 4 novembre 2013 20:15, Josh Boyer a écrit :
> >> On Mon, Nov 4, 2013 at 2:01 PM, Stephen Gallagher <sgallagh(a)redhat.com&gt;
> >> wrote:
> >>>> And, by the way, we've been supporting this kind of model with pip
> >>>> and gem already, so I really don't get why all the fuss when
> >>>> suddenly we want to do it with the desktop applications.
> >>>>
> >>>
> >>> Please don't use pip and gem as "positive" examples... they
> have a
> >>> habit of conflicting with the installed system that is an additional
> >>> problem we may hope to solve with this.
> >>
> >> It's worth pointing out that they're positive examples to the
> >> developers using them.  They want to work on their applications and
> >> not have to fight against the distro's versions.  And those developers
> >> are particularly the ones being targeted with containerized apps.  So
> >> equating the two in a positive light probably isn't a bad idea.  Those
> >> developers care about their apps.  They don't care about the distros.
> >
> > … till they have a customer that forces them to reinvent the deployment
> > processes distros standardised.
> >
> > 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 developpers. Let's stop pretending doing products
> > then. Be honest and admit you want a demo scene.
>
>  I want a stable base platform (aka the OS) that allows for people to
>  use it for development of interesting things (aka applications).  I
>  want that same platform to be usable by people to install interesting
>  things and us them.  I don't see a contradiction here that would force
>  one or the other, nor do I see how it reduces the product to a demo
>  scene.
>
>  If you want to reduce everything to absolutes, be my guest.  It will
>  get you a rock solid, well crafted distro that reaches a certain set
>  of people.  I'm interested in reaching more than just that set of
>  people. 
Ugh.  Truly poor wording on my part in that last paragraph.

I meant to imply that if you want to ignore containerized apps and
continue to focus on an RPM only distro that is tightly integrated,
that's definitely something that can be done.  One could argue it's
what has been done in Fedora for the last 10 years, and it's worked
well more or less.  I do, however, think times are changing and I
don't think it's necessary to stick ONLY to that.  Figuring out a way
to do containerized application deployment in a controlled fashion is
something that has a lot of benefit if done correctly.  You don't have
to throw out the entire RPM model to add this on top.

josh

[Nicolas Mailhot]

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.

-- 
Nicolas Mailhot

[drago01]

On Tue, Nov 5, 2013 at 12:35 PM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net&gt; 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.

[Frank Murphy]

On Tue, 5 Nov 2013 12:53:15 +0100
drago01 <drago01(a)gmail.com&gt; wrote:

>  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. 
Maybe?
http://www.techterms.com/definition/poweruser

-- 
Regards,
Frank 
www.frankly3d.com

[drago01]

On Tue, Nov 5, 2013 at 12:58 PM, Frank Murphy <frankly3d(a)gmail.com&gt; wrote:
>  On Tue, 5 Nov 2013 12:53:15 +0100
>  drago01 <drago01(a)gmail.com&gt; wrote:
>
> > 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.
>
>  Maybe?
>  http://www.techterms.com/definition/poweruser 
This is mostly about having powerful hardware, which our users have
the freedom to buy and run fedora on.
Since we build software and not hardware it does not matter much.

[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" <drago01(a)gmail.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  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.mailhot(a)laposte.net&gt; 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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Kevin Kofler]

drago01 wrote:
>  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. 
A power user is somebody experienced with computers who uses them regularly 
and who wants to customize his/her system to his/her liking, not be forced 
into a straightjacket UI designed for people who have never touched a 
computer before that cannot be configured in any way. Software developers 
definitely fit into that category.

Nobody will spend their whole day in configuration dialogs. Even if they are 
many options, those dialogs are something you set your preferences in once 
and then (hopefully) never have to touch again. (Of course, if you change 
your defaults every day due to some "usability" study on complete newbies 
which totally ignores the habit factor, then yes, they would have to reenter 
the dialogs. But not offering the option does not help, it will just make 
the user curse at you for making him suffer an unwanted change to his/her 
habitual workflow or move to a software that gives him/her the option.) And 
offering the option does not preclude having sane defaults, which means only 
those people who WANT to change something even SEE the dialog at all. So the 
option does not hurt the people who are not looking for it, that claim is 
just not true.

In short: Make the defaults as sane as possible, but still allow the user to 
change them if they disagree with you on what is "sane". The more options, 
the better.

        Kevin Kofler

[Olav Vitters]

On Wed, Nov 06, 2013 at 12:59:00AM +0100, Kevin Kofler wrote:
>  In short: Make the defaults as sane as possible, but still allow the
> user to 
>  change them if they disagree with you on what is "sane". The more options, 
>  the better. 
The definition given by Frank Murphy is totally different and doesn't
align with above. Above also doesn't relate to developers.

-- 
Regards,
Olav

[Kevin Kofler]

Olav Vitters wrote:
>  The definition given by Frank Murphy is totally different and
> doesn't
>  align with above. Above also doesn't relate to developers. 
These align a lot with what I wrote though. :-)
http://en.wiktionary.org/wiki/power_user
http://en.wikipedia.org/wiki/Power_user

        Kevin Kofler

[drago01]

On Thu, Nov 7, 2013 at 3:41 AM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  Olav Vitters wrote:
> > The definition given by Frank Murphy is totally different and doesn't
> > align with above. Above also doesn't relate to developers.
>
>  These align a lot with what I wrote though. :-)
>  http://en.wiktionary.org/wiki/power_user
>  http://en.wikipedia.org/wiki/Power_user 
No it doesn't if you go by them a developer is not a "power user" and
neither of those really match your definition either.
So you all proved that is a meaningless term (i.e buzzword). So can we
go back to use proper use case definitions?
"I need X because I am a power user" makes no sense at all. "I need X
because it helps me do ....." is way better to work with.

[Josh Boyer]

On Tue, Nov 5, 2013 at 6:35 AM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net&gt; 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. 
Fortunately, the WG can highlight the areas in whatever software they
choose that need to be modified to accomplish the WG's goals.  And due
to the wonderfulness of open source, Fedora can make those changes.
Work with whatever upstream is in question to see if there are changes
that can be done in a manner that benefit both.  Basically,
collaboration and compromise are going to be required.

josh

[Frank Murphy]

On Tue, 5 Nov 2013 12:35:30 +0100
"Nicolas Mailhot" <nicolas.mailhot(a)laposte.net&gt; wrote:

>  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.
>   
Not all developers use Gnome,
if they did, the other DEs' would not exist (within Fedora).

-- 
Regards,
Frank 
www.frankly3d.com

[Matthias Clasen]

On Tue, 2013-11-05 at 12:35 +0100, Nicolas Mailhot 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. 
Why do you think the two sets of goals have to be one and the same ?

The Fedora Workstation effort (not a great name, by the way), is brand
new, and its goals have only just been drafted. How could the goals that
GNOME has followed in the past 3 years be perfectly align with it ? And
why should they, for that matter ? This is not a GNOME project, it is
about saving Fedora.

Fedora Workstation product name

[Matthew Miller]

On Tue, Nov 05, 2013 at 11:25:18AM -0500, Matthias Clasen wrote:
>  The Fedora Workstation effort (not a great name, by the way), is
> brand 
It doesn't have to end up with that name, for the record. That's just a
working title and indicative of the conversation at Flock. Peter Jones had
suggested "Fedora Client", and there were some others as well. 


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

Fedora Workstation product name

[Josh Boyer]

On Tue, Nov 5, 2013 at 4:00 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Tue, Nov 05, 2013 at 11:25:18AM -0500, Matthias Clasen wrote:
> > The Fedora Workstation effort (not a great name, by the way), is brand
>
>  It doesn't have to end up with that name, for the record. That's just a
>  working title and indicative of the conversation at Flock. Peter Jones had
>  suggested "Fedora Client", and there were some others as well. 
People long ago dropped desktop@ from the CC list on the thread you
took this from.  If there is a desire to debate and suggest new names
for the Workstation product, it should probably be done on desktop@
and not devel@.

Please start a new thread there.

josh

Fedora Workstation product name

[Jaroslav Reznik]

----- Original Message -----
>  On Tue, Nov 05, 2013 at 11:25:18AM -0500, Matthias Clasen wrote:
>  > The Fedora Workstation effort (not a great name, by the way), is brand
>  
>  It doesn't have to end up with that name, for the record. That's just a
>  working title and indicative of the conversation at Flock. Peter Jones had
>  suggested "Fedora Client", and there were some others as well. 
Can we go one level up - should even Fedora be a name of a product? With 
Server/Workstation/Cloud and other as variants? Or can we treat Fedora as
a project covering all different products using different names?

You don't use M*soft Server but W*ows Server produced by that company...

KDE guys tried this rebranding a long time ago, it never worked very well due
to miscommunication in the very beginnings (KDE SC...). I was involved in
discussion at Akademy with many red faces screaming "noo, don't do that,
noo"
but actually it makes sense. And even more sense to productised Fedora...

Jaroslav

>  
>  --
>  Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora Workstation product name

[drago01]

On Wed, Nov 6, 2013 at 1:22 PM, Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
>  ----- Original Message -----
> > On Tue, Nov 05, 2013 at 11:25:18AM -0500, Matthias Clasen wrote:
> > > The Fedora Workstation effort (not a great name, by the way), is brand
> >
> > It doesn't have to end up with that name, for the record. That's just a
> > working title and indicative of the conversation at Flock. Peter Jones had
> > suggested "Fedora Client", and there were some others as well.
>
>  Can we go one level up - should even Fedora be a name of a product? With
>  Server/Workstation/Cloud and other as variants? Or can we treat Fedora as
>  a project covering all different products using different names?
>
>  You don't use M*soft Server but W*ows Server produced by that company...
>
>  KDE guys tried this rebranding a long time ago, it never worked very well due
>  to miscommunication in the very beginnings (KDE SC...). I was involved in
>  discussion at Akademy with many red faces screaming "noo, don't do that,
> noo"
>  but actually it makes sense. And even more sense to productised Fedora... 
It kills a well known brand and all marketing efforts of the past. And
the KDE one
didn't really worked in the end everyone just calls it (the desktop) "KDE".

Fedora Workstation product name

[Jaroslav Reznik]

----- Original Message -----
>  On Wed, Nov 6, 2013 at 1:22 PM, Jaroslav Reznik
> <jreznik(a)redhat.com&gt; wrote:
>  > ----- Original Message -----
>  >> On Tue, Nov 05, 2013 at 11:25:18AM -0500, Matthias Clasen wrote:
>  >> > The Fedora Workstation effort (not a great name, by the way), is brand
>  >>
>  >> It doesn't have to end up with that name, for the record. That's just a
>  >> working title and indicative of the conversation at Flock. Peter Jones had
>  >> suggested "Fedora Client", and there were some others as well.
>  >
>  > Can we go one level up - should even Fedora be a name of a product? With
>  > Server/Workstation/Cloud and other as variants? Or can we treat Fedora as
>  > a project covering all different products using different names?
>  >
>  > You don't use M*soft Server but W*ows Server produced by that company...
>  >
>  > KDE guys tried this rebranding a long time ago, it never worked very well
>  > due
>  > to miscommunication in the very beginnings (KDE SC...). I was involved in
>  > discussion at Akademy with many red faces screaming "noo, don't do that,
>  > noo"
>  > but actually it makes sense. And even more sense to productised Fedora...
>  
>  It kills a well known brand and all marketing efforts of the past. 
Brand stays - it will be Fedora, or better Fedora Project as vendor. Just
product will have different names but can still contain Fedora in name.

>  And
>  the KDE one
>  didn't really worked in the end everyone just calls it (the desktop) "KDE".
I'm aware of that but as I said - it was due to communication/marketing
mistakes.

Jaroslav

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

Fedora Workstation product name

[Adam Williamson]

On Wed, 2013-11-06 at 08:31 -0500, Jaroslav Reznik wrote:

>  > And
>  > the KDE one
>  > didn't really worked in the end everyone just calls it (the desktop)
> "KDE".
>  
>  I'm aware of that but as I said - it was due to communication/marketing
>  mistakes. 
Eh, I wouldn't agree with that. I got the re-name message well enough
when it happened but I kept calling it KDE because, c'mon, it's fricking
KDE. It just *is* KDE. I think some names are solidly enough baked-in
that you can't really change them.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

Fedora Workstation product name

[drago01]

On Wed, Nov 6, 2013 at 9:29 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  On Wed, 2013-11-06 at 08:31 -0500, Jaroslav Reznik wrote:
>
> > > And
> > > the KDE one
> > > didn't really worked in the end everyone just calls it (the desktop)
> "KDE".
> >
> > I'm aware of that but as I said - it was due to communication/marketing
> > mistakes.
>
>  Eh, I wouldn't agree with that. I got the re-name message well enough
>  when it happened but I kept calling it KDE because, c'mon, it's fricking
>  KDE. It just *is* KDE. I think some names are solidly enough baked-in
>  that you can't really change them. 
Yeah and even the "Fedora Core" name took a long time to get out of
people's mind.
Even HP was referring to Fedora as "Fedora Core" in BIOS changelogs
years after we renamed it.

Fedora Workstation product name

[Kevin Kofler]

Jaroslav Reznik wrote:
>  Can we go one level up - should even Fedora be a name of a product?
> With
>  Server/Workstation/Cloud and other as variants? Or can we treat Fedora as
>  a project covering all different products using different names? 
Please no…

>  KDE guys tried this rebranding a long time ago, it never worked very
> well
>  due to miscommunication in the very beginnings (KDE SC...). I was involved
>  in discussion at Akademy with many red faces screaming "noo, don't do
>  that, noo" but actually it makes sense. And even more sense to productised
>  Fedora... 
No, it doesn't make sense. Never did, never will. As for the "KDE SC" thing,

they now discourage its use without offering any alternative at all, which 
just means people reverted to calling it just "KDE". (I know I did.) There's

no way people are going to write "the KDE Plasma Workspaces, the KDE 
Development Platform / Libraries / Frameworks / (whatever the term of the 
day is) and the KDE Applications (those that happen to release together with 
the other stuff)" every single time.

        Kevin Kofler

[Kevin Kofler]

Alberto Ruiz wrote:
>  Indeed, this is a relief to the distro community, suddenly you
> don't
>  have the burden of maintaining all these apps in your system image,
>  avoiding any potential problems on upgrades. 
At that point, we have rendered ourselves obsolete. Packaging the 
applications and ensuring they work well together with each other and with 
the core libraries is what a distro is for.

>  It also removes the pressure for the user to have to upgrade his/her
>  whole system just because they want the latest version of an app. 
That's why new applications should be available as updates unless there's a 
good reason not to. (In the KDE SIG, we're quite good at providing that. But 
our Fedora update policies need improvement to encourage that practice more. 
It's funny how the very GNOME people who vetoed a more flexible update 
policy now complain about this issue and use it as an excuse to sabotage our 
whole repository system! This is a problem of GNOME's own making.)

>  It also allows for parallel versions of an app, which means that to
> test
>  a beta version of, say,  LibreOffice, you don't need the beta version of
>  your whole operating system. 
And for that, dedicated third-party or PPA/COPR/OBS/… repositories for those 
beta apps on stable distro releases are the way to go (and in fact, the way 
it's done now, and it works fine, only our tooling in Fedora could use 
improvement to match what Launchpad PPAs or OBS repos provide). It can even 
work for stable updates if the maintainer is too stubborn to just push them 
(see e.g. Rex Dieter's pulseaudio-backport repository on 
repos.fedorapeople.org).

>  And the application developer suddenly gains back control on how and
>  when his app gets delivered to users. 
How's that a good thing? The developer should not have to worry about that, 
and the user should not be at the whims of a bazillion different upstreams 
with conflicting goals.

>  The only downside is that we are going to have to rewire our brains
> to
>  stop using yum/dnf to browse/install/remove end user desktop apps.
>  (This, I think, is why this idea gets so much pushback from the distro
>  communities) 
Well, yes, because you're throwing away all the technical advantages of 
using yum for that in favor of an inferior system!

>  And, by the way, we've been supporting this kind of model with
> pip and
>  gem already, so I really don't get why all the fuss when suddenly we
>  want to do it with the desktop applications. 
You shouldn't be installing pip/gem/… stuff directly, that's what -devel 
packages are for.

        Kevin Kofler

[Reindl Harald]

Am 04.11.2013 22:18, schrieb Kevin Kofler:
>  Alberto Ruiz wrote:
> > Indeed, this is a relief to the distro community, suddenly you don't
> > have the burden of maintaining all these apps in your system image,
> > avoiding any potential problems on upgrades.
>  
>  At that point, we have rendered ourselves obsolete. Packaging the 
>  applications and ensuring they work well together with each other and with 
>  the core libraries is what a distro is for. 
+1

> > It also removes the pressure for the user to have to upgrade
> his/her
> > whole system just because they want the latest version of an app.
>  
>  That's why new applications should be available as updates unless there's a 
>  good reason not to. (In the KDE SIG, we're quite good at providing that. But 
>  our Fedora update policies need improvement to encourage that practice more. 
>  It's funny how the very GNOME people who vetoed a more flexible update 
>  policy now complain about this issue and use it as an excuse to sabotage our 
>  whole repository system! This is a problem of GNOME's own making) 
+1

written from a F19 KDE 4.11.3 Desktop (Rex Dieters kde-testing and the packages are
also on Fedora koji, i guess the release announce from KDE upstream will go out
within the next few hours)

http://techbase.kde.org/Schedules/KDE4/4.11_Release_Schedule
November 5, 2013: KDE SC 4.11.3 release

Nov 02 20:38:16 Updated: 6:kdelibs-common-4.11.3-1.fc19.x86_64
Nov 02 20:38:19 Updated: 6:kdelibs-4.11.3-1.fc19.x86_64
Nov 02 20:38:21 Updated: kdepimlibs-kxmlrpcclient-4.11.3-1.fc19.x86_64
Nov 02 20:38:22 Updated: kdepimlibs-4.11.3-1.fc19.x86_64
Nov 02 20:38:23 Updated: kdepimlibs-akonadi-4.11.3-1.fc19.x86_64
Nov 02 20:38:23 Updated: kde-style-oxygen-4.11.3-1.fc19.x86_64
Nov 02 20:38:24 Updated: pykde4-4.11.3-1.fc19.x86_64
Nov 02 20:38:25 Updated: kde-dev-utils-kmtrace-4.11.3-1.fc19.x86_64
Nov 02 20:38:25 Updated: kde-dev-utils-kmtrace-libs-4.11.3-1.fc19.x86_64
Nov 02 20:38:30 Updated: kde-runtime-flags-4.11.3-1.fc19.noarch
Nov 02 20:38:30 Updated: kde-runtime-drkonqi-4.11.3-1.fc19.x86_64
Nov 02 20:38:33 Updated: kde-runtime-4.11.3-1.fc19.x86_64
Nov 02 20:38:34 Updated: kde-runtime-libs-4.11.3-1.fc19.x86_64
Nov 02 20:38:34 Updated: kde-print-manager-libs-4.11.3-1.fc19.x86_64
Nov 02 20:38:34 Updated: kde-print-manager-4.11.3-1.fc19.x86_64
Nov 02 20:38:41 Updated: kde-baseapps-libs-4.11.3-1.fc19.x86_64
Nov 02 20:38:42 Updated: kde-baseapps-4.11.3-1.fc19.x86_64
Nov 02 20:38:43 Updated: kde-workspace-libs-4.11.3-1.fc19.x86_64
Nov 02 20:38:47 Updated: kde-workspace-4.11.3-1.fc19.x86_64
Nov 02 20:38:48 Updated: kdeplasma-addons-4.11.3-1.fc19.x86_64
Nov 02 20:38:49 Updated: kdeplasma-addons-libs-4.11.3-1.fc19.x86_64
Nov 02 20:38:49 Updated: kde-l10n-4.11.3-1.fc19.noarch
Nov 02 20:38:54 Updated: kde-l10n-German-4.11.3-1.fc19.noarch
Nov 02 20:38:56 Updated: kdegraphics-thumbnailers-4.11.3-1.fc19.x86_64
Nov 02 20:38:57 Updated: kde-dev-utils-kpartloader-4.11.3-1.fc19.x86_64
Nov 02 20:38:57 Updated: kdesdk-kioslaves-4.11.3-1.fc19.x86_64

[Lars Seipel]

>  And the application developer suddenly gains back control on how and
>  when his app gets delivered to users. 
And this is supposed to be a good thing? Looking at much much crap
distro packagers had to fix in the past I really can't think of it as
that.

You then basically need all that container stuff just so you can be a
little less scared at some application developer's broken attempts to
"enhance your user experience" by installing suid-root helpers or stuff
like that.

[Bastien Nocera]

----- Original Message -----
>  > And the application developer suddenly gains back control on how
> and
>  > when his app gets delivered to users.
>  
>  And this is supposed to be a good thing? Looking at much much crap
>  distro packagers had to fix in the past I really can't think of it as
>  that.
>  
>  You then basically need all that container stuff just so you can be a
>  little less scared at some application developer's broken attempts to
>  "enhance your user experience" by installing suid-root helpers or stuff
>  like that. 
Which they wouldn't be able to because it'd be sandboxed...

[Kevin Kofler]

Bastien Nocera wrote:

[> Lars Seipel wrote:]
> > You then basically need all that container stuff just so you can
> be a
> > little less scared at some application developer's broken attempts to
> > "enhance your user experience" by installing suid-root helpers or stuff
> > like that.
>  
>  Which they wouldn't be able to because it'd be sandboxed... 
That's his point. We need all the overhead of a sandbox just to (attempt to) 
prevent apps from doing such nasty things, a problem we don't have in the 
world of trusted repositories.

        Kevin Kofler

[drago01]

On Mon, Nov 4, 2013 at 11:11 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  Bastien Nocera wrote:
>
>  [> Lars Seipel wrote:]
> >> You then basically need all that container stuff just so you can be a
> >> little less scared at some application developer's broken attempts to
> >> "enhance your user experience" by installing suid-root helpers or
> stuff
> >> like that.
> >
> > Which they wouldn't be able to because it'd be sandboxed...
>
>  That's his point. We need all the overhead of a sandbox just to (attempt to)
>  prevent apps from doing such nasty things, a problem we don't have in the
>  world of trusted repositories. 
Wrong.

Nothing prevents users from downloading and running stuff from the web
right now.  We have no sandbox.
You seem to think that unpackaged applications do not exist today
which is simply not the case.

[drago01]

On Mon, Nov 4, 2013 at 11:14 PM, drago01 <drago01(a)gmail.com&gt; wrote:
>  On Mon, Nov 4, 2013 at 11:11 PM, Kevin Kofler
> <kevin.kofler(a)chello.at&gt; wrote:
> > Bastien Nocera wrote:
> >
> > [> Lars Seipel wrote:]
> >>> You then basically need all that container stuff just so you can be a
> >>> little less scared at some application developer's broken attempts to
> >>> "enhance your user experience" by installing suid-root helpers or
> stuff
> >>> like that.
> >>
> >> Which they wouldn't be able to because it'd be sandboxed...
> >
> > That's his point. We need all the overhead of a sandbox just to (attempt to)
> > prevent apps from doing such nasty things, a problem we don't have in the
> > world of trusted repositories.
>
>  Wrong.
>
>  Nothing prevents users from downloading and running stuff from the web
>  right now.  We have no sandbox. 
Err "we have no sandbox so adding one would help not not hurt"

[Kevin Kofler]

Matthew Miller wrote:
>  The world has changed here. Whatever power we had to apply this kind
> of
>  pressure is shrinking. In the world of "fork us on github!", "getting
> into
>  a distro" really isn't that important to people anymore regardless of what
>  we do. 
Huh? How is github relevant to an end user at all? They do not care if the 
source code of their software comes from github, SourceForge or some lone 
developer's HDD. They get it all from a distro.

        Kevin Kofler

[Stephen Gallagher]

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

On 11/04/2013 04:01 PM, Kevin Kofler wrote:
>  Matthew Miller wrote:
> > The world has changed here. Whatever power we had to apply this
> > kind of pressure is shrinking. In the world of "fork us on
> > github!", "getting into a distro" really isn't that important to
> > people anymore regardless of what we do.
>  
>  Huh? How is github relevant to an end user at all? They do not care
>  if the source code of their software comes from github, SourceForge
>  or some lone developer's HDD. They get it all from a distro. 
That's really not true any more in a world built on top of Ruby,
Django, Node.js...

In most cases, the people using these technologies don't use the
distribution packages at all. They instead use 'rubgyem-install',
'easy_install/pip' and 'npm install'. The only thing they care about
from the distro (sometimes!) is having those tools present.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJ4ENwACgkQeiVVYja6o6Oj0wCgorHQckXYycPMzGN/J6vtg8CG
> GecAoIhVISGGIackg0zVtD6Fff3r11sD
> =vO0G
> -----END PGP SIGNATURE-----

[Reindl Harald]

Am 04.11.2013 22:25, schrieb Stephen Gallagher:
>  On 11/04/2013 04:01 PM, Kevin Kofler wrote:
> > Huh? How is github relevant to an end user at all? They do not care
> > if the source code of their software comes from github, SourceForge
> > or some lone developer's HDD. They get it all from a distro.
>  
>  That's really not true any more in a world built on top of Ruby,
>  Django, Node.js...
>  
>  In most cases, the people using these technologies don't use the
>  distribution packages at all. They instead use 'rubgyem-install',
>  'easy_install/pip' and 'npm install'. The only thing they care about
>  from the distro (sometimes!) is having those tools present 
who is "they"?
any countable numbers of "them"?

don't forget that you never have real numbers in case of a Linux
distribution and a few people telling you doing so is not "they"
in context of the real userbase

[Michael Scherer]

Le lundi 04 novembre 2013 à 23:16 +0100, Reindl Harald a écrit :
>  
>  Am 04.11.2013 22:25, schrieb Stephen Gallagher:
>  > On 11/04/2013 04:01 PM, Kevin Kofler wrote:
>  >> Huh? How is github relevant to an end user at all? They do not care
>  >> if the source code of their software comes from github, SourceForge
>  >> or some lone developer's HDD. They get it all from a distro.
>  > 
>  > That's really not true any more in a world built on top of Ruby,
>  > Django, Node.js...
>  > 
>  > In most cases, the people using these technologies don't use the
>  > distribution packages at all. They instead use 'rubgyem-install',
>  > 'easy_install/pip' and 'npm install'. The only thing they care
> about
>  > from the distro (sometimes!) is having those tools present
>  
>  who is "they"?
>  any countable numbers of "them"? 
I guess that the same countable numbers we can see in  "they get it all
from a distro". 

If I may, I would suggest that being a bit more consistent in your
critics would benefit your position.

>  don't forget that you never have real numbers in case of a Linux
>  distribution and a few people telling you doing so is not "they"
>  in context of the real userbase 
I was giving a talk at pycon.fr last week, and spend the 3 days
discussing with people. Most people I discussed with ( coders and
sysadmins alike ) were fully ok with using pip install, much to my
dismay as a Fedora member. 

And those are people that write free softwares, people who contribute to
the whole ecosystem, and people we want to help to write more free
software. 

maybe you think they do not matters and we shouldn't care and only focus
on your usecase, but I would disrespectfully disagree, despites the
energy you spent on this thread trying to restlessly convince people.

-- 
Michael Scherer

[Reindl Harald]

Am 05.11.2013 00:06, schrieb Michael Scherer:
>  Le lundi 04 novembre 2013 à 23:16 +0100, Reindl Harald a écrit :
> >
> > Am 04.11.2013 22:25, schrieb Stephen Gallagher:
> >> On 11/04/2013 04:01 PM, Kevin Kofler wrote:
> >>> Huh? How is github relevant to an end user at all? They do not care
> >>> if the source code of their software comes from github, SourceForge
> >>> or some lone developer's HDD. They get it all from a distro.
> >>
> >> That's really not true any more in a world built on top of Ruby,
> >> Django, Node.js...
> >>
> >> In most cases, the people using these technologies don't use the
> >> distribution packages at all. They instead use 'rubgyem-install',
> >> 'easy_install/pip' and 'npm install'. The only thing they care
> about
> >> from the distro (sometimes!) is having those tools present
> >
> > who is "they"?
> > any countable numbers of "them"?
>  
>  I guess that the same countable numbers we can see in  "they get it all
>  from a distro".  
you are missing the fact that you or whoever proposes the
status quo needs to be changed has to prove why and not
the other way around

>  If I may, I would suggest that being a bit more consistent in your
>  critics would benefit your position. 
i am more consistent than you imagine

if it ain#t broken don#t fix it
if it is wokring don't change it
if you say it is broken prove that it is broken before fix it

that is the way stable and for endusers good software is developed
not by change this and that and that also and look what happens by doing so

> > don't forget that you never have real numbers in case of a
> Linux
> > distribution and a few people telling you doing so is not "they"
> > in context of the real userbase
>  
>  I was giving a talk at pycon.fr last week, and spend the 3 days
>  discussing with people. Most people I discussed with ( coders and
>  sysadmins alike ) were fully ok with using pip install, much to my
>  dismay as a Fedora member.  
most likely these are the poeple re-install their systems every few years
i install a sytem once in 10 or 20 years or once for a lifetime
so far this works for 10 dist-upgrades
RPM and only RPm pakcages is a strong reason why this works

>  And those are people that write free softwares, people who contribute
> to
>  the whole ecosystem, and people we want to help to write more free
>  software.  
oh, now you switch from "for the users" to "for the developers"
interesting

>  maybe you think they do not matters and we shouldn't care and
> only focus
>  on your usecase, but I would disrespectfully disagree, despites the
>  energy you spent on this thread trying to restlessly convince people. 
what is "my usecase"?

my usecase is a 100% clean and stable system with painless upgrades over years
which is working fine until careless people start to damage it and no you will
not gain that big enuders base if you force them to re-install from scratch
twice a year, nobody doing more than read mail and open a webbrowser with his
system can do this - and RPM and a consistent package system is the key for
a really consistent at all

[Kevin Kofler]

Michael Scherer wrote:
>  I was giving a talk at pycon.fr last week, and spend the 3 days
>  discussing with people. Most people I discussed with ( coders and
>  sysadmins alike ) were fully ok with using pip install, much to my
>  dismay as a Fedora member. 
But those are not end users at all.

To the average user, Python is a snake and Ruby is Berlusconi's favorite 
callgirl.

        Kevin Kofler

[Kevin Kofler]

Stephen Gallagher wrote:
>  That's really not true any more in a world built on top of Ruby,
>  Django, Node.js...
>  
>  In most cases, the people using these technologies don't use the
>  distribution packages at all. They instead use 'rubgyem-install',
>  'easy_install/pip' and 'npm install'. The only thing they care about
>  from the distro (sometimes!) is having those tools present. 
If for you "end user" means "web developer"…

        Kevin Kofler

[Stephen Gallagher]

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

On 11/04/2013 05:32 PM, Kevin Kofler wrote:
>  Stephen Gallagher wrote:
> > That's really not true any more in a world built on top of Ruby, 
> > Django, Node.js...
> > 
> > In most cases, the people using these technologies don't use the 
> > distribution packages at all. They instead use
> > 'rubgyem-install', 'easy_install/pip' and 'npm install'. The
> only
> > thing they care about from the distro (sometimes!) is having
> > those tools present.
>  
>  If for you "end user" means "web developer"… 
tl;dr: Heavily-qualified "yes".


Well, that's circling back a bit to what we've stated we want from the
Fedora Workstation. (Note: I'm not on that WG). We called it
"Workstation" and not "Desktop" for a reason. When I first proposed
the three products, I wanted us to focus on the things that Fedora has
an opportunity to be great at.

We have some excellent desktop environments (and if you're curious,
I've spent time running most of them; I currently run a
heavily-extended GNOME, but I was using KDE 4 for about a year prior
to that), but while we're having flame-wars over which one is better
for which reason, we have a tendency to lose sight of why they exist
at all. The desktop environment is (to me) an extension of the concept
of the operating system. It should facilitate the work you want to get
done (whether that's actual work or putzing around on Youtube) and not
get in the way of that. For most users, all they really want out of
their desktop is the ability to run their desktop and web applications.

Now, the question we have to face is this (in my opinion): What set of
users are we as the Fedora Workstation going to go after? What group
can we define that is likely to use Fedora and ultimately be
interested in contributing to it, either directly (traditional
contributor) or by building applications and tools atop it.

I'd argue that the "general home user" ship has sailed. Most home
users are happy with their Windows, OSX, iOS or Android devices. That
last has even scooped up a sizeable chunk of the tinkerers and
open-source advocate folks. Targeting this group *right now* is not an
effective use of our time and effort. The desktop environment that
people get pre-installed on their Best Buy laptop is "good enough" for
that group of people.

So let's take a look at who are the users that might be in our reach.
In my mind, there are two groups (with differing needs, of course)
that we have the best chance of reaching. The first are the
traditional Fedora contributors; the people who are working on
delivering Fedora itself. I think it stands to reason that our
Workstation offering should directly benefit their ability to continue
developing Fedora (all of its products, base design and the
ecosystem). This is a place where we do a pretty good job now, at
least in part because it's a bit of a self-fulfilling prophecy.

The second group that we have an opportunity to capture are the people
who are doing the really "edgy" development today. These are the folks
that are using the toolchains we don't love because they don't fit
into our current model of how the world works. These people are
working primarily in web application development because it's the
easiest way for them to target the largest number of users. They don't
have to care if their users are running Windows, iOS or BeOS as long
as the user has a reasonably-compliant browser. This is a group of
developers that right now are developing in one of two ways: They're
developing on Ubuntu to deploy on Ubuntu or they're developing on OSX
to deploy on Ubuntu.

I'm trying in the Server WG to drive an answer to that deployment
problem (as is Matthew in the Cloud WG). What I'd like to see from the
Workstation group is an answer for how to draw people to *prefer* to
use Fedora for this purpose. I have mentioned this on other threads,
but it's not going to be good enough to *match* Ubuntu and OSX in this
space. We need to exceed their ability here. We need to be finding
ways to make Fedora the absolute easiest and *best* place to be trying
all of these new crazy ideas that are taking off.

I absolutely believe that there are risks here in the long run. Some
(many) of these applications are eventually going to succeed and these
developers are going to [re-]learn the difficulties of doing a stable
deployment with an unstable software stack. However, I'm really not
convinced that it's Fedora's place to try to teach them this lesson. I
think it should be our job to enable them to deliver their best new
ideas *right now* and let them figure out when it's time to re-examine
the stable deployment problem.

So this reply has gone on for quite some length, but I hope that I
have represented my position accurately.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJ4SEwACgkQeiVVYja6o6OshACfYaIuT1ZR6iB7yK0eo8pWXyMJ
> 6XgAnjvkSNoSB9ZB43SFdPv+OWzoGwd7
> =FG7p
> -----END PGP SIGNATURE-----

[Nicolas Mailhot]

Le Lun 4 novembre 2013 18:56, Matthew Miller a écrit :

>  The world has changed here. Whatever power we had to apply this kind
> of
>  pressure is shrinking. In the world of "fork us on github!", "getting
> into
>  a
>  distro" really isn't that important to people anymore regardless of what
>  we
>  do. 
I think you overestimate the power of github and are a victim of an echo
chamber effect. Groups of developers working on a specific tech and
agreeing with themselves in their own specific forums never implied
adoption outside their own circle (it's nothing new either: see .com
crash, java people insisting nothing was wrong while sun was sining, etc).
And this list can be cruel because it comprises people from lots of
different backgrounds and echo chamber "evidences" tend not to survive
long in a diverse environment.

-- 
Nicolas Mailhot

[Stephen Gallagher]

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

On 11/04/2013 12:39 PM, Kevin Kofler wrote:
>  Rahul Sundaram wrote:
> > You assume that sandboxed apps means we get all the negatives and
> > none of the benefits.  That is unwarranted.  We can adopt the
> > good parts and improve upon it based on the lessons learned from
> > adoption of app stores across multiple operating systems and
> > mobile devices that serve a much broader audience.  We should be
> > willing to let competent contributors who are interested in doing
> > that try it and provide useful feedback when necessary instead of
> > dismissing it on bad assumptions as a knee jerk reaction on our
> > experiences with proprietary software or bad conduct of 
> > particular companies.
>  
>  The reason we are so strongly opposed to app stores is that we are
>  fairly convinced that the mere fact of having them available WILL: 
>  * reduce the number of applications actually available in our
>  repositories (because some upstreams will just upload a bundle and
>  tell you to use that, and nobody will want to do the work of
>  actually getting the package through Fedora review), 
Sure, we probably would end up reducing the number of applications
available in the standard yum repos. I'm not as convinced as you are
that this is a bad thing. Right now, there's really no distinction
between what constitutes the operating system and what constitutes the
application ecosystem.

Given how complex and difficult navigating our packaging process is,
I'd be astonished if this didn't result in a large net gain for the
application ecosystem. Giving users access to the software they want
is the goal of an operating system. It's wonderful if we can
accomplish this with 100% technical purity, but unfortunately we live
in an imperfect universe where "perfect" is often the enemy of "good
enough".


>  * result in more applications adopting non-Free licenses (because
>  one of the big pressure factors to adopt an acceptable license has
>  always been to get into Fedora and Debian repositories – drop that
>  and people will just use whatever restrictive license terms they
>  can come up with), 

This just doesn't make sense at all. I highly doubt you could find
within 24 hours three upstream projects that made the choice to
license their code under a FOSS license for the sole reason that it
would be carried by Fedora or Debian (exempting of course any project
originating within Red Hat, Canonical or the other distribution sponsors).

Inclusion in the respository may be a goal for packages that are
already FOSS, but no one decides on a FOSS license just to be part of
Fedora.



>  * increase the number of applications that cost money (especially
>  if you offer a true app store, i.e. one which allows selling apps
>  in them – do you really expect that if you tell people that they
>  can sell apps in your store, they will not do it?) 

In other words, if people want to make a profit off of their own
personal hard work, they are not entitled to do so? I fail to see this
argument. Last I checked, every proper FOSS license permits the sale
of the software with or without support or warranty. Most of them also
permit anyone else to repackage and ship it with or without warranty
as well.

So if there was a FOSS project out there that was only available at
cost on an app store, I can pretty much guarantee that someone else
would just show up and repackage the source as the free version.
Honestly, I'd be expecting many upstreams to do that anyway: package a
free version and a pay version that was essentially the "donation"
button. "You can have it for free, but if you like it and want to help
us keep working on it, please buy this one..."


>  and thus, it is just not true that having the app store available
>  does not affect those of us who opt against using it. It WILL have
>  detrimental effects that will hurt all users. 

I don't think any of your arguments lead to that conclusion at all, sorry.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJ36E0ACgkQeiVVYja6o6OsUACfcci/2ovL2lA0Q50aLHmWj21R
> C14AoIR9uzNVTMR5hz7bao1i5t/dhasV
> =zGQJ
> -----END PGP SIGNATURE-----

[Bruno Wolff III]

On Mon, Nov 04, 2013 at 13:32:45 -0500,
   Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
> Inclusion in the respository may be a goal for packages that are
> already FOSS, but no one decides on a FOSS license just to be part of
> Fedora. 
I believe there have been some licenses changed to remove non-commercial 
or field of use restrictions in order to get into Fedora. I don't know 
that I could find three of them in 24 hours (wall clock time, not time 
spent searching) though.

[Reindl Harald]

Am 04.11.2013 19:32, schrieb Stephen Gallagher:
e, we probably would end up reducing the number of applications
>  available in the standard yum repos. I'm not as convinced as you
> are
>  that this is a bad thing. Right now, there's really no distinction
>  between what constitutes the operating system and what constitutes the
>  application ecosystem. 
*that* is the definition of a *distribution*

[Stephen Gallagher]

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

On 11/04/2013 02:01 PM, Reindl Harald wrote:
>  
>  
>  Am 04.11.2013 19:32, schrieb Stephen Gallagher: e, we probably
>  would end up reducing the number of applications
> > available in the standard yum repos. I'm not as convinced as you
> > are that this is a bad thing. Right now, there's really no
> > distinction between what constitutes the operating system and
> > what constitutes the application ecosystem.
>  
>  *that* is the definition of a *distribution* 
I don't think so. I think that's the definition of a *library*.

Let's say you want to build a boat. So you go to the library and you
dig through the thousands of books there until you find some on
carpentry, buoyancy principals and boat-building. You probably *can*
build a boat from this information, but that's not the purpose of
every book in the library.

A distribution would be more like going to an engineering college and
studying nautical engineering. Focused and dedicated to the task,
you'll probably produce a better boat in the end.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJ38mAACgkQeiVVYja6o6N6cQCePRm9NnCvX3ZRZ1PrdhPTHoxu
> 6DQAn2Y1PCtD/yA6P8826Z2qmruNUC0R
> =3l7y
> -----END PGP SIGNATURE-----

[Mateusz Marzantowicz]

On 04.11.2013 20:15, Stephen Gallagher wrote:
>  On 11/04/2013 02:01 PM, Reindl Harald wrote:
>  
>  
> > Am 04.11.2013 19:32, schrieb Stephen Gallagher: e, we probably
> > would end up reducing the number of applications
> >> available in the standard yum repos. I'm not as convinced as you
> >> are that this is a bad thing. Right now, there's really no
> >> distinction between what constitutes the operating system and
> >> what constitutes the application ecosystem.
>  
> > *that* is the definition of a *distribution*
>  
>  I don't think so. I think that's the definition of a *library*.
>  
>  Let's say you want to build a boat. So you go to the library and you
>  dig through the thousands of books there until you find some on
>  carpentry, buoyancy principals and boat-building. You probably *can*
>  build a boat from this information, but that's not the purpose of
>  every book in the library.
>  
>  A distribution would be more like going to an engineering college and
>  studying nautical engineering. Focused and dedicated to the task,
>  you'll probably produce a better boat in the end.
>  
>   
I don't get your example but I agree with Reindl Harald - Linux
Distribution is a set of software that works as one coherent
environment. Let it be 10, 100 or 100000000000 different packages but
they're chosen, compiled and adjusted to work together. This is the
strength of Linux as operating system.



Mateusz Marzantowicz

[Bastien Nocera]

----- Original Message -----
>  I don't get your example but I agree with Reindl Harald - Linux
>  Distribution is a set of software that works as one coherent
>  environment. Let it be 10, 100 or 100000000000 different packages but
>  they're chosen, compiled and adjusted to work together. This is the
>  strength of Linux as operating system. 
I'd like to see the QA matrix on that one...

[Adam Williamson]

On Mon, 2013-11-04 at 16:15 -0500, Bastien Nocera wrote:
>  
>  ----- Original Message -----
>  > I don't get your example but I agree with Reindl Harald - Linux
>  > Distribution is a set of software that works as one coherent
>  > environment. Let it be 10, 100 or 100000000000 different packages but
>  > they're chosen, compiled and adjusted to work together. This is the
>  > strength of Linux as operating system.
>  
>  I'd like to see the QA matrix on that one... 
It's hideous, but I suspect the QA matrix for sandboxed apps would be
even worse. Are you going to guarantee to me that the sandboxing will be
100% perfect - that we'll *never* have the case where a 'sandboxed' app
works on Ubuntu 13.04 but not on Fedora 18? Yeah, I didn't think so...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Bastien Nocera]

----- Original Message -----
>  On Mon, 2013-11-04 at 16:15 -0500, Bastien Nocera wrote:
>  > 
>  > ----- Original Message -----
>  > > I don't get your example but I agree with Reindl Harald - Linux
>  > > Distribution is a set of software that works as one coherent
>  > > environment. Let it be 10, 100 or 100000000000 different packages but
>  > > they're chosen, compiled and adjusted to work together. This is the
>  > > strength of Linux as operating system.
>  > 
>  > I'd like to see the QA matrix on that one...
>  
>  It's hideous, but I suspect the QA matrix for sandboxed apps would be
>  even worse. Are you going to guarantee to me that the sandboxing will be
>  100% perfect - that we'll *never* have the case where a 'sandboxed' app
>  works on Ubuntu 13.04 but not on Fedora 18? 
There's bugs in every software. But it should work. That's the aim.

>  Yeah, I didn't think so... 
Might not want to put answers in people's mouths. Did you read up on the
various bundling techniques that were explored and the API/ABI guarantees we
want to offer? I'll stop short of paraphrasing you.

[Kevin Kofler]

Bastien Nocera wrote:
>  Might not want to put answers in people's mouths. Did you read up
> on the
>  various bundling techniques that were explored and the API/ABI guarantees
>  we want to offer? I'll stop short of paraphrasing you. 
The fact that bundling is even being "explored" as a "technique" at
all 
makes me puke!

        Kevin Kofler

[Bastien Nocera]

----- Original Message -----
>  Bastien Nocera wrote:
>  > Might not want to put answers in people's mouths. Did you read up on the
>  > various bundling techniques that were explored and the API/ABI guarantees
>  > we want to offer? I'll stop short of paraphrasing you.
>  
>  The fact that bundling is even being "explored" as a "technique" at
> all
>  makes me puke! 
*plonk*

Can we remove that boy from the mailing-list? The level of discussion is worse
than 10 levels deep in a slashdot thread.

[Reindl Harald]

Am 06.11.2013 10:56, schrieb Bastien Nocera:
>  ----- Original Message -----
> > Bastien Nocera wrote:
> >> Might not want to put answers in people's mouths. Did you read up on the
> >> various bundling techniques that were explored and the API/ABI guarantees
> >> we want to offer? I'll stop short of paraphrasing you.
> >
> > The fact that bundling is even being "explored" as a "technique"
> at all
> > makes me puke!
>  
>  *plonk*
>  
>  Can we remove that boy from the mailing-list? The level of discussion is worse
>  than 10 levels deep in a slashdot thread. 
besides that it looks like you suggested to remove yourself due wrong
quoting "that boy" does a lot of hard work as packager and tries to
do it in a clean way without sloppy compromises for the sake of
future mainainment

maybe you do not care about KDE, but he as packager and many other does

http://koji.fedoraproject.org/koji/userinfo?userID=362

[Bastien Nocera]

----- Original Message -----
>  Am 06.11.2013 10:56, schrieb Bastien Nocera:
>  > ----- Original Message -----
>  >> Bastien Nocera wrote:
>  >>> Might not want to put answers in people's mouths. Did you read up on
> the
>  >>> various bundling techniques that were explored and the API/ABI guarantees
>  >>> we want to offer? I'll stop short of paraphrasing you.
>  >>
>  >> The fact that bundling is even being "explored" as a
> "technique" at all
>  >> makes me puke!
>  > 
>  > *plonk*
>  > 
>  > Can we remove that boy from the mailing-list? The level of discussion is
>  > worse
>  > than 10 levels deep in a slashdot thread.
>  
>  besides that it looks like you suggested to remove yourself due wrong
>  quoting "that boy" 
You'll have to blame the company provided Zimbra webmail for that.

>  does a lot of hard work as packager and tries to
>  do it in a clean way without sloppy compromises for the sake of
>  future mainainment
>  
>  maybe you do not care about KDE, but he as packager and many other does 
I'm sure we'd get another maintainer who doesn't feel entitled to reply
to emails with absurdities, flame baits and trolling.

[Olav Vitters]

On Wed, Nov 06, 2013 at 01:00:16AM +0100, Kevin Kofler wrote:
>  Bastien Nocera wrote:
>  > Might not want to put answers in people's mouths. Did you read up on the
>  > various bundling techniques that were explored and the API/ABI guarantees
>  > we want to offer? I'll stop short of paraphrasing you.
>  
>  The fact that bundling is even being "explored" as a "technique" at
> all 
>  makes me puke! 
That's offtopic.

-- 
Regards,
Olav

[Kevin Kofler]

Olav Vitters wrote:

>  On Wed, Nov 06, 2013 at 01:00:16AM +0100, Kevin Kofler wrote:
> > Bastien Nocera wrote:
> > > Might not want to put answers in people's mouths. Did you read up on
> > > the various bundling techniques that were explored and the API/ABI
> > > guarantees we want to offer? I'll stop short of paraphrasing you.
> > 
> > The fact that bundling is even being "explored" as a "technique"
> at all
> > makes me puke!
>  
>  That's offtopic. 
How is pointing out a fundamental unfixable flaw in the approach you are 
advocating off topic?

Do I need to rehash all the reasons why bundling sucks?
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

        Kevin Kofler

[Peter Robinson]

On 7 Nov 2013 03:20, "Kevin Kofler" <kevin.kofler(a)chello.at&gt; wrote:
>  Olav Vitters wrote:
>
>  > On Wed, Nov 06, 2013 at 01:00:16AM +0100, Kevin Kofler wrote:
>  >> Bastien Nocera wrote:
>  >> > Might not want to put answers in people's mouths. Did you read up on
>  >> > the various bundling techniques that were explored and the API/ABI
>  >> > guarantees we want to offer? I'll stop short of paraphrasing you.
>  >>
>  >> The fact that bundling is even being "explored" as a
> "technique" at all
>  >> makes me puke!
>  >
>  > That's offtopic.
>
>  How is pointing out a fundamental unfixable flaw in the approach you are
>  advocating off topic? 
Just because you can't see a way to fix it doesn't mean its either
unfixable or that there aren't people willing to step up to do so.

Peter

[Kevin Kofler]

Peter Robinson wrote:
>  Just because you can't see a way to fix it doesn't mean its
> either
>  unfixable or that there aren't people willing to step up to do so. 
It's not that I can't see a way to fix it, it's that I can see that there is 
no way! The whole system relies on bundling, so it is provably impossible to 
implement it without getting the nasty drawbacks of bundling.

        Kevin Kofler

[Olav Vitters]

On Thu, Nov 07, 2013 at 03:50:59AM +0100, Kevin Kofler wrote:
>  Olav Vitters wrote:
>  
>  > On Wed, Nov 06, 2013 at 01:00:16AM +0100, Kevin Kofler wrote:
>  >> Bastien Nocera wrote:
>  >> > Might not want to put answers in people's mouths. Did you read up on
>  >> > the various bundling techniques that were explored and the API/ABI
>  >> > guarantees we want to offer? I'll stop short of paraphrasing you.
>  >> 
>  >> The fact that bundling is even being "explored" as a
> "technique" at all
>  >> makes me puke!
>  > 
>  > That's offtopic.
>  
>  How is pointing out a fundamental unfixable flaw in the approach you are 
>  advocating off topic? 
You're pointing out that you want to puke. That's offtopic for this
mailing list. I rather not know the amount of detail that you're
displaying.

-- 
Regards,
Olav

[Stephen Gallagher]

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

On 11/04/2013 03:49 PM, Mateusz Marzantowicz wrote:
>  On 04.11.2013 20:15, Stephen Gallagher wrote:
> > On 11/04/2013 02:01 PM, Reindl Harald wrote:
> > 
> > 
> >> Am 04.11.2013 19:32, schrieb Stephen Gallagher: e, we probably 
> >> would end up reducing the number of applications
> >>> available in the standard yum repos. I'm not as convinced as
> >>> you are that this is a bad thing. Right now, there's really
> >>> no distinction between what constitutes the operating system
> >>> and what constitutes the application ecosystem.
> > 
> >> *that* is the definition of a *distribution*
> > 
> > I don't think so. I think that's the definition of a *library*.
> > 
> > Let's say you want to build a boat. So you go to the library and
> > you dig through the thousands of books there until you find some
> > on carpentry, buoyancy principals and boat-building. You probably
> > *can* build a boat from this information, but that's not the
> > purpose of every book in the library.
> > 
> > A distribution would be more like going to an engineering college
> > and studying nautical engineering. Focused and dedicated to the
> > task, you'll probably produce a better boat in the end.
> > 
> > 
>  
>  I don't get your example but I agree with Reindl Harald - Linux 
>  Distribution is a set of software that works as one coherent 
>  environment. Let it be 10, 100 or 100000000000 different packages
>  but they're chosen, compiled and adjusted to work together. This is
>  the strength of Linux as operating system.
>   
I'm pretty sure you're agreeing with me and not Reindl. His argument
is that it's the responsibility of the distribution to carry
everything all at once.

I'm arguing that it's perfectly acceptable to carry a
carefully-selected subset of things that define that distribution.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJ4EE0ACgkQeiVVYja6o6OVXQCgosZEzusNMy21X8gN7tqKCkyx
> /moAni5KWJv1gDzxpygCiMasNPdiv1fh
> =PxTt
> -----END PGP SIGNATURE-----

[Kevin Kofler]

Stephen Gallagher wrote:
>  Sure, we probably would end up reducing the number of applications
>  available in the standard yum repos. I'm not as convinced as you are
>  that this is a bad thing. Right now, there's really no distinction
>  between what constitutes the operating system and what constitutes the
>  application ecosystem.
>  
>  Given how complex and difficult navigating our packaging process is,
>  I'd be astonished if this didn't result in a large net gain for the
>  application ecosystem. Giving users access to the software they want
>  is the goal of an operating system. It's wonderful if we can
>  accomplish this with 100% technical purity, but unfortunately we live
>  in an imperfect universe where "perfect" is often the enemy of "good
>  enough". 
But the net result for the user would be:
* no more centralized updates – instead, either there are no automatic
  updates at all (most likely), or the software would have to poll every
  single software source for updates (slooooow),
* much more wasted disk space, due to bundling instead of dependency
  resolution,
* no more centralized security fixes for libraries (outside of the arbitrary
  "core set").
Thus, an overall negative.

>  This just doesn't make sense at all. I highly doubt you could
> find
>  within 24 hours three upstream projects that made the choice to
>  license their code under a FOSS license for the sole reason that it
>  would be carried by Fedora or Debian (exempting of course any project
>  originating within Red Hat, Canonical or the other distribution sponsors). 
Ask spot, he will certainly be able to name you many more than 3 such 
projects.

There were some high-profile examples of code getting relicensed due to 
distro pressure, e.g. the OpenGL-related code covered by the SGI Free 
Software License B (covered by a rewrite of the license thanks to the 
upgrade clause the original license had). Sun Microsystems (before being 
bought out by Oracle) has also relicensed more than one piece of software 
under our pressure (which often required a lot of nagging).

>  Inclusion in the respository may be a goal for packages that are
>  already FOSS, but no one decides on a FOSS license just to be part of
>  Fedora. 
I'm not even sure about that, but you also forget the many almost-free ones 
out there, who only removed the offending license terms due to pressure from 
Fedora and/or Debian.

>  So if there was a FOSS project out there that was only available at
>  cost on an app store, I can pretty much guarantee that someone else
>  would just show up and repackage the source as the free version. 
But see the previous point, the payware would NOT be FOSS, it'd be released 
under some restrictive license which does not allow you to redistribute it. 
So you wouldn't just be forced to pay, but also be deprived of your freedoms 
in the process.

        Kevin Kofler

[Stephen Gallagher]

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

On 11/04/2013 04:49 PM, Kevin Kofler wrote:
>  Stephen Gallagher wrote:
> > Sure, we probably would end up reducing the number of
> > applications available in the standard yum repos. I'm not as
> > convinced as you are that this is a bad thing. Right now, there's
> > really no distinction between what constitutes the operating
> > system and what constitutes the application ecosystem.
> > 
> > Given how complex and difficult navigating our packaging process
> > is, I'd be astonished if this didn't result in a large net gain
> > for the application ecosystem. Giving users access to the
> > software they want is the goal of an operating system. It's
> > wonderful if we can accomplish this with 100% technical purity,
> > but unfortunately we live in an imperfect universe where
> > "perfect" is often the enemy of "good enough".
>  
>  But the net result for the user would be: * no more centralized
>  updates – instead, either there are no automatic updates at all
>  (most likely), or the software would have to poll every single
>  software source for updates (slooooow), 

Or we build an ecosystem similar to an "app store" (which I hate using
because I would suggest that we only offer FOSS solutions through it).
These application could then package themselves as makes sense to
them, but still be offered via a single source with a single updates
stream.


>  * much more wasted disk space, due to bundling instead of
>  dependency resolution, 
Sure, I'll grant you that. However, this is a penalty that my
admittedly unscientific polling has shown to be acceptable in many
cases. While the advent of SSDs has reset the cash-for-gigabyte to a
decade ago, for the most part people don't really notice or care about
the few extra megabytes. That's not all people and we certainly should
strive not to be wasteful, but in my opinion there are places where we
can spend the same amount of effort to achieve a greater level of
success (where success is measured in the size of our app ecosystem
and our user base).


>  * no more centralized security fixes for libraries (outside of the
>  arbitrary "core set"). Thus, an overall negative.
>   
This is the part of your argument that I agree the most with. I come
from a security background; I worked on the SSSD and I've been a
coordinator with a number of upstream projects on how to properly deal
wth CVEs and responsible disclosure. So I agree that this would be a
decrease in overall security.

That said, I think there are ways we can minimize this. For one, we
can improve tooling in order to minimize these risks. While it's
unfortunate if we can't update a single component (xulrunner, for
example) to effect fixes to multiple other packages, we probably can
start maintaining a library of known bundles, that way we at least
know the majority of things that need patching when it comes to that.

Trust me, I've thought long and hard about this, and at the end of it
I finally came to this conclusion: People are doing this anyway. Many
of the popular projects out there are just opting to bundle and
distribute everything that they need in order to bypass distribution
limitations and get their code on more systems. For most of these
projects, we're never going to fix the situation, because there's
really no incentive for them: their current approach gets them on
Fedora, Ubuntu, maybe even the *BSDs.

If people are doing it anyway, we'll achieve better results by
facilitating that and helping them better track the bundles they are
shipping, rather than trying to bludgeon them into using a specific
version we decide to ship (which may be too old or too new).



> > This just doesn't make sense at all. I highly doubt you
> could
> > find within 24 hours three upstream projects that made the choice
> > to license their code under a FOSS license for the sole reason
> > that it would be carried by Fedora or Debian (exempting of course
> > any project originating within Red Hat, Canonical or the other
> > distribution sponsors).
>  
>  Ask spot, he will certainly be able to name you many more than 3
>  such projects.
>  
>  There were some high-profile examples of code getting relicensed
>  due to distro pressure, e.g. the OpenGL-related code covered by the
>  SGI Free Software License B (covered by a rewrite of the license
>  thanks to the upgrade clause the original license had). Sun
>  Microsystems (before being bought out by Oracle) has also
>  relicensed more than one piece of software under our pressure
>  (which often required a lot of nagging).
>   
Interesting. I will ask Tom about that. I still suspect this is more
the exception than the rule (and probably limited to "software that
Red Hat had a corporate interest in"), but I won't pretend to be able
to back that assertion up.


> > Inclusion in the respository may be a goal for packages that are
>
> > already FOSS, but no one decides on a FOSS license just to be
> > part of Fedora.
>  
>  I'm not even sure about that, but you also forget the many
>  almost-free ones out there, who only removed the offending license
>  terms due to pressure from Fedora and/or Debian.
>   
I'm not convinced that this is a situation that would be put at risk
by this idea. If they want to be part of the platform, they'd likely
still push for this.


> > So if there was a FOSS project out there that was only available
> > at cost on an app store, I can pretty much guarantee that someone
> > else would just show up and repackage the source as the free
> > version.
>  
>  But see the previous point, the payware would NOT be FOSS, it'd be
>  released under some restrictive license which does not allow you to
>  redistribute it. So you wouldn't just be forced to pay, but also be
>  deprived of your freedoms in the process.
>   
And we don't have to be willing to host it. That's one of the
strengths of an "app store" ecosystem: ultimately, the publisher
decides what is acceptable. If our philosophy is "FOSS-only" (and it
should be), then that's fine. If someone decides to set up a true
for-cash app store as well and enable it to work with Fedora, they can
do that anyway (and now). It still enables more people to consume the
platform we're shipping and gives us an opportunity to convert them to
the free versions of things. I see that as a victory.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJ4NyQACgkQeiVVYja6o6NVTwCfXcizchLq5Nv11fE4tDvuz71W
> BowAoIoqFb4L7iaBiMKepdcIW9ocKLrD
> =EJ9F
> -----END PGP SIGNATURE-----

[drago01]

On Sun, Nov 3, 2013 at 6:44 PM, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:

>  since it is a free operating system it does not need to be
> commerical
>  successfull and so it needs to satisfy it's *existing* and potential userbase
>  but not obsessive attrative for *everybody* 

No. If you loose to the competion you become irrelevant which means
less / no support from third parties, less (new) contributors etc etc.
So yes for the project to grow and succeed we should try to reach more users.

[Nicolas Mailhot]

Le Dim 3 novembre 2013 19:34, drago01 a écrit :
>  On Sun, Nov 3, 2013 at 6:44 PM, Reindl Harald
> <h.reindl(a)thelounge.net&gt;
>  wrote:
>
> > since it is a free operating system it does not need to be commerical
> > successfull and so it needs to satisfy it's *existing* and potential
> > userbase
> > but not obsessive attrative for *everybody*
>
>
>  No. If you loose to the competion you become irrelevant which means
>  less / no support from third parties, less (new) contributors etc etc. 
The competition worked hard at API stability. Even abandoned experiments
like silverlight are going to work identically for years in new os
versions.

GNOME decided to break it all the time (can't even get extensions work
from one gnome-shell version to the next one and no gracefully disabling
is still functional breakage).

And thus it 'lost to the competition'. No amount of indirection and
sandboxing is going to hide the utter lack of regard for stability of our
core desktop project

-- 
Nicolas Mailhot

[Florian Müllner]

On Mon, Nov 4, 2013 at 11:37 AM, Nicolas Mailhot <
nicolas.mailhot(a)laposte.net&gt; wrote:
>  GNOME decided to break it all the time (can't even get extensions
> work
>  from one gnome-shell version to the next one and no gracefully disabling
>  is still functional breakage). 
So what do you suggest? We can either

(1) restrict the functionality extension can provide (e.g. "add an icon
with a menu to the top bar" - of course that'd mean no alternate-tab,
shell-shape, alternative-status-menu etc.)

(2) cease development of gnome-shell

(1) will cause an understandable outrage as it would mean the end for a
large percentage of extensions, and (2) is not an option.

[Mateusz Marzantowicz]

On 04.11.2013 12:18, Florian Müllner wrote:
>  On Mon, Nov 4, 2013 at 11:37 AM, Nicolas Mailhot
>  <nicolas.mailhot(a)laposte.net <mailto:[e-mail]>> wrote:
> > GNOME decided to break it all the time (can't even get extensions work
> > from one gnome-shell version to the next one and no gracefully disabling
> > is still functional breakage).
>  
>  So what do you suggest? We can either
>  
>  (1) restrict the functionality extension can provide (e.g. "add an icon
>  with a menu to the top bar" - of course that'd mean no alternate-tab,
>  shell-shape, alternative-status-menu etc.)
>  
>  (2) cease development of gnome-shell
>  
>  (1) will cause an understandable outrage as it would mean the end for a
>  large percentage of extensions, and (2) is not an option.
>  
>  
>   
Just see how others does this. Linux Kernel is one example, Django is
another. This two projects from very different corners are able to
provide stable API/ABI for some longer time period. I really appreciate
your (GNOME devels) hard work but sometimes it is better to stop and
think for a moment about where we're going, than writing as much code as
one can handle and the remove it in next release.



Mateusz Marzantowicz

[Bryn M. Reeves]

On 11/04/2013 11:32 AM, Mateusz Marzantowicz wrote:
>  Just see how others does this. Linux Kernel is one example, Django
> is
>  another. This two projects from very different corners are able to
>  provide stable API/ABI for some longer time period. I really appreciate 
The kernel does not provide stable APIs. If you've ever tried to
maintain a non-trivial module or patch to the kernel out-of-tree for any
length of time you'll understand how much work is involved in just
keeping it working. Gnome shell extensions are not so different.

Regards,
Bryn.

[Lars Seipel]

On Mon, Nov 04, 2013 at 11:36:42AM +0000, Bryn M. Reeves wrote:
>  The kernel does not provide stable APIs. If you've ever tried to
>  maintain a non-trivial module or patch to the kernel out-of-tree for any
>  length of time you'll understand how much work is involved in just
>  keeping it working. Gnome shell extensions are not so different. 
True. They are also one of the least likely pieces of code I can imagine
running in some sort of isolated container. If we are talking
applications instead, the Linux syscall ABI is damn stable. Just as
there are userspace libraries that go to great lenghts to offer a stable
interface to their users.

If I, as an application developer, don't want my code to break every few
months I'd be well advised to pick my dependencies wisely and choose
libraries that offer me what I want (i.e. a stable interface) instead of
those that don't.  That's the proper solution. Not mindlessly bundling
everything together and expect others to keep it working somehow.

If we are missing stable libraries in parts of our stack that's a
problem to be fixed in upstream projects instead of being worked around
in the distribution.

So please don't let's pretend that containerizing apps with their
dependencies is anything more than a workaround, a stop-gap measure to
paper over other problems. And it does come with its costs, one of those
being tons of added complexity.

It's going the easy way instead of solving problems properly, upstream
in applications and libraries. Is it sensible in the context of Fedora
to do it anyhow? I don't know. I have my worries, though.

Lars

[drago01]

On Mon, Nov 4, 2013 at 2:44 PM, Lars Seipel <lars.seipel(a)gmail.com&gt; wrote:
>  On Mon, Nov 04, 2013 at 11:36:42AM +0000, Bryn M. Reeves wrote:
> > The kernel does not provide stable APIs. If you've ever tried to
> > maintain a non-trivial module or patch to the kernel out-of-tree for any
> > length of time you'll understand how much work is involved in just
> > keeping it working. Gnome shell extensions are not so different.
>
>  True. They are also one of the least likely pieces of code I can imagine
>  running in some sort of isolated container. If we are talking
>  applications instead, the Linux syscall ABI is damn stable. Just as
>  there are userspace libraries that go to great lenghts to offer a stable
>  interface to their users.
>
>  If I, as an application developer, don't want my code to break every few
>  months I'd be well advised to pick my dependencies wisely and choose
>  libraries that offer me what I want (i.e. a stable interface) instead of
>  those that don't.  That's the proper solution. Not mindlessly bundling
>  everything together and expect others to keep it working somehow. 
It is not only about stable ABIs but also what if you are using a feature added
in a new version of a library that is not in the target distro yet?
You'd be trying to
use the lowest common denominator which means you have to wait years until all
distros you care about ship the newer library.

[Kevin Kofler]

drago01 wrote:
>  You'd be trying to use the lowest common denominator which means
> you have
>  to wait years until all distros you care about ship the newer library. 
And how is this Fedora's problem? We don't take years to ship new libraries.

        Kevin Kofler

[Stephen Gallagher]

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

On 11/04/2013 02:17 PM, Kevin Kofler wrote:
>  drago01 wrote:
> > You'd be trying to use the lowest common denominator which means
> > you have to wait years until all distros you care about ship the
> > newer library.
>  
>  And how is this Fedora's problem? We don't take years to ship new
>  libraries.
>   
We have the opposite problem in many cases: we ship new libraries
months or years before people are ready for them in a lot of cases.
(Django updates come to mind).

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJ38yUACgkQeiVVYja6o6ML3gCeME3kqR9qJMpMqDZyMS5K3xkN
> t08AnRgGlLI4Q9WIJgm8har5hM+2PGLw
> =oWn5
> -----END PGP SIGNATURE-----

[drago01]

On Mon, Nov 4, 2013 at 8:17 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  drago01 wrote:
> > You'd be trying to use the lowest common denominator which means you have
> > to wait years until all distros you care about ship the newer library.
>
>  And how is this Fedora's problem? We don't take years to ship new libraries.
Read my mail again and try understand what is all about (hint: Fedora
is not the only distribution that exists).

[Reindl Harald]

Am 04.11.2013 20:26, schrieb drago01:
>  On Mon, Nov 4, 2013 at 8:17 PM, Kevin Kofler
> <kevin.kofler(a)chello.at&gt; wrote:
> > drago01 wrote:
> >> You'd be trying to use the lowest common denominator which means you have
> >> to wait years until all distros you care about ship the newer library.
> >
> > And how is this Fedora's problem? We don't take years to ship new libraries.
>  
>  Read my mail again and try understand what is all about (hint: Fedora
>  is not the only distribution that exists) 
and why do different distributions exist?
guess what: because they have different goals and userbases

otherwise we could join all distributions in a big one with
doing all but nothing good

i started to *really* use Fedora at a time where Ubuntu got
really popular and i took Fedora and built a ecosystem around
it because Fedora is waht it is - don't taint that

[Josh Boyer]

On Mon, Nov 4, 2013 at 2:34 PM, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
>  Am 04.11.2013 20:26, schrieb drago01:
> > On Mon, Nov 4, 2013 at 8:17 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
> >> drago01 wrote:
> >>> You'd be trying to use the lowest common denominator which means you
> have
> >>> to wait years until all distros you care about ship the newer library.
> >>
> >> And how is this Fedora's problem? We don't take years to ship new
> libraries.
> >
> > Read my mail again and try understand what is all about (hint: Fedora
> > is not the only distribution that exists)
>
>  and why do different distributions exist?
>  guess what: because they have different goals and userbases
>
>  otherwise we could join all distributions in a big one with
>  doing all but nothing good
>
>  i started to *really* use Fedora at a time where Ubuntu got
>  really popular and i took Fedora and built a ecosystem around
>  it because Fedora is waht it is - don't taint that 
The addition of a new piece of functionality does not immediately
taint or modify the core of what Fedora is.  Maybe instead of just
steadfastly asserting there should be no Change, you could work _with_
people as they try to include Change to address specific needs that
aren't being met.

Successful distros are evolutionary projects.  There is no "done" or
"final state" with them.  That doesn't mean they rip out the core
concepts and start over, but it does mean they adapt to new usecases
and challenges as they come up.

josh

[Reindl Harald]

Am 04.11.2013 20:43, schrieb Josh Boyer:
>  On Mon, Nov 4, 2013 at 2:34 PM, Reindl Harald
> <h.reindl(a)thelounge.net&gt; wrote:
> > and why do different distributions exist?
> > guess what: because they have different goals and userbases
> >
> > otherwise we could join all distributions in a big one with
> > doing all but nothing good
> >
> > i started to *really* use Fedora at a time where Ubuntu got
> > really popular and i took Fedora and built a ecosystem around
> > it because Fedora is waht it is - don't taint that
>  
>  The addition of a new piece of functionality does not immediately
>  taint or modify the core of what Fedora is.  Maybe instead of just
>  steadfastly asserting there should be no Change, you could work _with_
>  people as they try to include Change to address specific needs that
>  aren't being met.
>  
>  Successful distros are evolutionary projects.  There is no "done" or
>  "final state" with them.  That doesn't mean they rip out the core
>  concepts and start over, but it does mean they adapt to new usecases
>  and challenges as they come up 
that's all true but you can be pretty sure if a "app-store" with
bundeled applications exists *nobody* would package and maintain
them as RPM -> everybody would point with his finger to the app

if it goes in that direction, and it starts faster than anybody likes
you do a dramatical harm to the userbase which likes the consistent
package managment and *really used* conecpt of shared libraries

[drago01]

On Mon, Nov 4, 2013 at 8:49 PM, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
>  Am 04.11.2013 20:43, schrieb Josh Boyer:
> > On Mon, Nov 4, 2013 at 2:34 PM, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
> >> and why do different distributions exist?
> >> guess what: because they have different goals and userbases
> >>
> >> otherwise we could join all distributions in a big one with
> >> doing all but nothing good
> >>
> >> i started to *really* use Fedora at a time where Ubuntu got
> >> really popular and i took Fedora and built a ecosystem around
> >> it because Fedora is waht it is - don't taint that
> >
> > The addition of a new piece of functionality does not immediately
> > taint or modify the core of what Fedora is.  Maybe instead of just
> > steadfastly asserting there should be no Change, you could work _with_
> > people as they try to include Change to address specific needs that
> > aren't being met.
> >
> > Successful distros are evolutionary projects.  There is no "done" or
> > "final state" with them.  That doesn't mean they rip out the core
> > concepts and start over, but it does mean they adapt to new usecases
> > and challenges as they come up
>
>  that's all true but you can be pretty sure if a "app-store" with
>  bundeled applications exists *nobody* would package and maintain
>  them as RPM -> everybody would point with his finger to the app 
No because RPM packages apps *do* have benifits .. otherwise we
wouldn't have this discussion.

>  if it goes in that direction, and it starts faster than anybody
> likes
>  you do a dramatical harm to the userbase which likes the consistent
>  package managment and *really used* conecpt of shared libraries 
Again those are NOT MUTUALLY EXCLUSIVE. You can have sandboxed *and*
rpm packaged
apps at the same time.

[Reindl Harald]

Am 04.11.2013 20:56, schrieb drago01:
>  On Mon, Nov 4, 2013 at 8:49 PM, Reindl Harald
> <h.reindl(a)thelounge.net&gt; wrote:
> > that's all true but you can be pretty sure if a "app-store" with
> > bundeled applications exists *nobody* would package and maintain
> > them as RPM -> everybody would point with his finger to the app
>  
>  No because RPM packages apps *do* have benifits .. otherwise we
>  wouldn't have this discussion.
>  
> > if it goes in that direction, and it starts faster than anybody likes
> > you do a dramatical harm to the userbase which likes the consistent
> > package managment and *really used* conecpt of shared libraries
>  
>  Again those are NOT MUTUALLY EXCLUSIVE. You can have sandboxed *and*
>  rpm packaged apps at the same time. 
the most imporant word in your answer is *CAN*

but you will not, nobody will package whatever application
as RPM if he is fine with the app-store, so you *could*
have both but i doubt at the end of the day it will happen

[drago01]

On Mon, Nov 4, 2013 at 9:02 PM, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
>  Am 04.11.2013 20:56, schrieb drago01:
> > On Mon, Nov 4, 2013 at 8:49 PM, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
> >> that's all true but you can be pretty sure if a "app-store" with
> >> bundeled applications exists *nobody* would package and maintain
> >> them as RPM -> everybody would point with his finger to the app
> >
> > No because RPM packages apps *do* have benifits .. otherwise we
> > wouldn't have this discussion.
> >
> >> if it goes in that direction, and it starts faster than anybody likes
> >> you do a dramatical harm to the userbase which likes the consistent
> >> package managment and *really used* conecpt of shared libraries
> >
> > Again those are NOT MUTUALLY EXCLUSIVE. You can have sandboxed *and*
> > rpm packaged apps at the same time.
>
>  the most imporant word in your answer is *CAN*
>
>  but you will not, nobody will package whatever application
>  as RPM if he is fine with the app-store, so you *could*
>  have both but i doubt at the end of the day it will happen 
And I disagree ... but there is a way to find out ... lets try and see ;)

[Mateusz Marzantowicz]

On 04.11.2013 21:03, drago01 wrote:
>  On Mon, Nov 4, 2013 at 9:02 PM, Reindl Harald
> <h.reindl(a)thelounge.net&gt; wrote:
> >
> >
> > Am 04.11.2013 20:56, schrieb drago01:
> >> On Mon, Nov 4, 2013 at 8:49 PM, Reindl Harald <h.reindl(a)thelounge.net&gt;
> wrote:
> >>> that's all true but you can be pretty sure if a "app-store"
> with
> >>> bundeled applications exists *nobody* would package and maintain
> >>> them as RPM -> everybody would point with his finger to the app
> >>
> >> No because RPM packages apps *do* have benifits .. otherwise we
> >> wouldn't have this discussion.
> >>
> >>> if it goes in that direction, and it starts faster than anybody likes
> >>> you do a dramatical harm to the userbase which likes the consistent
> >>> package managment and *really used* conecpt of shared libraries
> >>
> >> Again those are NOT MUTUALLY EXCLUSIVE. You can have sandboxed *and*
> >> rpm packaged apps at the same time.
> >
> > the most imporant word in your answer is *CAN*
> >
> > but you will not, nobody will package whatever application
> > as RPM if he is fine with the app-store, so you *could*
> > have both but i doubt at the end of the day it will happen
>  
>  And I disagree ... but there is a way to find out ... lets try and see ;)
>   
After all there are other Linux distributions, so let's see if Fedora
survives this experiment. ;-)



Mateusz Marzantowicz

[Adam Williamson]

On Mon, 2013-11-04 at 21:03 +0100, drago01 wrote:
>  On Mon, Nov 4, 2013 at 9:02 PM, Reindl Harald
> <h.reindl(a)thelounge.net&gt; wrote:
>  >
>  >
>  > Am 04.11.2013 20:56, schrieb drago01:
>  >> On Mon, Nov 4, 2013 at 8:49 PM, Reindl Harald <h.reindl(a)thelounge.net&gt;
> wrote:
>  >>> that's all true but you can be pretty sure if a "app-store"
> with
>  >>> bundeled applications exists *nobody* would package and maintain
>  >>> them as RPM -> everybody would point with his finger to the app
>  >>
>  >> No because RPM packages apps *do* have benifits .. otherwise we
>  >> wouldn't have this discussion.
>  >>
>  >>> if it goes in that direction, and it starts faster than anybody likes
>  >>> you do a dramatical harm to the userbase which likes the consistent
>  >>> package managment and *really used* conecpt of shared libraries
>  >>
>  >> Again those are NOT MUTUALLY EXCLUSIVE. You can have sandboxed *and*
>  >> rpm packaged apps at the same time.
>  >
>  > the most imporant word in your answer is *CAN*
>  >
>  > but you will not, nobody will package whatever application
>  > as RPM if he is fine with the app-store, so you *could*
>  > have both but i doubt at the end of the day it will happen
>  
>  And I disagree ... but there is a way to find out ... lets try and see ;) 
That's rather a cavalier attitude. 

You seem to agree that the future Harald posits is at least a
possibility. If so, I think you, he and I would all agree it would be a
negative outcome in at least some respects. It is, therefore, a future
risk. It's not an easily reversible risk: we can't invent a sandboxed
app distribution mechanism, promote it as a blessed and 'supported'
method of app distribution for Fedora, and then suddenly say 'hey, wait,
that was a bad idea!' and take it away again. Or, rather, we could, but
that path would have its own negative consequences.

So: you, he and I all agree that the path your propose implies a risk.
You would also argue, I'm sure, that it may result in a benefit.

In this situation what we should do is carefully consider the relative
possibilities of the good, bad and mixed outcomes with as much precision
as we can, and try to come up with a path forward which makes the
likelihood of a good outcome as high as possible and the likelihood of a
bad outcome as low as possible. "Let's just try it and see what
happens!" is not a mature approach to risk management.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[drago01]

On Tue, Nov 5, 2013 at 9:56 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  On Mon, 2013-11-04 at 21:03 +0100, drago01 wrote:
> > On Mon, Nov 4, 2013 at 9:02 PM, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
> > >
> > >
> > > Am 04.11.2013 20:56, schrieb drago01:
> > >> On Mon, Nov 4, 2013 at 8:49 PM, Reindl Harald <h.reindl(a)thelounge.net&gt;
> wrote:
> > >>> that's all true but you can be pretty sure if a
> "app-store" with
> > >>> bundeled applications exists *nobody* would package and maintain
> > >>> them as RPM -> everybody would point with his finger to the app
> > >>
> > >> No because RPM packages apps *do* have benifits .. otherwise we
> > >> wouldn't have this discussion.
> > >>
> > >>> if it goes in that direction, and it starts faster than anybody likes
> > >>> you do a dramatical harm to the userbase which likes the consistent
> > >>> package managment and *really used* conecpt of shared libraries
> > >>
> > >> Again those are NOT MUTUALLY EXCLUSIVE. You can have sandboxed *and*
> > >> rpm packaged apps at the same time.
> > >
> > > the most imporant word in your answer is *CAN*
> > >
> > > but you will not, nobody will package whatever application
> > > as RPM if he is fine with the app-store, so you *could*
> > > have both but i doubt at the end of the day it will happen
> >
> > And I disagree ... but there is a way to find out ... lets try and see ;)
>
>  That's rather a cavalier attitude.
>
>  You seem to agree that the future Harald posits is at least a
>  possibility. 
No I don't. I just think that at this point the best way to prove that
to him is simply to show it how it works out in practice.

I still don't get why we have to argue that much about something like
this .. is giving upstreams a well defined way how to ship there
applications instead of letting them come up with a hack really that
bad?
Upstreams will always (and always had) seek was to do that .. simply
because there is demand. No one is forcing anyone to install such
apps.

[Olav Vitters]

On Tue, Nov 05, 2013 at 12:56:47PM -0800, Adam Williamson wrote:
>  bad outcome as low as possible. "Let's just try it and see
> what
>  happens!" is not a mature approach to risk management. 
Ehr, instead of promoting something as supported, just start off slow.
Call if alpha, write down all the concerns, etc. Announcing this as the
new supported + preferred way is not what is intended IMO.

Your post effectively read as stop energy IMO. It is impossible to get
everything right at the first version. Just ensure everyones expectation
is correct. Call it experimental + alpha initially.

Various concerns have been raised. Just write them down, make a plan to
address them, done.

-- 
Regards,
Olav

[Adam Williamson]

On Tue, 2013-11-05 at 22:15 +0100, Olav Vitters wrote:
>  On Tue, Nov 05, 2013 at 12:56:47PM -0800, Adam Williamson wrote:
>  > bad outcome as low as possible. "Let's just try it and see what
>  > happens!" is not a mature approach to risk management.
>  
>  Ehr, instead of promoting something as supported, just start off slow.
>  Call if alpha, write down all the concerns, etc. Announcing this as the
>  new supported + preferred way is not what is intended IMO.
>  
>  Your post effectively read as stop energy IMO. It is impossible to get
>  everything right at the first version. Just ensure everyones expectation
>  is correct. Call it experimental + alpha initially.
>  
>  Various concerns have been raised. Just write them down, make a plan to
>  address them, done. 
What I'm trying to do is contribute to ensuring that happens. As I wrote
in another post, I've always thought it'd be great if distros could
collaborate on a single approved framework/channel for third party
software releases (preferably before Valve does it for us). But it
definitely _does_ need to be the case that this is done carefully and
with a clear decision made on to what extent we choose to 'bless' this
mechanism in comparison to the distro repositories.

Essentially I'm trying to make the point that this is an extremely
sensitive issue which has the potential to cause long-term and
non-reversible changes to software distribution paradigms we've been
using for decades, so it needs to be handled carefully and with an
appreciation of all the consequences, not just with a 'hey, let's build
it, slap together some press about it and see what happens' kind of
attitude...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Kevin Kofler]

Olav Vitters wrote:
>  Various concerns have been raised. Just write them down, make a plan
> to
>  address them, done. 
But many of those concerns are inherent to the concept of "sandboxed 
applications" or the methods of delivery they'd enable and cannot possibly 
be addressed, ever. The whole concept is fatally flawed.

        Kevin Kofler

[Olav Vitters]

On Wed, Nov 06, 2013 at 01:25:29AM +0100, Kevin Kofler wrote:
>  But many of those concerns are inherent to the concept of
> "sandboxed 
>  applications" or the methods of delivery they'd enable and cannot possibly 
>  be addressed, ever. The whole concept is fatally flawed. 
I'd suggest trying a different hat than just black.

http://en.wikipedia.org/wiki/Six_Thinking_Hats

Suggest to also think of how to address concerns. At the moment, it
seems you want to bribe programs to accept a complicated and long
process (distributions) because the alternative might be too easy
(apps).

This highlights a concern, not a "fatal flaw". The flaw IMO is within
the distribution method. It takes a long time and currently there is
nothing that makes it easy. Luckily there is no other method at the
moment to archive that.

Say you have this new application and you want to provide it to (most)
Linux users *now* (not 6+ months later). There should be an answer for
that.

-- 
Regards,
Olav

[Miloslav Trmač]

On Wed, Nov 6, 2013 at 3:04 PM, Olav Vitters <olav(a)vitters.nl&gt; wrote:
>  This highlights a concern, not a "fatal flaw". The flaw IMO
> is within
>  the distribution method. 
No, the fatal flaw is that we don't really have an OS one can build
applications on: the ABI is unstable and insufficient.  So the choices
are either constantly rebuilding and patching (what distributions do)
or bundling (what non-distribution mechanisms do).


>  Say you have this new application and you want to provide it to
> (most)
>  Linux users *now* (not 6+ months later). There should be an answer for
>  that. 
Letting developers provide a custom application format is not actually
solving this: the difficult part is not making something "available on
the internet", but making it "reachable by the users".  This, in
practice, always ends up as one or a very small number of centralized
places - _the_ distribution, _the_ app store, _the_ amazon.com.  And
the difficulty of getting a set of bits to amazon.com / an app store /
a RPM is very similar.
    Mirek

[Olav Vitters]

On Wed, Nov 06, 2013 at 07:26:48PM +0100, Miloslav Trmač wrote:
>  places - _the_ distribution, _the_ app store, _the_ amazon.com.  And
>  the difficulty of getting a set of bits to amazon.com / an app store /
>  a RPM is very similar. 
If one will immediately solve it for multiple distributions, then the
gain is immensely higher. An IMO, it is not about RPM vs another
packaging format. To get into Fedora, you need an account, reviews, etc.
It is a pretty long process.

This hopefully is much quicker with greater results.

-- 
Regards,
Olav

[Sergio Pascual]

2013/11/6 Olav Vitters <olav(a)vitters.nl&gt;

>  If one will immediately solve it for multiple distributions, then
> the
>  gain is immensely higher. An IMO, it is not about RPM vs another
>  packaging format. To get into Fedora, you need an account, reviews, etc.
>  It is a pretty long process.
>  
Has this "sanboxed-bundled-from-upstream"  proposal been discussed with
other distributions? If the final result is that the "Universal Linux
Package" only works in Fedora we are not gaining anything.

[Olav Vitters]

On Wed, Nov 06, 2013 at 10:55:30PM +0100, Sergio Pascual wrote:
>  Has this "sanboxed-bundled-from-upstream"  proposal been
> discussed with
>  other distributions? If the final result is that the "Universal Linux
>  Package" only works in Fedora we are not gaining anything. 
A lot of this is being based on technology that's not really available
yet such as kdbus, Wayland, systemd bits. This has been discussed at
GUADEC (GNOME conference):
http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome

AFAIK (not sure), it should come somewhat easy once you the distribution
is based upon systemd. I assume Lennart will talk about it at various
conferences. For e.g. Mageia, the focus is currently on releasing Mageia
4. Features for Mageia 5 is later, so probably discuss it at FOSDEM
(beginning of Feb).

-- 
Regards,
Olav

[Kevin Kofler]

Olav Vitters wrote:
>  AFAIK (not sure), it should come somewhat easy once you the
> distribution
>  is based upon systemd. 
That means it will exclude the most popular distribution out there.

        Kevin Kofler

[Olav Vitters]

On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote:
>  Olav Vitters wrote:
>  > AFAIK (not sure), it should come somewhat easy once you the distribution
>  > is based upon systemd.
>  
>  That means it will exclude the most popular distribution out there. 
I fail to see the point of discussing non-Fedora distributions on Fedora
devel mailing list. If you want to discuss GNOME, we also have a
development list, see
https://mail.gnome.org/mailman/listinfo/desktop-devel-list. A bit more
logical to include people who actually work on this and less annoying to
people who don't want to discuss other distributions on the Fedora
mailing list.

-- 
Regards,
Olav

[Sergio Pascual]

2013/11/7 Olav Vitters <olav(a)vitters.nl&gt;

>  On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote:
>  > Olav Vitters wrote:
>  > > AFAIK (not sure), it should come somewhat easy once you the
>  distribution
>  > > is based upon systemd.
>  >
>  > That means it will exclude the most popular distribution out there.
>
>  I fail to see the point of discussing non-Fedora distributions on Fedora
>  devel mailing list. 

I fail to see the point of discussing a feature that is meant to allow
upstreams to provide installable bundles that work in all linuxes if it is
only to work in Fedora.

[Olav Vitters]

On Thu, Nov 07, 2013 at 11:33:57AM +0100, Sergio Pascual wrote:
>  2013/11/7 Olav Vitters <olav(a)vitters.nl&gt;
>  
>  > On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote:
>  > > Olav Vitters wrote:
>  > > > AFAIK (not sure), it should come somewhat easy once you the
>  > distribution
>  > > > is based upon systemd.
>  > >
>  > > That means it will exclude the most popular distribution out there.
>  >
>  > I fail to see the point of discussing non-Fedora distributions on Fedora
>  > devel mailing list.
>  
>  I fail to see the point of discussing a feature that is meant to allow
>  upstreams to provide installable bundles that work in all linuxes if it is
>  only to work in Fedora. 
I already talked about other distributions so your concern has been
addressed already.

-- 
Regards,
Olav

[Kevin Kofler]

Olav Vitters wrote:

>  On Thu, Nov 07, 2013 at 11:33:57AM +0100, Sergio Pascual wrote:
> > 2013/11/7 Olav Vitters <olav(a)vitters.nl&gt;
> > 
> > > On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote:
> > > > Olav Vitters wrote:
> > > > > AFAIK (not sure), it should come somewhat easy once you the
> > > distribution
> > > > > is based upon systemd.
> > > >
> > > > That means it will exclude the most popular distribution out there.
> > >
> > > I fail to see the point of discussing non-Fedora distributions on
> > > Fedora devel mailing list.
> > 
> > I fail to see the point of discussing a feature that is meant to allow
> > upstreams to provide installable bundles that work in all linuxes if it
> > is only to work in Fedora.
>  
>  I already talked about other distributions so your concern has been
>  addressed already. 
But I pointed out that you are leaving out the most popular one, and you 
responded by labeling me as off-topic when actually YOU were the one who 
started talking about other distributions.

You advertise distribution-independent packages, so your packages really 
need to work on ALL distributions. Assuming systemd is already a non-
starter.

IMHO, trying to support cross-distro packages is a failed endeavour from the 
outstart, Fedora RPMs are the way to go.

        Kevin Kofler

[Frank Murphy]

On Thu, 7 Nov 2013 11:17:28 +0100
Olav Vitters <olav(a)vitters.nl&gt; wrote:

>  On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote:
>  > Olav Vitters wrote:
>  > > AFAIK (not sure), it should come somewhat easy once you the
>  > > distribution is based upon systemd.
>  > 
>  > That means it will exclude the most popular distribution out
>  > there.
>  
>  I fail to see the point of discussing non-Fedora distributions on
>  Fedora devel mailing list. If you want to discuss GNOME, we also
>  have a development list, see
>  https://mail.gnome.org/mailman/listinfo/desktop-devel-list. 
To be fair you introduced Guadec, aka Gnome developemt.
(I'm not pro\anti Gnome)

>  A bit more logical to include people who actually work on this and
>  less annoying to people who don't want to discuss other
>  distributions on the Fedora mailing list.
>   
May it be loosely to cover target audience,
Why are they using distro X, 
is what the wg is doing going to win them over?


-- 
Regards,
Frank 
www.frankly3d.com

[Olav Vitters]

On Thu, Nov 07, 2013 at 10:45:29AM +0000, Frank Murphy wrote:
>  On Thu, 7 Nov 2013 11:17:28 +0100
>  Olav Vitters <olav(a)vitters.nl&gt; wrote:
>  
>  > On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote:
>  > > Olav Vitters wrote:
>  > > > AFAIK (not sure), it should come somewhat easy once you the
>  > > > distribution is based upon systemd.
>  > > 
>  > > That means it will exclude the most popular distribution out
>  > > there.
>  > 
>  > I fail to see the point of discussing non-Fedora distributions on
>  > Fedora devel mailing list. If you want to discuss GNOME, we also
>  > have a development list, see
>  > https://mail.gnome.org/mailman/listinfo/desktop-devel-list.
>  
>  To be fair you introduced Guadec, aka Gnome developemt.
>  (I'm not pro\anti Gnome) 
I explained that this thought has been discussed and introduced at a
conference.

If people cannot the mention of GNOME: not my problem.

-- 
Regards,
Olav

[Nicolas Mailhot]

Le Jeu 7 novembre 2013 11:17, Olav Vitters a écrit :
>  On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote:
> > Olav Vitters wrote:
> > > AFAIK (not sure), it should come somewhat easy once you the
> > distribution
> > > is based upon systemd.
> >
> > That means it will exclude the most popular distribution out there.
>
>  I fail to see the point of discussing non-Fedora distributions on Fedora
>  devel mailing list. If you want to discuss GNOME, we also have a
>  development list, see
>  https://mail.gnome.org/mailman/listinfo/desktop-devel-list. A bit more
>  logical to include people who actually work on this and less annoying to
>  people who don't want to discuss other distributions on the Fedora
>  mailing list. 
I fail to see the point of discussing non-GNOME-specific problems on a
GNOME development list. A bit more logical to include people who actually
work on non-GNOME software and don't want to discuss non-GNOME app
distribution on a GNOME list.

Really, why do I have to write this at all? Fedora Workstation is not
GNOME, that has already bee written in this thread.

-- 
Nicolas Mailhot

[Olav Vitters]

On Thu, Nov 07, 2013 at 02:28:09PM +0100, Nicolas Mailhot wrote:
>  I fail to see the point of discussing non-GNOME-specific problems on
> a
>  GNOME development list. A bit more logical to include people who actually
>  work on non-GNOME software and don't want to discuss non-GNOME app
>  distribution on a GNOME list. 
As mentioned, I said the interested people are on that mailing list.
Anyway, if you want to discuss another distribution on Fedora mailing
list, I think it is stupid and pointless, but that is just my opinion.

-- 
Regards,
Olav

[Lennart Poettering]

On Thu, 07.11.13 03:53, Kevin Kofler (kevin.kofler(a)chello.at) wrote:

>  Olav Vitters wrote:
>  > AFAIK (not sure), it should come somewhat easy once you the distribution
>  > is based upon systemd.
>  
>  That means it will exclude the most popular distribution out there. 
If you are referring to Ubuntu, then yes. But then again, they already
have their own app packaging format based around .debs and
AppArmor. So yeah, we might be dicks by not supporting non-systemd
systems, but they were dicks first, by not supporting non-Ubuntu systems
for their app images. And that's quite some consolation, no? ;-)

Lennart

-- 
Lennart Poettering, Red Hat

[Miloslav Trmač]

On Thu, Nov 7, 2013 at 4:15 PM, Lennart Poettering <mzerqung(a)0pointer.de&gt; wrote:
>  On Thu, 07.11.13 03:53, Kevin Kofler (kevin.kofler(a)chello.at) wrote:
>
> > Olav Vitters wrote:
> > > AFAIK (not sure), it should come somewhat easy once you the distribution
> > > is based upon systemd.
> >
> > That means it will exclude the most popular distribution out there.
>
>  If you are referring to Ubuntu, then yes. But then again, they already
>  have their own app packaging format based around .debs and
>  AppArmor. So yeah, we might be dicks by not supporting non-systemd
>  systems, but they were dicks first, by not supporting non-Ubuntu systems
>  for their app images. And that's quite some consolation, no? ;-) 
No, calling each other dicks is overall not at all consoling.

Is there a technical reason why we can't use their packaging format,
interpreting it with our technologies but staying compatible?
    Mirek

[Lennart Poettering]

On Thu, 07.11.13 20:09, Miloslav Trmač (mitr(a)volny.cz) wrote:

>  On Thu, Nov 7, 2013 at 4:15 PM, Lennart Poettering
> <mzerqung(a)0pointer.de&gt; wrote:
>  > On Thu, 07.11.13 03:53, Kevin Kofler (kevin.kofler(a)chello.at) wrote:
>  >
>  >> Olav Vitters wrote:
>  >> > AFAIK (not sure), it should come somewhat easy once you the distribution
>  >> > is based upon systemd.
>  >>
>  >> That means it will exclude the most popular distribution out there.
>  >
>  > If you are referring to Ubuntu, then yes. But then again, they already
>  > have their own app packaging format based around .debs and
>  > AppArmor. So yeah, we might be dicks by not supporting non-systemd
>  > systems, but they were dicks first, by not supporting non-Ubuntu systems
>  > for their app images. And that's quite some consolation, no? ;-)
>  
>  No, calling each other dicks is overall not at all consoling.
>  
>  Is there a technical reason why we can't use their packaging format,
>  interpreting it with our technologies but staying compatible? 
Well, the most relevant bit is that they use apparmor for
sandboxing. Nobody else uses that.

And I don't think it is a good idea to use .deb as an image format.

So if the format on disk, and the execution runtime is totally different
for us and for them, there's little to share.

Lennart

-- 
Lennart Poettering, Red Hat

[Miloslav Trmač]

On Thu, Nov 7, 2013 at 9:48 PM, Lennart Poettering <mzerqung(a)0pointer.de&gt; wrote:
>  On Thu, 07.11.13 20:09, Miloslav Trmač (mitr(a)volny.cz) wrote:
> > Is there a technical reason why we can't use their packaging format,
> > interpreting it with our technologies but staying compatible?
>
>  Well, the most relevant bit is that they use apparmor for
>  sandboxing. Nobody else uses that. 
Are the packages expected to ship their own apparmor policy?  That
would appear to be at odds with the idea of protecting against
malicious packages.  If they aren't expected to ship their own, could
we implement the same sandboxing policy using SELinux?
(https://wiki.ubuntu.com/AppDevUploadProcess seems to suggest Ubuntu
will be using some higher-level "profile" format, not raw AppArmor.)

>  And I don't think it is a good idea to use .deb as an image
> format. 
.deb is just an ar archive; if this were the only difference, it would
not be worth fragmenting the ecosystem over IMHO.  (Especially if the
GNOME apps alternative is a "compressed disk image", which saves disk
space and costs extra CPU time and memory, making exactly the wrong
tradeoff in most situations AFAICS.)
    Mire

[Michael Scherer]

On Thu, Nov 07, 2013 at 09:55:12PM +0100, Miloslav Trmač wrote:
>  On Thu, Nov 7, 2013 at 9:48 PM, Lennart Poettering
> <mzerqung(a)0pointer.de&gt; wrote:
>  > On Thu, 07.11.13 20:09, Miloslav Trmač (mitr(a)volny.cz) wrote:
>  >> Is there a technical reason why we can't use their packaging format,
>  >> interpreting it with our technologies but staying compatible?
>  >
>  > Well, the most relevant bit is that they use apparmor for
>  > sandboxing. Nobody else uses that.
>  
>  Are the packages expected to ship their own apparmor policy?
>  That would appear to be at odds with the idea of protecting against
>  malicious packages.  If they aren't expected to ship their own, could
>  we implement the same sandboxing policy using SELinux?
>  (https://wiki.ubuntu.com/AppDevUploadProcess seems to suggest Ubuntu
>  will be using some higher-level "profile" format, not raw AppArmor.) 
The whole plan is here :
https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement

Looking at :
https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinemen...

I would say "no".

> From a quick look, some abstraction are quite apparmor specific, see
> the concept 
of read_path, which is something we can hardly translate to selinux (
since
apparmor use path, while selinux use a 2 tier system with label assigned to
path, and then privileges assigned based on label ).

What we could do is to have a better abstraction that would be apparmor
and selinux comptaible. Since despites what Lennart claim, AppArmor is also
used by Opensuse. And I am sure people using smackd ( such as intel people ) would
be delighted to not be left in the cold. SELinux is still pretty RH/Fedora specific,
even if Debian and gentoo support it in theory ( in practice, Debian didn't seems to
support it that well ).

>  > And I don't think it is a good idea to use .deb as an image
> format.
>  .deb is just an ar archive; if this were the only difference, it would
>  not be worth fragmenting the ecosystem over IMHO.  (Especially if the
>  GNOME apps alternative is a "compressed disk image", which saves disk
>  space and costs extra CPU time and memory, making exactly the wrong
>  tradeoff in most situations AFAICS.) 
While I do not see any obvious problem into using deb, I do not think it will
bring much gain. It will matter for people managing the low level format,
ie few people. Reusing the manifests ( if it was doable ) would have yield much
more gain. 

-- 
Michael Scherer

[Michael Cronenworth]

Michael scherer wrote:
>  SELinux is still pretty RH/Fedora specific,
>  even if Debian and gentoo support it in theory ( in practice, Debian didn't seems to
>  support it that well ). 
Millions of Android devices now have SELinux. Android 4.3 enabled SELinux and 
defaults to Permissive. Android 4.4 defaults to Enforcing.

[Adam Williamson]

On Fri, 2013-11-08 at 08:37 -0600, Michael Cronenworth wrote:
>  Michael scherer wrote:
>  > SELinux is still pretty RH/Fedora specific,
>  > even if Debian and gentoo support it in theory ( in practice, Debian didn't
> seems to
>  > support it that well ).
>  
>  Millions of Android devices now have SELinux. Android 4.3 enabled SELinux and 
>  defaults to Permissive. Android 4.4 defaults to Enforcing. 
*can't quite believe this is the first he's read about this*
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Miloslav Trmač]

On Fri, Nov 8, 2013 at 2:31 PM, Michael scherer <misc(a)zarb.org&gt; wrote:
>  On Thu, Nov 07, 2013 at 09:55:12PM +0100, Miloslav Trmač wrote:
> > On Thu, Nov 7, 2013 at 9:48 PM, Lennart Poettering <mzerqung(a)0pointer.de&gt;
> wrote:
> > > On Thu, 07.11.13 20:09, Miloslav Trmač (mitr(a)volny.cz) wrote:
> > >> Is there a technical reason why we can't use their packaging format,
> > >> interpreting it with our technologies but staying compatible?
> > >
> > > Well, the most relevant bit is that they use apparmor for
> > > sandboxing. Nobody else uses that.
> >
> > Are the packages expected to ship their own apparmor policy?
> > That would appear to be at odds with the idea of protecting against
> > malicious packages.  If they aren't expected to ship their own, could
> > we implement the same sandboxing policy using SELinux?
> > (https://wiki.ubuntu.com/AppDevUploadProcess seems to suggest Ubuntu
> > will be using some higher-level "profile" format, not raw AppArmor.)
>
>  The whole plan is here :
>  https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement
>
>  Looking at :
>  https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinemen...
>
>  I would say "no".
>
>  From a quick look, some abstraction are quite apparmor specific, see the concept
>  of read_path, which is something we can hardly translate to selinux ( since
>  apparmor use path, while selinux use a 2 tier system with label assigned to
>  path, and then privileges assigned based on label ). 
Yes, that's one thing that we cannot (and shouldn't) support, but
read_path is listed in the "Red-flagged for manual review (use should
actively be discouraged with updates made to policy groups and
templates)" section; is it likely to be frequently used?
     Mirek

>  What we could do is to have a better abstraction that would be apparmor
>  and selinux comptaible. Since despites what Lennart claim, AppArmor is also
>  used by Opensuse. And I am sure people using smackd ( such as intel people ) would
>  be delighted to not be left in the cold. SELinux is still pretty RH/Fedora specific,
>  even if Debian and gentoo support it in theory ( in practice, Debian didn't seems to
>  support it that well ).
>
> > > And I don't think it is a good idea to use .deb as an image format.
> > .deb is just an ar archive; if this were the only difference, it would
> > not be worth fragmenting the ecosystem over IMHO.  (Especially if the
> > GNOME apps alternative is a "compressed disk image", which saves disk
> > space and costs extra CPU time and memory, making exactly the wrong
> > tradeoff in most situations AFAICS.)
>
>  While I do not see any obvious problem into using deb, I do not think it will
>  bring much gain. It will matter for people managing the low level format,
>  ie few people. Reusing the manifests ( if it was doable ) would have yield much
>  more gain.
>
>  --
>  Michael Scherer
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Michael Scherer]

Le vendredi 08 novembre 2013 à 21:24 +0100, Miloslav Trmač a écrit :
>  On Fri, Nov 8, 2013 at 2:31 PM, Michael scherer <misc(a)zarb.org&gt;
> wrote:
>  > On Thu, Nov 07, 2013 at 09:55:12PM +0100, Miloslav Trmač wrote:
>  >> On Thu, Nov 7, 2013 at 9:48 PM, Lennart Poettering <mzerqung(a)0pointer.de&gt;
> wrote:
>  >> > On Thu, 07.11.13 20:09, Miloslav Trmač (mitr(a)volny.cz) wrote:
>  >> >> Is there a technical reason why we can't use their packaging
> format,
>  >> >> interpreting it with our technologies but staying compatible?
>  >> >
>  >> > Well, the most relevant bit is that they use apparmor for
>  >> > sandboxing. Nobody else uses that.
>  >>
>  >> Are the packages expected to ship their own apparmor policy?
>  >> That would appear to be at odds with the idea of protecting against
>  >> malicious packages.  If they aren't expected to ship their own, could
>  >> we implement the same sandboxing policy using SELinux?
>  >> (https://wiki.ubuntu.com/AppDevUploadProcess seems to suggest Ubuntu
>  >> will be using some higher-level "profile" format, not raw AppArmor.)
>  >
>  > The whole plan is here :
>  > https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement
>  >
>  > Looking at :
>  > https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinemen...
>  >
>  > I would say "no".
>  >
>  > From a quick look, some abstraction are quite apparmor specific, see the concept
>  > of read_path, which is something we can hardly translate to selinux ( since
>  > apparmor use path, while selinux use a 2 tier system with label assigned to
>  > path, and then privileges assigned based on label ).
>  
>  Yes, that's one thing that we cannot (and shouldn't) support, but
>  read_path is listed in the "Red-flagged for manual review (use should
>  actively be discouraged with updates made to policy groups and
>  templates)" section; is it likely to be frequently used? 
I can imagine that for any application having some kind of private
database ( like a list of music file, save for games, or scoreboard, etc
), this would be used. So yeah, not much, but not that uncommon either
IMHO. 

But even on the others fields, there will be some issues like the need
to keep the policy in sync ( for policy_groups ), and the need to keep
the template in sync (as the system work by taking template to generate
the policy).  Keep in sync the content and the name.

It could be doable to adapt, but I am quite sure that sooner or later,
we will face problem to keep the SElinux and AppArmor policies in sync,
due to the difference of approach. I also expect that a conversion
wouldn't be straightforward due to different stacks, etc.

I do not really see that as a sustainable approach.
-- 
Michael Scherer

[Adam Williamson]

On Thu, 2013-11-07 at 16:15 +0100, Lennart Poettering wrote:
>  On Thu, 07.11.13 03:53, Kevin Kofler (kevin.kofler(a)chello.at) wrote:
>  
>  > Olav Vitters wrote:
>  > > AFAIK (not sure), it should come somewhat easy once you the distribution
>  > > is based upon systemd.
>  > 
>  > That means it will exclude the most popular distribution out there.
>  
>  If you are referring to Ubuntu, then yes. But then again, they already
>  have their own app packaging format based around .debs and
>  AppArmor. So yeah, we might be dicks by not supporting non-systemd
>  systems, but they were dicks first, by not supporting non-Ubuntu systems
>  for their app images. And that's quite some consolation, no? ;-) 
The implementation of some kind of 'app level packaging system' divorced
from distros' historic package formats seems like a fairly valuable
opportunity to finally improve the level of interoperability between
Debian-derived and non-Debian-derived distros.

If, instead, we turn it into an opportunity to argue about who was being
a dick first and then cheerfully prolong the existing, needless divides
without even making a serious attempt at working together, that...seems
like something of a waste. And an invitation to a system that _does_
work across distros, like OH SAY STEAM, to eat everyone's lunch.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Florian Weimer]

On 11/06/2013 11:30 PM, Olav Vitters wrote:
>  On Wed, Nov 06, 2013 at 10:55:30PM +0100, Sergio Pascual wrote:
> > Has this "sanboxed-bundled-from-upstream"  proposal been discussed with
> > other distributions? If the final result is that the "Universal Linux
> > Package" only works in Fedora we are not gaining anything.
>
>  A lot of this is being based on technology that's not really available
>  yet such as kdbus, Wayland, systemd bits. This has been discussed at
>  GUADEC (GNOME conference):
>  http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome 
"Wayland" and "systemd" strongly suggest no Ubuntu interoperability 
whatsoever.  Shouldn't this be a top priority for bundled applications?

-- 
Florian Weimer / Red Hat Product Security Team

[Bastien Nocera]

----- Original Message -----
>  On 11/06/2013 11:30 PM, Olav Vitters wrote:
>  > On Wed, Nov 06, 2013 at 10:55:30PM +0100, Sergio Pascual wrote:
>  >> Has this "sanboxed-bundled-from-upstream"  proposal been discussed
> with
>  >> other distributions? If the final result is that the "Universal Linux
>  >> Package" only works in Fedora we are not gaining anything.
>  >
>  > A lot of this is being based on technology that's not really available
>  > yet such as kdbus, Wayland, systemd bits. This has been discussed at
>  > GUADEC (GNOME conference):
>  > http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome
>  
>  "Wayland" and "systemd" strongly suggest no Ubuntu interoperability
>  whatsoever.  Shouldn't this be a top priority for bundled applications? 
If we get any traction on this, their customers/users will ask them for it
themselves.

[Kevin Kofler]

Bastien Nocera wrote:

>  ----- [Florian Weimer wrote:] -----
> > "Wayland" and "systemd" strongly suggest no Ubuntu
> interoperability
> > whatsoever.  Shouldn't this be a top priority for bundled applications?
>  
>  If we get any traction on this, their customers/users will ask them for it
>  themselves. 
Hahaha, you really think you can force Canonical into adopting your 
technologies that way? LOL! This is going to backfire spectacularly! (My 
guess: Canonical will come up with their own Ubuntu App model requiring 
Ubuntu technologies and all the third-party developers you are trying to 
attract will target only that one.)

        Kevin Kofler

[Florian Müllner]

On Thu, Nov 7, 2013 at 4:58 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  (My guess: Canonical will come up with their own Ubuntu App model
> requiring
>  Ubuntu technologies 
If you had read Lennart's previous reply to this thread, you'd be
aware that they already did.

[Adam Williamson]

On Thu, 2013-11-07 at 16:58 +0100, Kevin Kofler wrote:
>  Bastien Nocera wrote:
>  
>  > ----- [Florian Weimer wrote:] -----
>  >> "Wayland" and "systemd" strongly suggest no Ubuntu
> interoperability
>  >> whatsoever.  Shouldn't this be a top priority for bundled applications?
>  > 
>  > If we get any traction on this, their customers/users will ask them for it
>  > themselves.
>  
>  Hahaha, you really think you can force Canonical into adopting your 
>  technologies that way? LOL! This is going to backfire spectacularly! (My 
>  guess: Canonical will come up with their own Ubuntu App model requiring 
>  Ubuntu technologies and all the third-party developers you are trying to 
>  attract will target only that one.) 
They already *have* one:

http://shop.canonical.com/index.php?cPath=19

I have no idea how it works or where it's documented, but it exists.
Given that it's there and working and people are using it, the
obligation would seem to be on any group that comes along later to try
and implement something similar to:

i) evaluate Ubuntu's system for its potential to be used outside of
Ubuntu
ii) If it's not ready to be used outside of Ubuntu as-is, propose a
future development path which would result in interoperability and ask
the developers of the Ubuntu system if they're willing to work down such
lines, and make a genuine effort to have that come about, even at the
cost of short-term inconvenience in development
iii) If that proves impossible, communicate the situation and the
attempts that were made clearly and publicly

I'd therefore suggest anyone trying to invent a new app-level
distribution mechanism go and look at and produce a formal evaluation of
all the existing efforts in the space, including this one, before
inventing something else new.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Olav Vitters]

On Thu, Nov 07, 2013 at 12:58:37PM +0100, Florian Weimer wrote:
>  On 11/06/2013 11:30 PM, Olav Vitters wrote:
>  >On Wed, Nov 06, 2013 at 10:55:30PM +0100, Sergio Pascual wrote:
>  >>Has this "sanboxed-bundled-from-upstream"  proposal been discussed
> with
>  >>other distributions? If the final result is that the "Universal Linux
>  >>Package" only works in Fedora we are not gaining anything.
>  >
>  >A lot of this is being based on technology that's not really available
>  >yet such as kdbus, Wayland, systemd bits. This has been discussed at
>  >GUADEC (GNOME conference):
>  >http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome
>  
>  "Wayland" and "systemd" strongly suggest no Ubuntu interoperability
>  whatsoever.  Shouldn't this be a top priority for bundled
>  applications? 
Canonical does what Canonical wants to do. They already have their own
solution for something like this. It is just very distribution specific
and not as secure as what this is proposing AFAIK.

-- 
Regards,
Olav

[Josh Boyer]

On Tue, Nov 5, 2013 at 3:56 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  In this situation what we should do is carefully consider the
> relative
>  possibilities of the good, bad and mixed outcomes with as much precision
>  as we can, and try to come up with a path forward which makes the
>  likelihood of a good outcome as high as possible and the likelihood of a
>  bad outcome as low as possible. "Let's just try it and see what
>  happens!" is not a mature approach to risk management. 
I'm asking this question genuinely and not sarcastically.

Isn't that very "let's try it and see what happens!" approach exactly
what we're doing with Fedora.next?  It seems to me we've forged ahead
with good ideas around what we'd like to see, but it's a hell of a lot
more risk than just having a new way to package applications.  I mean,
we don't even have resource requirements identified for Fedora.next,
much less acquired.  Yet, here we are doing it and doing it with the
expectation that we'll work through it.

I'm just having trouble wrapping my head around the intense focus on a
new app packaging technology when the entire distro is making massive
changes to how it's produced.  It seems like we collectively aren't
seeing the forest because of the trees here.

josh

[Miloslav Trmač]

On Wed, Nov 6, 2013 at 7:24 PM, Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:
>  I'm just having trouble wrapping my head around the intense focus
> on a
>  new app packaging technology when the entire distro is making massive
>  changes to how it's produced. 
I think the trouble here is that the Linux Apps proposal (which is
being implicitly referred to) uses a single term to mix three
completely different problems, each of them difficult, and gives us a
single "package deal":

* Sandboxing as a protection mechanism (technically difficult - to
design, to migrate to, lots of work to implement)
* Bundling as a way to "solve" API/ABI breakage (not "technically
right" yet done and requested in practice, security concerns)
* Non-distribution mechanisms to get software from developers to users
(losing control/ability to integrate, making it easier for proprietary
software)

With the 2^3 possible combinations of likes/dislikes, almost everyone
has something to be intensely unhappy about.

On the other hand, the move to WGs has so far not resulted in any
drastic proposals to change what we are doing; it's easy to view this
as "different kinds of spins with more voting bodies".  I expect this
to change eventually, but not just now.
     Mirek

[Josh Boyer]

On Wed, Nov 6, 2013 at 1:34 PM, Miloslav Trmač <mitr(a)volny.cz&gt; wrote:
>  On Wed, Nov 6, 2013 at 7:24 PM, Josh Boyer
> <jwboyer(a)fedoraproject.org&gt; wrote:
> > I'm just having trouble wrapping my head around the intense focus on a
> > new app packaging technology when the entire distro is making massive
> > changes to how it's produced.
>
>  I think the trouble here is that the Linux Apps proposal (which is
>  being implicitly referred to) uses a single term to mix three
>  completely different problems, each of them difficult, and gives us a
>  single "package deal":
>
>  * Sandboxing as a protection mechanism (technically difficult - to
>  design, to migrate to, lots of work to implement)
>  * Bundling as a way to "solve" API/ABI breakage (not "technically
>  right" yet done and requested in practice, security concerns)
>  * Non-distribution mechanisms to get software from developers to users
>  (losing control/ability to integrate, making it easier for proprietary
>  software)
>
>  With the 2^3 possible combinations of likes/dislikes, almost everyone
>  has something to be intensely unhappy about. 
Sure, but that's kind of my point.  If we can't realize that it's
possible to do some kind of combination that makes sense with
something this small, what are we going to do when the entire distro
is up for change?  While I dislike buzzwords, the stop energy here is
pretty daunting.

>  On the other hand, the move to WGs has so far not resulted in any
>  drastic proposals to change what we are doing; it's easy to view this
>  as "different kinds of spins with more voting bodies".  I expect this
>  to change eventually, but not just now. 
What you say makes some sense.  It also makes me very tired thinking
about the threads coming when the details start getting presented by
the WGs :).  I guess that's what we've signed up for though.

josh

[Kevin Kofler]

Josh Boyer wrote:
>  What you say makes some sense.  It also makes me very tired thinking
>  about the threads coming when the details start getting presented by
>  the WGs :).  I guess that's what we've signed up for though. 
Well yes, each time you try to force a change through which actually makes 
things worse, there WILL be resistance. In fact, this is already what is 
happening in this thread, the "app" proposal coming from (parts of) the 
Workstation WG.

        Kevin Kofler

[Peter Robinson]

On 7 Nov 2013 03:05, "Kevin Kofler" <kevin.kofler(a)chello.at&gt; wrote:
>  Josh Boyer wrote:
>  > What you say makes some sense.  It also makes me very tired thinking
>  > about the threads coming when the details start getting presented by
>  > the WGs :).  I guess that's what we've signed up for though.
>
>  Well yes, each time you try to force a change through which actually makes
>  things worse, there WILL be resistance. In fact, this is already what is
>  happening in this thread, the "app" proposal coming from (parts of) the
>  Workstation WG. 
I don't see many people forcing things through, I believe that the vast
majority of contributors either like the change or aren't bothered by it.
There's certainly no proof that it'll make anything worse. That doesn't
mean its going to be perfect or without teething problems as the changes
are made and things settle down.

The fact that you don't like change or don't understand it means that you
shouldn't try and project your opinion as that of the general community.

Peter

[Michael Cronenworth]

Peter Robinson wrote:
>  I don't see many people forcing things through, I believe that
> the vast majority
>  of contributors either like the change or aren't bothered by it. There's
>  certainly no proof that it'll make anything worse. That doesn't mean its going
>  to be perfect or without teething problems as the changes are made and things
>  settle down. 
There's plenty of reasons why you haven't seen any negative feedback. I'll
share 
my views on this subject since I'm in the "not sure" ballpark of this new
process.

Where's the benefit of creating a handful of workgroups that now have some sort 
of power over the distribution? After reading all of the emails in the past week 
I have yet to see any benefits of this "Fedora.next" process. I agree Fedora 
needs to continue to evolve, but this process appears to shake the foundations 
of Fedora. Specifics: Different kernels per "product", app sandboxing (lib 
bundling). Will the DVD/Live ISOs currently created cease to exist F21+? 
Fragmentation of Fedora into Cloud/Workstation/Server "products"? I'm just 
randomly spitting out ideas in my head that come to mind, but you cannot expect 
that silence equates to agreement in your favor.

It strikes me as odd at the large number of @redhat accounts and small number of 
non-@redhat accounts in favor of this new process. Who is in charge of evolving 
Fedora at this point? I do value Red Hat involvement, but I don't want the 
common myth of "Fedora = Red Hat beta" to become a fact.

I'm still going to keep my ears open and attempt at digesting what this new idea 
is bringing to the table, but it hasn't sit well on my stomach so far.

back to the basics of fedora.next

[Matthew Miller]

[Apologies for late replies to a long, wandering thread. I've been at a
confernece and am just catching up.]

On Thu, Nov 07, 2013 at 08:47:44AM -0600, Michael Cronenworth wrote:
>  Where's the benefit of creating a handful of workgroups that now
>  have some sort of power over the distribution? After reading all of 
I wouldn't phrase it that way. The idea is to create working groups who
accept responsibility for a part of the distribution. 

>  "Fedora.next" process. I agree Fedora needs to continue to
> evolve,
>  but this process appears to shake the foundations of Fedora.
>  Specifics: Different kernels per "product", app sandboxing (lib
>  bundling). Will the DVD/Live ISOs currently created cease to exist
>  F21+? Fragmentation of Fedora into Cloud/Workstation/Server
>  "products"? 
Again, I don't think I'd phrase it that way. We want to target different use
cases differently. Up until now, people who want to run Fedora on servers 
(and there are a lot of them -- I was just at Usenix LISA and spoke to many
people doing so) have been to some degree at the mercy of decisions made for
"the default offering", and the only thing stopping that has been sudden
interventions from Red Hat regarding RHEL needs when there's a perception
that things have gone "astray". That's not a good way to do it -- there
should be a Fedora Server voice in its own right.

Still, fragmentation wouldn't be a good result, which is why we have the
Base Design group -- and existing groups like Marketing and Design will
still be involved across the board.


>  It strikes me as odd at the large number of @redhat accounts and
>  small number of non-@redhat accounts in favor of this new process.
>  Who is in charge of evolving Fedora at this point? I do value Red
>  Hat involvement, but I don't want the common myth of "Fedora = Red
>  Hat beta" to become a fact. 
This is actually completely the opposite. If that is what Red Hat wanted,
they would simply pull funding for Fedora and have something else designed
from scratch to be more suitable to that role. Fedora needs to succeed on
its own merit.

The three proposed products come from discussion at Flock, started by
Stephen Gallagher (who is a Red Hat employee but also a Fedora community
member for years), but those are basically just some broad needs that we
saw. We're already promoting cloud to first-class-citizen in Fedora 20, and
this is really just adding server to that. Stephen can talk more about how
his thinking led him to suggsting this.

As for who is in charge -- well, the structure says the Fedora Board and the
elected members of FESCo. But this is and remains a community process. I've
basically tried to absorb everything I hear from everyone in the community
-- Red Hat and not -- and attemped to integrate it into a coherent plan, and
then pushed to advance that plan. Sometimes not everyone agrees, and that
means compromise, and there's nothing wrong with that. Sometimes we're going
to make wrong moves and have to correct, and there's also nothing wrong with
that.

It's absolutely true that I'm advocating for more flexibility in what and
who can be included in Fedora, and in how we can do that. That doesn't mean
I don't have respect for what we're doing now or how we got here. It means I
think we can do that _and more_ and still all be Fedora.


>  I'm still going to keep my ears open and attempt at digesting
> what
>  this new idea is bringing to the table, but it hasn't sit well on my
>  stomach so far. 
I appreciate your willingness to be open and to talk about your concerns --
that's how we get anyhere as a community. Does the above help things sit
better? 

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

back to the basics of fedora.next

[Jaroslav Reznik]

----- Original Message -----
>  [Apologies for late replies to a long, wandering thread. I've
> been at a
>  confernece and am just catching up.]
>  
>  On Thu, Nov 07, 2013 at 08:47:44AM -0600, Michael Cronenworth wrote:
>  > Where's the benefit of creating a handful of workgroups that now
>  > have some sort of power over the distribution? After reading all of
>  
>  I wouldn't phrase it that way. The idea is to create working groups who
>  accept responsibility for a part of the distribution.
>  
>  > "Fedora.next" process. I agree Fedora needs to continue to evolve,
>  > but this process appears to shake the foundations of Fedora.
>  > Specifics: Different kernels per "product", app sandboxing (lib
>  > bundling). Will the DVD/Live ISOs currently created cease to exist
>  > F21+? Fragmentation of Fedora into Cloud/Workstation/Server
>  > "products"?
>  
>  Again, I don't think I'd phrase it that way. We want to target different use
>  cases differently. Up until now, people who want to run Fedora on servers
>  (and there are a lot of them -- I was just at Usenix LISA and spoke to many
>  people doing so) have been to some degree at the mercy of decisions made for
>  "the default offering", and the only thing stopping that has been sudden
>  interventions from Red Hat regarding RHEL needs when there's a perception
>  that things have gone "astray". That's not a good way to do it -- there
>  should be a Fedora Server voice in its own right.
>  
>  Still, fragmentation wouldn't be a good result, which is why we have the
>  Base Design group -- and existing groups like Marketing and Design will
>  still be involved across the board. 
This is one thing we touched at Base WG and it was raised as part of the
Base WG role - we need a way how to communicate between different WGs, we
need a way how to reach other teams as marketing, design etc. (actually not
to forget we have these). Especially as Base WG has to gather the requirements
from project based on the Base.

I'll try to draft a way how we could do it - it's probably enough high level
to bring it to the Board. And probably makes sense to restart the discussion
how much sense is to have Board in the current way how it's implemented or
if we want to move it forward and better fit the new model - to have
representatives from WGs, from other teams, to actually coordinate project.
Not just being a body to give stamps to trademark requests. 

It's great many WGs are trying to share a lot of stuff, to avoid kind of
fragmentation where it does not make a lot of sense, se we have very similar
charters. We definitely has to go further and find a balance, based on
resources we have, flexibility we want etc. I don't see as a big issue to
at least start collecting bold ideas, at one point, we would have to sit
down and try to pick up what's possible, what are our goals for the future
and how to make these goals possible.

Jaroslav

back to the basics of fedora.next

[Michael Cronenworth]

Matthew Miller wrote:
>  Again, I don't think I'd phrase it that way. We want to
> target different use
>  cases differently. Up until now, people who want to run Fedora on servers
>  (and there are a lot of them -- I was just at Usenix LISA and spoke to many
>  people doing so) have been to some degree at the mercy of decisions made for
>  "the default offering", and the only thing stopping that has been sudden
>  interventions from Red Hat regarding RHEL needs when there's a perception
>  that things have gone "astray". That's not a good way to do it -- there
>  should be a Fedora Server voice in its own right. 
Perhaps Fedora has been marketed incorrectly. There's nothing wrong with running 
Fedora on anything from a Pi to a 16+ core server, but the main download for 
Fedora touts it as a Desktop distribution. Perhaps announcing there is a Server 
product will sway those users into looking at Fedora, but it could have been 
done with a change to the web site.

>  Still, fragmentation wouldn't be a good result, which is why we
> have the
>  Base Design group -- and existing groups like Marketing and Design will
>  still be involved across the board. 
Marketing and Design seem to have, indirectly, necessitated this change. Perhaps 
their goals need to be re-evaluated during this new process.

>  The three proposed products come from discussion at Flock, started
> by
>  Stephen Gallagher (who is a Red Hat employee but also a Fedora community
>  member for years), but those are basically just some broad needs that we
>  saw. We're already promoting cloud to first-class-citizen in Fedora 20, and
>  this is really just adding server to that. Stephen can talk more about how
>  his thinking led him to suggsting this.
>
>  As for who is in charge -- well, the structure says the Fedora Board and the
>  elected members of FESCo. But this is and remains a community process. I've
>  basically tried to absorb everything I hear from everyone in the community
>  -- Red Hat and not -- and attemped to integrate it into a coherent plan, and
>  then pushed to advance that plan. Sometimes not everyone agrees, and that
>  means compromise, and there's nothing wrong with that. Sometimes we're going
>  to make wrong moves and have to correct, and there's also nothing wrong with
>  that.
>
>  It's absolutely true that I'm advocating for more flexibility in what and
>  who can be included in Fedora, and in how we can do that. That doesn't mean
>  I don't have respect for what we're doing now or how we got here. It means I
>  think we can do that_and more_  and still all be Fedora. 
I studied the discussions prior to the creation of these workgroups and I saw 
positive ideas. The problem I'm seeing now is that when those ideas are put in 
practice they don't appear to be as fruitful.

>  I appreciate your willingness to be open and to talk about your
> concerns --
>  that's how we get anyhere as a community. Does the above help things sit
>  better? 
Thanks for taking the time to reply. I feel slightly better today.

[Kevin Kofler]

Peter Robinson wrote:
>  I don't see many people forcing things through, I believe that
> the vast
>  majority of contributors either like the change or aren't bothered by it. 
Ah, the "silent majority" hypothesis, always a fun argument to bring (with 
no evidence whatsoever) when one is clearly losing a discussion.

Can't you just admit that the consensus is AGAINST Apple-like apps?

        Kevin Kofler

[Rahul Sundaram]

Hi


On Thu, Nov 7, 2013 at 10:06 AM, Kevin Kofler  wrote:

>  Peter Robinson wrote:
>  > I don't see many people forcing things through, I believe that the vast
>  > majority of contributors either like the change or aren't bothered by it.
>
>  Ah, the "silent majority" hypothesis, always a fun argument to bring (with
>  no evidence whatsoever) when one is clearly losing a discussion.
>
>  Can't you just admit that the consensus is AGAINST Apple-like apps?
>  
You haven't established any such consensus at all.  On the contrary, I see
a number of people on both sides.

Rahul

[Olav Vitters]

On Thu, Nov 07, 2013 at 04:06:04PM +0100, Kevin Kofler wrote:
>  Peter Robinson wrote:
>  > I don't see many people forcing things through, I believe that the vast
>  > majority of contributors either like the change or aren't bothered by it.
>  
>  Ah, the "silent majority" hypothesis, always a fun argument to bring (with 
>  no evidence whatsoever) when one is clearly losing a discussion. 
Ok, you're against "silent majority" hypothesis

>  Can't you just admit that the consensus is AGAINST Apple-like
> apps? 
Wait, I thought you were against "silent majority" hypothesis?

-- 
Regards,
Olav

[Mattias Ellert]

tor 2013-11-07 klockan 09:14 +0000 skrev Peter Robinson:

>  I don't see many people forcing things through, I believe that
> the
>  vast majority of contributors either like the change or aren't
>  bothered by it. 
Just so that my silence is not counted as approval. I disapprove.

	Mattias

[Olav Vitters]

On Thu, Nov 07, 2013 at 04:01:09AM +0100, Kevin Kofler wrote:
>  Well yes, each time you try to force a change through which actually
> makes 
>  things worse, there WILL be resistance. In fact, this is already what is 
>  happening in this thread, the "app" proposal coming from (parts of) the 
>  Workstation WG. 
That you see a proposal as forcing things through is unfortunate. But I
don't see much resistance, there are concerns and sometimes voiced in a
strange way, but that's pretty much it.

-- 
Regards,
Olav

[Adam Williamson]

On Wed, 2013-11-06 at 13:24 -0500, Josh Boyer wrote:
>  On Tue, Nov 5, 2013 at 3:56 PM, Adam Williamson
> <awilliam(a)redhat.com&gt; wrote:
>  > In this situation what we should do is carefully consider the relative
>  > possibilities of the good, bad and mixed outcomes with as much precision
>  > as we can, and try to come up with a path forward which makes the
>  > likelihood of a good outcome as high as possible and the likelihood of a
>  > bad outcome as low as possible. "Let's just try it and see what
>  > happens!" is not a mature approach to risk management.
>  
>  I'm asking this question genuinely and not sarcastically.
>  
>  Isn't that very "let's try it and see what happens!" approach exactly
>  what we're doing with Fedora.next?  It seems to me we've forged ahead 
Hoo boy, just when the thread was quieting down...

I'm still slightly out of sync with the fedora.next stuff (REALLY picked
a bad time to go on vacation), but it does seem to me that a decent
amount of 'mature reflection' was done on it before it was approved, at
least. And it does not appear to be irreversible at this point: we are
still only at the point where a bunch of WGs are going away to come up
with proposals for FESCo's review, yes? FESCo could ultimately still
decide to shoot down the whole thing, or demand major changes, or delay
it for any given amount of time? As I read the process, we are not
irreversibly committed to any practical changes to any Fedora product at
this point.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Rahul Sundaram]

Hi


On Wed, Nov 6, 2013 at 2:38 PM, Adam Williamson wrote:

>  I'm still slightly out of sync with the fedora.next stuff (REALLY picked
>  a bad time to go on vacation), but it does seem to me that a decent
>  amount of 'mature reflection' was done on it before it was approved, at
>  least.
>  
I don't really have a problem in believing that but it would be useful to
know in more detail how the initial proposals came to be (who were
involved?  what problems are we trying to solve?  what are failures of the
current model?  did it go through Red Hat management internally before
being proposed and is more headcount being allotted?  Was Fedora Board and
FESCo members aware that a proposal were coming through and what was their
rationale for choosing to go forward? etc)

Rahul

[Michael Scherer]

On Wed, Nov 06, 2013 at 02:45:46PM -0500, Rahul Sundaram wrote:
>  Hi
>  
>  
>  On Wed, Nov 6, 2013 at 2:38 PM, Adam Williamson wrote:
>  
>  >
>  > I'm still slightly out of sync with the fedora.next stuff (REALLY picked
>  > a bad time to go on vacation), but it does seem to me that a decent
>  > amount of 'mature reflection' was done on it before it was approved, at
>  > least.
>  >
>  
>  I don't really have a problem in believing that but it would be useful to
>  know in more detail how the initial proposals came to be (who were
>  involved?  what problems are we trying to solve?  what are failures of the
>  current model?  did it go through Red Hat management internally before
>  being proposed and is more headcount being allotted?  Was Fedora Board and
>  FESCo members aware that a proposal were coming through and what was their
>  rationale for choosing to go forward? etc) 
I suspect Mattew discussed this around him before, as anything anyone would
propose. Would chatting with Spot on IRC count as going with Red Hat management,
or just 2 community member talking together ? Because the outcome would be the
same. But the 
 
The proposal was discussed IRL during Flock, the proposal was discussed here before[1]
 and got lot of feedback, the proposal was checked by Board[3] , by FESCO[2].

And I think this was in line with the discussion on the whole "product or
platform"
on the Board mailling list, who was started by the user base discussion initiated 
by Robyn [4].

So it all boil down to "thing have changed, and so we think we should also do some
changes, for
all those reasons".

[1] https://lists.fedoraproject.org/pipermail/devel/2013-July/186323.html
[2] https://fedorahosted.org/fesco/ticket/1158
[3] https://fedoraproject.org/wiki/Fedora.next/boardproposal
[4]
http://wordshack.wordpress.com/2013/04/04/board-meeting-topic-for-the-day...

-- 
Michael Scherer

[Matthew Miller]

On Wed, Nov 06, 2013 at 02:45:46PM -0500, Rahul Sundaram wrote:
>  I don't really have a problem in believing that but it would be
> useful to
>  know in more detail how the initial proposals came to be (who were
>  involved?  what problems are we trying to solve?  what are failures of the
>  current model?  did it go through Red Hat management internally before
>  being proposed and is more headcount being allotted?  Was Fedora Board and
>  FESCo members aware that a proposal were coming through and what was their
>  rationale for choosing to go forward? etc) 
Did you see my message in July before Flock, and my talk there? 

<http://www.youtube.com/watch?v=K4dNP9DiaXc> <- if this link is broken it's
     because I'm on the train and yourube is blocked

<https://lists.fedoraproject.org/pipermail/devel/2013-July/186323.html>

<http://mattdm.org/fedora/next/>

And I think that answers most of your questions, or at least provides a
starting point for them. Overall, the process is basically what you see in
public and I've tried to make this as transparent as possible.

I did discuss the idea with my manager (Denise Dumas, Director of Platform
Engineering) to make sure she would support me in spending time developing
it. She has promised (including to everyone at Flock) to provide resources
where we can make a good case for them (and I think we can!). I also talked
with a few people both inside and outside of Red Hat to help adjust the
initial presentation and message, and I presented it to get feedback from a
handful of groups internally before Flock.

Mostly, though, there was very little that you can't see on this and other
mailing lists and in Fedora IRC logs. 

The part about three products came from Stephen Gallagher at Flock, and he
can take both credit and blame for that :). To me, that provides a practical
answer to "how do we deliver something out of these policy rings I
proposed", which was kind of a missing piece so I went with it. If you have
solutions to other missing pieces I'll back those too.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Rahul Sundaram]

Hi


On Sat, Nov 9, 2013 at 3:36 PM, Matthew Miller wrote:

>  I did discuss the idea with my manager (Denise Dumas, Director of Platform
>  Engineering) to make sure she would support me in spending time developing
>  it. She has promised (including to everyone at Flock) to provide resources
>  where we can make a good case for them (and I think we can!). I also talked
>  with a few people both inside and outside of Red Hat to help adjust the
>  initial presentation and message, and I presented it to get feedback from a
>  handful of groups internally before Flock.
>
>  Mostly, though, there was very little that you can't see on this and other
>  mailing lists and in Fedora IRC logs.
>  
These are the key parts that I wanted to confirm.  Thanks.

Rahul

[Josh Boyer]

On Wed, Nov 6, 2013 at 2:38 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  On Wed, 2013-11-06 at 13:24 -0500, Josh Boyer wrote:
> > On Tue, Nov 5, 2013 at 3:56 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
> > > In this situation what we should do is carefully consider the relative
> > > possibilities of the good, bad and mixed outcomes with as much precision
> > > as we can, and try to come up with a path forward which makes the
> > > likelihood of a good outcome as high as possible and the likelihood of a
> > > bad outcome as low as possible. "Let's just try it and see what
> > > happens!" is not a mature approach to risk management.
> >
> > I'm asking this question genuinely and not sarcastically.
> >
> > Isn't that very "let's try it and see what happens!" approach
> exactly
> > what we're doing with Fedora.next?  It seems to me we've forged ahead
>
>  Hoo boy, just when the thread was quieting down...
>
>  I'm still slightly out of sync with the fedora.next stuff (REALLY picked
>  a bad time to go on vacation), but it does seem to me that a decent
>  amount of 'mature reflection' was done on it before it was approved, at
>  least. And it does not appear to be irreversible at this point: we are
>  still only at the point where a bunch of WGs are going away to come up
>  with proposals for FESCo's review, yes? FESCo could ultimately still
>  decide to shoot down the whole thing, or demand major changes, or delay
>  it for any given amount of time? As I read the process, we are not
>  irreversibly committed to any practical changes to any Fedora product at
>  this point. 
Sure.  That doesn't change that the risk is still there and that there
are lots of unknowns and will be ever after FESCo approves (or
rejects) the governance and PDRs for the WGs.  I suppose the point of
little return is Jan.  That doesn't mean that it's _not_ a somewhat
cavalier approach.

My point is, we're seriously considering changing Fedora as a whole
because it allows us to make certain things better.  So do app
containers, or containers in general.  So do a lot of other technical
things that could _possibly_ lead to some downsides.  I'm just
imploring people to stop screaming NO on these technical items before
they even get started.  I think we need a bit more of a bold approach
or we're going to be stuck where we are with other projects doing the
innovation people find interesting and useful.

josh

[Kevin Kofler]

Josh Boyer wrote:
>  Isn't that very "let's try it and see what
> happens!" approach exactly
>  what we're doing with Fedora.next? 
I also have strong doubts that what you call "Fedora.next" is going to be of 
any benefit to us. The existing system with the Spins and SIGs just worked, 
what's the point of overthrowing it all with a new parallel structure 
(Products and Working Groups)?

        Kevin Kofler

[Nicolas Mailhot]

Le Mer 6 novembre 2013 19:24, Josh Boyer a écrit :

>  I'm just having trouble wrapping my head around the intense focus
> on a
>  new app packaging technology when the entire distro is making massive
>  changes to how it's produced. 
Because all distributions can and do ship the same software and the main
thing that differences distributions is attention to packaging. What build
the Fedora brand is in huge part the hard work of packagers over the years
and careful definition of packaging guidelines.

There have been many people that claimed this process was awful in the
past and their alternatives all sank. Mainly because they were addressing
developer problems (freedom to take all the shortcuts that make
integration hard and users miserable) and thought they would win
marketshare this way (hint: you do not win marketshare by solving
developer problems you win marketshare by solving user problems. Users
always voted with their feet and rejected the developer-friendly solutions
that made their own life harder).

So what makes this initiative different? I guess that's because it
promotes itself as making it possible to get software in Fedora, competing
with and disparaging the work of packagers while hijacking the brand they
helped building.

Get this thing its own name. Let it win or lose user confidence on its own
merit, and don't confuse users with "in Fedora" claims when you're
absolutely *not* offering the same thing "in Fedora" means now.

Right now this proposal has the potential to ruin user trust and become
the same thorn nvidia drivers are for xorg and kernel people now. Of
course people who build this trust do not like it.

Is that clearer?

Regards,

-- 
Nicolas Mailhot

[Josh Boyer]

On Thu, Nov 7, 2013 at 8:20 AM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net&gt; wrote:
>  Le Mer 6 novembre 2013 19:24, Josh Boyer a écrit :
>
> > I'm just having trouble wrapping my head around the intense focus on a
> > new app packaging technology when the entire distro is making massive
> > changes to how it's produced.
>
>  Because all distributions can and do ship the same software and the main
>  thing that differences distributions is attention to packaging. What build
>  the Fedora brand is in huge part the hard work of packagers over the years
>  and careful definition of packaging guidelines. 
I think you missed the point of my question.  It might have been too
subtle.  It wasn't "what is wrong with sandboxed/containerized apps?".
 See the follow ups.

>  There have been many people that claimed this process was awful in
> the
>  past and their alternatives all sank. Mainly because they were addressing
>  developer problems (freedom to take all the shortcuts that make
>  integration hard and users miserable) and thought they would win
>  marketshare this way (hint: you do not win marketshare by solving
>  developer problems you win marketshare by solving user problems. Users
>  always voted with their feet and rejected the developer-friendly solutions
>  that made their own life harder). 
Users want apps.  Developers are increasingly not caring at all about
distros.  I think there's a middle ground to be had here.  As I've
said before, just saying this is bad without even thinking about if it
has some positives and how it could work just seems shortsighted.

>  So what makes this initiative different? I guess that's because
> it
>  promotes itself as making it possible to get software in Fedora, competing
>  with and disparaging the work of packagers while hijacking the brand they
>  helped building.
>
>  Get this thing its own name. Let it win or lose user confidence on its own
>  merit, and don't confuse users with "in Fedora" claims when you're
>  absolutely *not* offering the same thing "in Fedora" means now. 
And yet, now we have Coprs.  Which lets people easily upload
unreviewed, possibly bundled application SRPMs for easy distribution
outside of the main Fedora repos.  Everyone seems to think Coprs are
awesome, but they can be used for the same things you deride
containerized apps for.

>  Right now this proposal has the potential to ruin user trust and
> become
>  the same thorn nvidia drivers are for xorg and kernel people now. Of
>  course people who build this trust do not like it.
>
>  Is that clearer? 
No.

josh

[Nicolas Mailhot]

Le Jeu 7 novembre 2013 14:57, Josh Boyer a écrit :

>  And yet, now we have Coprs.  Which lets people easily upload
>  unreviewed, possibly bundled application SRPMs for easy distribution
>  outside of the main Fedora repos.  Everyone seems to think Coprs are
>  awesome, but they can be used for the same things you deride
>  containerized apps for. 
And Coprs have their own name. So they're doing exactly what I proposed.
You didn't read my message

-- 
Nicolas Mailhot

[Josh Boyer]

On Thu, Nov 7, 2013 at 9:10 AM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net&gt; wrote:
>  Le Jeu 7 novembre 2013 14:57, Josh Boyer a écrit :
>
> > And yet, now we have Coprs.  Which lets people easily upload
> > unreviewed, possibly bundled application SRPMs for easy distribution
> > outside of the main Fedora repos.  Everyone seems to think Coprs are
> > awesome, but they can be used for the same things you deride
> > containerized apps for.
>
>  And Coprs have their own name. So they're doing exactly what I proposed.
>  You didn't read my message 
Oh, I read it.  I find it odd that we can have a tool with a name
(Copr) that is officially part of the Fedora project and a tool
without a name (containerized apps) that doesn't even exit yet that
both solve similar issues and can be used in similar ways and somehow
have the name being the only thing that makes it acceptable.

So if we call containerized apps "Appers" and host it somewhere on
Fedora infrastructure and tell people about it, you'd be totally OK
with that?  People seem to already be jumping to conclusions that
Appers are going to somehow magically be THE WAY we deliver software,
but yet nobody had the same thoughts around Coprs.  The blinders
involved here are pretty large.

These things are tools.  They aren't the end-all-be-all solution to
software delivery.  I just wish people would calm down and stop
wasting so much energy fighting against something on grounds that
aren't even with existing tools and before anyone even sees what it
looks like.

josh

[Nicolas Mailhot]

Le Jeu 7 novembre 2013 15:19, Josh Boyer a écrit :

>  So if we call containerized apps "Appers" and host it
> somewhere on
>  Fedora infrastructure and tell people about it, you'd be totally OK
>  with that? 
I think that would remove a lot of the emotion in this thread.

>   People seem to already be jumping to conclusions that
>  Appers are going to somehow magically be THE WAY we deliver software,
>  but yet nobody had the same thoughts around Coprs. 
Maybe that's because Coprs were never announced with huge rants about
market-share and how Fedora packaging sucked and was irrelevant?

>  The blinders involved here are pretty large. 
It's not blinders it's the natural reaction of people to tactless
pronouncements and dismissals. I do wish the people complaining about this
list focused more on technical aspects and less on hype or
we-ll-decide-somewhere-else-even-though-it-concerns-you.

-- 
Nicolas Mailhot

[Kevin Fenzi]

On Thu, 7 Nov 2013 15:45:13 +0100
"Nicolas Mailhot" <nicolas.mailhot(a)laposte.net&gt; wrote:
...snip...

>  
>  It's not blinders it's the natural reaction of people to tactless
>  pronouncements and dismissals. I do wish the people complaining about
>  this list focused more on technical aspects and less on hype or
>  we-ll-decide-somewhere-else-even-though-it-concerns-you. 
Thats one thing that puzzles me about this thread... this is all from: 

"Work towards a system where applications can be installed inside a
container to improve security and simplify compatibility through
library bundling"

Which basically says that the working group is going to work on that.
There's actually 0 technical details on how the implemetation will work
out, or even if it will. 

Perhaps we could move this back to productive and suggest that the
working group amend their PRD to have something like: 

"Investigate the implementation and usage for application containers"
and then we can discuss details when there actually are some? 

kevin

[Olav Vitters]

On Thu, Nov 07, 2013 at 08:57:06AM -0700, Kevin Fenzi wrote:
>  Which basically says that the working group is going to work on
> that.
>  There's actually 0 technical details on how the implemetation will work
>  out, or even if it will.  
http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome

So there have been lots of thought and work going into this. But maybe
more needs to be written down in the proposal as you mentioned.

-- 
Regards,
Olav

[Kevin Fenzi]

On Thu, 7 Nov 2013 20:50:28 +0100
Olav Vitters <olav(a)vitters.nl&gt; wrote:

>  On Thu, Nov 07, 2013 at 08:57:06AM -0700, Kevin Fenzi wrote:
>  > Which basically says that the working group is going to work on
>  > that. There's actually 0 technical details on how the implemetation
>  > will work out, or even if it will. 
>  
>  http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome
>  
>  So there have been lots of thought and work going into this. But maybe
>  more needs to be written down in the proposal as you mentioned. 
Thats one possible implementation sure.

Yeah, ideally a write up with pros/cons, work outstanding that needs to
still be done, what things are acceptable for shipping this way and
what isn't, how they are exposed to users, how users can manage them,
how they interact with other containers that the other working groups
might be working on to meet their needs for server applications, etc. 

I think it's premature to yell about something where there's not even a
detailed proposal to look at. 

kevin

[Olav Vitters]

On Thu, Nov 07, 2013 at 03:45:13PM +0100, Nicolas Mailhot wrote:
>  Maybe that's because Coprs were never announced with huge rants
> about
>  market-share and how Fedora packaging sucked and was irrelevant? 
I'm pretty sure you're misunderstanding what people are saying if you
think above. What I wrote might be understood like above, but that's not
what I meant at all. Suggest to reread what people wrote.

A few comments to make it easier: I was talking about the *review
process*. That can take *ages*. Secondly, this is not meant to replace
packages, no packages are not at all irrelevant.

-- 
Regards,
Olav

[Kevin Kofler]

Josh Boyer wrote:
>  So if we call containerized apps "Appers" 
The name "Apper" is already taken!

        Kevin Kofler

[Michael Cronenworth]

Josh Boyer wrote:
>  Everyone seems to think Coprs are
>  awesome, but they can be used for the same things you deride
>  containerized apps for. 
Please don't count me as "everyone."

How is Coprs a benefit?
-Allows easy Fedora fragmentation. Why bother with package reviews ever again? 
Were Ubuntu's PPAs seen as such an advantage because they allowed every John Doe 
and Jane Smith to release packages put together with duct tape? I highly value 
Fedora's packaging guidelines and now to provide a service that does away with 
them is insulting.
-Who is going to police it? People will attempt at uploading binary packages. 
(steam, NVIDIA, skype, etc)
-What's this do over running mock on your local system? Anyone can generate RPMs 
on their own system the same way Koji/Coprs do.

[Kevin Fenzi]

On Thu, 07 Nov 2013 09:06:43 -0600
Michael Cronenworth <mike(a)cchtml.com&gt; wrote:

>  Josh Boyer wrote:
>  > Everyone seems to think Coprs are
>  > awesome, but they can be used for the same things you deride
>  > containerized apps for.
>  
>  Please don't count me as "everyone."
>  
>  How is Coprs a benefit?
>  -Allows easy Fedora fragmentation. Why bother with package reviews
>  ever again? Were Ubuntu's PPAs seen as such an advantage because they
>  allowed every John Doe and Jane Smith to release packages put
>  together with duct tape? I highly value Fedora's packaging guidelines
>  and now to provide a service that does away with them is insulting. 
Like repos.fedorapeople.org ?

How on earth do you get to 'does away with them' ?

>  -Who is going to police it? People will attempt at uploading binary
>  packages. (steam, NVIDIA, skype, etc) 
The copr maintainers? along with anyone who looks at them who wishes to
report something non distributable. Just like repos.fedorapeople.org 

>  -What's this do over running mock on your local system? Anyone
> can
>  generate RPMs on their own system the same way Koji/Coprs do. 
Sure they can. This just allows them a place to publish them and not
use local computing resources to build them. 

kevin

[Michael Cronenworth]

Kevin Fenzi wrote:
>  Like repos.fedorapeople.org ? 
I don't have a beef with r.f.o. They're no different from hosting a repo on a 
personal server. The top of the root page even contains a disclaimer.

>  How on earth do you get to 'does away with them' ? 
It's a Fedora infrastructure server building non-Fedora packages. Why is it 
considered part of Fedora? Plus there is no disclaimer.

>  The copr maintainers? along with anyone who looks at them who wishes
> to
>  report something non distributable. Just like repos.fedorapeople.org 
Good. I see that feature.

>  Sure they can. This just allows them a place to publish them and not
>  use local computing resources to build them. 
I don't have anything wrong with creating a useful service if it respects 
Fedora's principles.

[Kevin Fenzi]

On Thu, 07 Nov 2013 13:47:34 -0600
Michael Cronenworth <mike(a)cchtml.com&gt; wrote:

>  Kevin Fenzi wrote:
>  > Like repos.fedorapeople.org ?
>  
>  I don't have a beef with r.f.o. They're no different from hosting a
>  repo on a personal server. The top of the root page even contains a
>  disclaimer.
>  
>  > How on earth do you get to 'does away with them' ?
>  
>  It's a Fedora infrastructure server building non-Fedora packages. Why
>  is it considered part of Fedora? Plus there is no disclaimer. 
Like koji? (which you can make scratch builds of 'non fedora
packages'). 

It's 'part of fedora' in the sense that it's running in our private
openstack cloud. You're welcome to run your own (see the copr packages
available in fedora/epel). 

We could add a disclaimer... can you file a copr ticket asking for one?

>  > The copr maintainers? along with anyone who looks at them who
>  > wishes to report something non distributable. Just like
>  > repos.fedorapeople.org
>  
>  Good. I see that feature.
>  
>  > Sure they can. This just allows them a place to publish them and not
>  > use local computing resources to build them.
>  
>  I don't have anything wrong with creating a useful service if it
>  respects Fedora's principles. 
I don't see anything against fedora's principals here... but if you see
something feel free to let me know. 

kevin

[Michael Scherer]

Le lundi 04 novembre 2013 à 21:02 +0100, Reindl Harald a écrit :
>  
>  Am 04.11.2013 20:56, schrieb drago01:
>  > On Mon, Nov 4, 2013 at 8:49 PM, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
>  >> that's all true but you can be pretty sure if a "app-store" with
>  >> bundeled applications exists *nobody* would package and maintain
>  >> them as RPM -> everybody would point with his finger to the app
>  > 
>  > No because RPM packages apps *do* have benifits .. otherwise we
>  > wouldn't have this discussion.
>  > 
>  >> if it goes in that direction, and it starts faster than anybody likes
>  >> you do a dramatical harm to the userbase which likes the consistent
>  >> package managment and *really used* conecpt of shared libraries
>  > 
>  > Again those are NOT MUTUALLY EXCLUSIVE. You can have sandboxed *and*
>  > rpm packaged apps at the same time.
>  
>  the most imporant word in your answer is *CAN*
>  
>  but you will not, nobody will package whatever application
>  as RPM if he is fine with the app-store, so you *could*
>  have both but i doubt at the end of the day it will happen 
If no one think that using a rpm is bringing any value, then indeed, no
one will do the job. Now, if someone think this is better for whatever
reasons, then this someone will do the job. 

It seems that your fear is that if people are not forced to make rpm,
they will not see the value of doing so, and so would not do it. 

So if that's the problem, then the solution is to demonstrate the value
of packaging and rpm rather than restricting all others alternatives. 

-- 
Michael Scherer

[Reindl Harald]

Am 04.11.2013 23:50, schrieb Michael Scherer:
>  Le lundi 04 novembre 2013 à 21:02 +0100, Reindl Harald a écrit :
> >
> > Am 04.11.2013 20:56, schrieb drago01:
> >> On Mon, Nov 4, 2013 at 8:49 PM, Reindl Harald <h.reindl(a)thelounge.net&gt;
> wrote:
> >>> that's all true but you can be pretty sure if a "app-store"
> with
> >>> bundeled applications exists *nobody* would package and maintain
> >>> them as RPM -> everybody would point with his finger to the app
> >>
> >> No because RPM packages apps *do* have benifits .. otherwise we
> >> wouldn't have this discussion.
> >>
> >>> if it goes in that direction, and it starts faster than anybody likes
> >>> you do a dramatical harm to the userbase which likes the consistent
> >>> package managment and *really used* conecpt of shared libraries
> >>
> >> Again those are NOT MUTUALLY EXCLUSIVE. You can have sandboxed *and*
> >> rpm packaged apps at the same time.
> >
> > the most imporant word in your answer is *CAN*
> >
> > but you will not, nobody will package whatever application
> > as RPM if he is fine with the app-store, so you *could*
> > have both but i doubt at the end of the day it will happen
>  
>  If no one think that using a rpm is bringing any value, then indeed, no
>  one will do the job. Now, if someone think this is better for whatever
>  reasons, then this someone will do the job. 
>  
>  It seems that your fear is that if people are not forced to make rpm,
>  they will not see the value of doing so, and so would not do it. 
>  
>  So if that's the problem, then the solution is to demonstrate the value
>  of packaging and rpm rather than restricting all others alternatives.  
and that is why the Linux kernel is that successful

there is one person which makes decisions and proves that this is
possible, widely accepted and works over many years, hence this
works longer than Fedora even exists
_____________________

the real problem Fedora has that there is nobody with the power to make
finally decisions and in doubt everybody can do anything and until the
damage is not done things which are not broken are happily fixed

too often changes are done on parts where a lot of people are happy
that they slowly start to stabilize themself, things are changed for
the sake of the change because often people appear to be bored that
things are just working instead look glad on that

honestly, the "Fedora Core" days was better looking forward to 10, 20 years
because there was a clean distinction between "Redhat" and
"fedora-extras"
where it was pretty easy to keep one eye more what is coming from the extras
repo - *no i do not say* that the package from "extras" was bad, i only say
that they from "core" where always safer because their intention was base of
the next enterprise-distribution

[Michael Scherer]

Le mardi 05 novembre 2013 à 00:05 +0100, Reindl Harald a écrit :

>  the real problem Fedora has that there is nobody with the power to
> make
>  finally decisions and in doubt everybody can do anything and until the
>  damage is not done things which are not broken are happily fixed 
If there was such a person or group, and if that person would say "stop
posting now, now we do offer sandbox because i decided', you would
complain as equally as you do now. 

If you want someone who has a final word and a vision, there is Ubuntu
and Mark.

But this whole discussion is going totally off topic, so I will stop
here and now. 
-- 
Michael Scherer

[Adam Williamson]

On Mon, 2013-11-04 at 23:50 +0100, Michael Scherer wrote:
>  Le lundi 04 novembre 2013 à 21:02 +0100, Reindl Harald a écrit :
>  > 
>  > Am 04.11.2013 20:56, schrieb drago01:
>  > > On Mon, Nov 4, 2013 at 8:49 PM, Reindl Harald <h.reindl(a)thelounge.net&gt;
> wrote:
>  > >> that's all true but you can be pretty sure if a "app-store"
> with
>  > >> bundeled applications exists *nobody* would package and maintain
>  > >> them as RPM -> everybody would point with his finger to the app
>  > > 
>  > > No because RPM packages apps *do* have benifits .. otherwise we
>  > > wouldn't have this discussion.
>  > > 
>  > >> if it goes in that direction, and it starts faster than anybody likes
>  > >> you do a dramatical harm to the userbase which likes the consistent
>  > >> package managment and *really used* conecpt of shared libraries
>  > > 
>  > > Again those are NOT MUTUALLY EXCLUSIVE. You can have sandboxed *and*
>  > > rpm packaged apps at the same time.
>  > 
>  > the most imporant word in your answer is *CAN*
>  > 
>  > but you will not, nobody will package whatever application
>  > as RPM if he is fine with the app-store, so you *could*
>  > have both but i doubt at the end of the day it will happen
>  
>  If no one think that using a rpm is bringing any value, then indeed, no
>  one will do the job. Now, if someone think this is better for whatever
>  reasons, then this someone will do the job. 
>  
>  It seems that your fear is that if people are not forced to make rpm,
>  they will not see the value of doing so, and so would not do it. 
>  
>  So if that's the problem, then the solution is to demonstrate the value
>  of packaging and rpm rather than restricting all others alternatives.  
So to me this is the nub of the debate, and it's both fantastically
interesting and fantastically difficult to work out in advance.

In an ideal world things would work the way Michael describes, and also,
the stock market would behave precisely as neat theories based on
rational actors predict, and no-one would have any difficulty solving
the three door problem, and healthcare.gov would never have been
launched in a state in which it could not possibly work...

And in the real world, well, it's the real world. :)

So let me step into my handy Tardis and bring back a vignette from the
Real World after Fedora and other distributions bless upstream app
distribution as a preferred channel:

---

Scene: an office, much like this one.

Manager: ...so, executive summary: you're saying you'd _like_ to spend a
not insubstantial chunk of your fairly expensive time working to jump
through some hoops so our Shiny New Application can be included in these
'downstream distribution' things, but if I insist, you can whack a
button to put it in the Linux App Store and we can go to press with our
announcement tomorrow?

Well-Intentioned Techie A: (gulps)...yes.

Manager: Whack that button, techie. Whack it hard. Now get out of my
office, I have to call the PR department.

Well-Intentioned Techie A: (sighs) OK. So, when will you let me have
some time to work on having the app packaged in distributions further
down the road?

Manager: What were the concrete benefits to us again?

Well-Intentioned Techie A: Err, well, in an extremely theoretical way
that you will never understand no matter how many times I explain it to
you, it probably makes our app - and the rest of the ecosystem! - more
secure.

Manager: Less of this 'ecosystem' crap, Techie, no-one cares about that.
ZDNet is not yelling about any security issues in our product right now,
right?

WITA: Er, no.

Manager: Okay, not my problem, then. What else?

WITA: (sighs, continues with an ever-increasing sense of foreboding)
Well, it might reduce storage and memory usage on the user's system by
an amount that wouldn't really be appreciable and would be difficult for
a non-technical user to associate with our app in the first pl- you're
never going to give me time to work on this, are you?

Manager: No. No, I'm not. But here, have another bottle of rye.

WITA: (sighs, returns to office, resumes drinking)

---

Now after I've collected my Tony awards...I hope you get the point. In
theory, we'd still be able to evangelize the benefits of centralized
distribution in a world where we blessed a form of upstream
distribution. In practice, things may well be messier than that. If
distros move away from the gospel of centralized distribution to a
sufficient extent, we may wind up in a 'tragedy of the commons' where
it's just not enough in anyone's short-term direct interest to invest
the resources in supported centralized distribution, even though many
people would recognize the arguments in its favour on a long-term,
ecosystem-wide level. "We can post it on the store and it'll work on
everyone's system tomorrow" is an *extremely* powerful argument.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Matthew Miller]

On Tue, Nov 05, 2013 at 01:23:01PM -0800, Adam Williamson wrote:
>  So let me step into my handy Tardis and bring back a vignette from
> the
>  Real World after Fedora and other distributions bless upstream app
>  distribution as a preferred channel: 
I'm not sure I can match this for evocativeness, but:

>  Manager: ...so, executive summary: you're saying you'd _like_
> to spend a
>  not insubstantial chunk of your fairly expensive time working to jump
>  through some hoops so our Shiny New Application can be included in these
>  'downstream distribution' things, but if I insist, you can whack a
>  button to put it in the Linux App Store and we can go to press with our
>  announcement tomorrow?
>  
>  Well-Intentioned Techie A: (gulps)...yes.
>  
>  Manager: Whack that button, techie. Whack it hard. Now get out of my
>  office, I have to call the PR department. 
In a different future where there is no such magic button, what brings
enlightenment to the manager? I think maybe the conversation goes much like
yours, except with "and don't bother me about 'getting into downstream
distributions' again".

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Adam Williamson]

On Tue, 2013-11-05 at 16:52 -0500, Matthew Miller wrote:
>  On Tue, Nov 05, 2013 at 01:23:01PM -0800, Adam Williamson wrote:
>  > So let me step into my handy Tardis and bring back a vignette from the
>  > Real World after Fedora and other distributions bless upstream app
>  > distribution as a preferred channel:
>  
>  I'm not sure I can match this for evocativeness, but:
>  
>  > Manager: ...so, executive summary: you're saying you'd _like_ to spend a
>  > not insubstantial chunk of your fairly expensive time working to jump
>  > through some hoops so our Shiny New Application can be included in these
>  > 'downstream distribution' things, but if I insist, you can whack a
>  > button to put it in the Linux App Store and we can go to press with our
>  > announcement tomorrow?
>  > 
>  > Well-Intentioned Techie A: (gulps)...yes.
>  > 
>  > Manager: Whack that button, techie. Whack it hard. Now get out of my
>  > office, I have to call the PR department.
>  
>  In a different future where there is no such magic button, what brings
>  enlightenment to the manager? I think maybe the conversation goes much like
>  yours, except with "and don't bother me about 'getting into downstream
>  distributions' again". 
There's two differences:

1) It's substantially easier for users to get your app from their distro
repos than from your own distribution system
2) It's probably rather more work for you to maintain your own
distribution system

To summarize it cynically - the comparative shittiness of current
third-party distribution methods (various podunk frameworks which don't
really work, non-repo packages, or the old
statically-compiled-binary-in-a-tarball being your only options) works
in favour of distro packaging.

Yes, in an ideal world (as I was saying) we could get everyone on board
with 'distro packaging is better than even a good third party
distribution framework once you get over the initial startup costs!'
even if we improve third party distribution, but in the _real_ world, it
may be the  case that once we make third party distribution X% more
convenient for both sides and X% more officially blessed by
distributions, suddenly no-one cares about distro packaging any more.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Colin Walters]

On Tue, 2013-11-05 at 13:23 -0800, Adam Williamson wrote:
>   If
>  distros move away from the gospel of centralized distribution  
Some people working on technologies in this area may have that as a
goal, but I think it's absolutely crucial to continue to support the
"package" model of application distribution as well.

Consider applications like Boxes or virt-manager - these are tightly
tied into the virtualization libraries which are in turn tightly tied
into the operating system plumbing - and that's fine and makes sense!

The two other cases are:
- Less tightly coupled Free Software 
- Proprietary software

This is a fantastically complex discussion for a number of reasons just
with respect to terminology - for example, Debian has a non-free
repository that is "centralized", or at least more centralized than
Fedora.

I know you had a long mail, but your example didn't state whether 
"Shiny New Application" was Free Software or proprietary, or whether it
was tightly coupled or not, etc.  These aspects matter, and there's a
lot of grey area in the continuum.

But I guess a bottom line is as a member of the upstream GNOME
community, I would argue very much against any application mechanism
which did not allow applications to *also* be shipped in the traditional
package model.

[Olav Vitters]

On Tue, Nov 05, 2013 at 01:23:01PM -0800, Adam Williamson wrote:
>  So let me step into my handy Tardis and bring back a vignette from
> the
>  Real World after Fedora and other distributions bless upstream app
>  distribution as a preferred channel: 
Could you give some practical programs which are impacted by this? From
what I can see, loads of programs are not packaged by a distribution.
They might have a package for one distribution, but then not for
another.

For a manager/techy type situation, I fail to understand practical
programs which would be impacted. Usually manager/techy means
proprietary, in which case you usually have packages for a few
distributions, but not all.

Really popular applications already provide packages for a few
distributions (but again not all).

The intention of these apps are to give an app for a distribution before
it's included within the distribution itself.

If the distribution method is really that more inconvenient, then this
should be addressed. But IMO the app thing is happening anyway. I really
dislike these artificial roadblocks for proprietary software.

The conversation IMO goes more like this:
- Manager: Hey can we provide something on this Linux thing?
- Techy: 20min of tech talk
- Manager looking at his phone 10 secs into the conversation
- Manager: "maybe we go for something less complicated"

vs

Techy: 1st quick n dirty (app), then improve on that (distributions)

-- 
Regards,
Olav

[Michael Scherer]

On Tue, Nov 05, 2013 at 01:23:01PM -0800, Adam Williamson wrote:
>  On Mon, 2013-11-04 at 23:50 +0100, Michael Scherer wrote:
>  > Le lundi 04 novembre 2013 à 21:02 +0100, Reindl Harald a écrit :
>  > > 
>  > > Am 04.11.2013 20:56, schrieb drago01:
>  > > > On Mon, Nov 4, 2013 at 8:49 PM, Reindl Harald
> <h.reindl(a)thelounge.net&gt; wrote:
>  > > >> that's all true but you can be pretty sure if a
> "app-store" with
>  > > >> bundeled applications exists *nobody* would package and maintain
>  > > >> them as RPM -> everybody would point with his finger to the app
>  > > > 
>  > > > No because RPM packages apps *do* have benifits .. otherwise we
>  > > > wouldn't have this discussion.
>  > > > 
>  > > >> if it goes in that direction, and it starts faster than anybody likes
>  > > >> you do a dramatical harm to the userbase which likes the consistent
>  > > >> package managment and *really used* conecpt of shared libraries
>  > > > 
>  > > > Again those are NOT MUTUALLY EXCLUSIVE. You can have sandboxed *and*
>  > > > rpm packaged apps at the same time.
>  > > 
>  > > the most imporant word in your answer is *CAN*
>  > > 
>  > > but you will not, nobody will package whatever application
>  > > as RPM if he is fine with the app-store, so you *could*
>  > > have both but i doubt at the end of the day it will happen
>  > 
>  > If no one think that using a rpm is bringing any value, then indeed, no
>  > one will do the job. Now, if someone think this is better for whatever
>  > reasons, then this someone will do the job. 
>  > 
>  > It seems that your fear is that if people are not forced to make rpm,
>  > they will not see the value of doing so, and so would not do it. 
>  > 
>  > So if that's the problem, then the solution is to demonstrate the value
>  > of packaging and rpm rather than restricting all others alternatives. 
>  
>  So to me this is the nub of the debate, and it's both fantastically
>  interesting and fantastically difficult to work out in advance.
>  
>  In an ideal world things would work the way Michael describes, and also,
>  the stock market would behave precisely as neat theories based on
>  rational actors predict, and no-one would have any difficulty solving
>  the three door problem, and healthcare.gov would never have been
>  launched in a state in which it could not possibly work...
>  
>  And in the real world, well, it's the real world. :) 
Excuse me to remove your bnice piece of anticipation, 
and excuse me to not answer in the same way as I do not have a good idea for now.

While what you show is likely true, there is just 1 single problem, this is not the
future. This is the present.

Currently, if you do not have the big button of your story, you still have a few 
choice as a ISV or upstream ( free or non free, the problem are the same for both,
except that in the case of free software, people will complain to you for stuff 
that you didn't decide to do ):

1) you just distribute nothing, besides a tarball with source code. Or maybe just a gem
or similar. This seems to satisfy perfectly some people who are quite happy of the
sisyphean tasks that is the integration of a always growing pack of line of code, but
strangely
enough, it doesn't suit that well some end-users.

And the choice of version shipped by the distribution is a choice that the distribution
do. So far, this model served us quite well, and frankly, it satisfy most of my needs,
because I have several years of experience.  

But besides some end-users, that's also not satisfying for some upstream, since they 
want to have their code sent to users fast for various reasons, like "having feedback

on new features" ( the faster, the better, if possible the day of release ),
sometime, they want 
to distribute bugfixes or proposed bugfixes. Sometimes they also want to have
a supported version, potentially older. 

For every policy decided by a distro, you can find one reason to do thing differently.
In the end, it all boils down on who decide the version, between the upstream, the 
end users and distribution. And while of course, with enough ressources, everybody can 
choose what he want, there is no one here with a unlimited amount of ressources.
SO in the end, that's just distribution using their power to decide for others,;
because others
either do not have the ressource (users), or spend their ressources on making software
(upstream).

In order to take/give back some choice to upstream and/or end users, people tried
 various systems : 

2) compile stuff in static
That's ugly. And yet, that work enough well for distributing games on Linux since a
few
years (earliest personal example I can find would be Unreal tournament), for 
distributing software used in industry or even plugin. Some upstream do this for now.
Despites us saying "don't do that, it kill kittens, ulrich drepper said
it".


2bis) use some "magical" system, like autoinstall, zeroinstall, etc. They
didn't work that well.
Potentially for chicken and eggs problem, potentially because some problem were left
unsolved.
However, since company like Microsoft and Apple ( or Google ) managed to make it work fine
enough,
this show the technical issues are not really that hard to solve. 

3) compile on every distribution in the native format. That's what Open build system,
from suse, 
is doing. While I wouldn't call that a big success, it is working more than fine. Of
course, 
the maintenance cost is high for complex packages, because distributions prefer to not 
standardize on anything so you have ugly spec files.

4) compile only on the distribution that matter to you, or just the one with the more
perceived
market share. Currently, that basically mean Ubuntu, or for specialized products, that
mean
RHEL, sometime SLES. Some people view that as a subtle form of lock-in. And people
with lesser know distribution usually complain about this. This also bring lots
of subtle issue. PPAs are full of them, between repository incompatibilities,
distribution
problem, conflicts, etc.

5) offer a magic script that install everything. Node.js do that. Salt do that.
That's a bit crappy from security point of view, but so far, the main problem 
is mostly about user education ( ie, training people to not do dumb stuff ).
Because running a shell script on a amazon ec2 instance is not a so big deal. If
you do not trust the script, installing a package from upstream wouldn't be more
trusted.
 

So we have all of those systems, that are already used, each with different success rate 
and issues.
> From there, we can see a few points : 
- the whole issue of who distribute between upstream and distribution is mostly who decide
what
users see and get. Of course, as with any change, people who currently have the
"power" see initiative
to give the power to others as bad, mostly due to human nature because every body deeply
believe to do the
best job, and knowing what is best. No one believe to do a crappy job and yet invest time
in it.
And of course, every group say they are the best suited for that. But this power play is
divisive,
and division doesn't benefit free software.

- posting angry mail on ml and refusing alternatives didn't prevent them from
emerging, 
and from having a moderate success.
PPA are populars, so does OBS. They are not perfect, but they work good enough for people
( and
it seems good enough for us to replicate, despites PPAs being a time bomb, breaking Ubuntu
upgrade
in various way ).
 
- compile stuff as static is a perfectly acceptable system for most OEM. That's
unclean, likely insecure,
that consume memory, but since we as a community do not offer anything better, OEM usually
choose that, and
as long as our only answer to their problems will not solve their issues, they will
continue. 
And despites being problematic, most regular users do not care, OEMs do not care, only
packagers 
do. And no one besides packagers do care about what packagers care, most of the time. The
ressource issues 
will just become mooth as the time pass if not already. My laptop has 8G of ram.
That's more than enough to 
be wasted for static binaries. ( same goes for the disk in my case, and CPU ). And on
security point of view, 
well, that's also a lost cause when people are advocating exchanging security for
speed, ease of use or 
anything ( like "disable selinux or apparmor, it is useless and slow stuff" ),
so not caring about security of libraries is just another step in that direction.


- despites having alternatives, rpm/deb packaging didn't stop being used. In fact,
even more 
interesting, despites having both, this didn't prevent others packaging system to be
created. 
> From emerge to macports, pip, pkgng, there is new system being created
> on a regular basis. 
And people still make rpm and deb, despites being more complex,
gothic and cumbersome
to use than others. It was historically easier to make a gentoo initscript than a sysv
initscript, and yet people
didn't move. Debian package use several file of different formats, is not at all
unified, non parsable by
regular tools, and yet, Debian has a gigantic community making packages. 

So something has to be really really better to disrupt the current model
of rpm/deb and centralized repository. If in the past, none of the attempts did,
I cannot see why suddenly something will.

And finally, having sandboxing system is not the future. This is the present.
People do distribute complete VM in the entreprise side of the life.

Even in Fedora, we already have docker in rawhide, which seems to be quite similar
to what people speculate on what sandboxed application will be :
- some kind of appstore ( aka a central repo )
- working on various distributions, by design
- you get a full OS in bundle, also by design
- isolated from the main system using lxc and likely selinux

Yet, I haven't seen people saying "this shouldn't be offered", or
anyone
thinking this is unacceptable for Fedora, or something that will bring doom to current
linux distribution.

I would also be against having that as a primary way of deploying
applications. But I am fine about giving the possibility, and I am prefectly fine
knowing that some people prefer this, that this solve some people issues.

-- 
Michael Scherer

[Adam Williamson]

On Wed, 2013-11-06 at 19:10 +0100, Michael scherer wrote:

>  > > So if that's the problem, then the solution is to
> demonstrate the value
>  > > of packaging and rpm rather than restricting all others alternatives. 
>  > 
>  > So to me this is the nub of the debate, and it's both fantastically
>  > interesting and fantastically difficult to work out in advance.
>  > 
>  > In an ideal world things would work the way Michael describes, and also,
>  > the stock market would behave precisely as neat theories based on
>  > rational actors predict, and no-one would have any difficulty solving
>  > the three door problem, and healthcare.gov would never have been
>  > launched in a state in which it could not possibly work...
>  > 
>  > And in the real world, well, it's the real world. :)
>  
>  Excuse me to remove your bnice piece of anticipation, 
>  and excuse me to not answer in the same way as I do not have a good idea for now.
>  
>  While what you show is likely true, there is just 1 single problem, this is not the
>  future. This is the present. 
Various people replied along these lines ("you can't be sure it'll
happen that way, and anyway, it's already the case that lots of parties
don't bother with distro packaging"). I'd agree with both of those
points. To summarize my response to that general line of reasoning: I
don't disagree. As the first two lines of my reply said:

"So to me this is the nub of the debate, and it's both fantastically
interesting and fantastically difficult to work out in advance."

It's not a clear calculation _at all_, and it's a pure counterfactual,
so more or less impossible to determine with any certainty. An equally
possible result is that fewer parties _relatively speaking_ have a
strong interest in aiding distro packaging but more parties _absolutely
speaking_ become interested in making software available for Linux at
all, and the upshot of that is that we get more software available both
through the 'third party' mechanism _and_ through distro packaging, and
all is sweetness and rainbows. That's certainly a plausible outcome. I'm
not suggesting I or anyone can be certain exactly what would happen, jus
that this is a sensitive and risk-prone area.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Kevin Kofler]

Adam Williamson wrote:
>  It's not a clear calculation _at all_, and it's a pure
> counterfactual,
>  so more or less impossible to determine with any certainty. An equally
>  possible result is that fewer parties _relatively speaking_ have a
>  strong interest in aiding distro packaging but more parties _absolutely
>  speaking_ become interested in making software available for Linux at
>  all, and the upshot of that is that we get more software available both
>  through the 'third party' mechanism _and_ through distro packaging, and
>  all is sweetness and rainbows. That's certainly a plausible outcome. I'm
>  not suggesting I or anyone can be certain exactly what would happen, jus
>  that this is a sensitive and risk-prone area. 
I don't believe in that at all. I think that the Free Software community is 
happy with the system as it stands now; whom we would attract with an 
alternative system is developers who develop proprietary software and/or who 
hate distribution packaging, and so will never get their stuff into our 
repositories. If a developer is happy with the distro packaging system, why 
would they care about the app system?

        Kevin Kofler

[Rahul Sundaram]

Hi


On Wed, Nov 6, 2013 at 10:11 PM, Kevin Kofler wrote:

>  I don't believe in that at all. I think that the Free Software community is
>  happy with the system as it stands now
>  
Well you should speak for yourself instead of assuming that a large
community has only one view.. I think there is room for improvement and
more than one approach and I also think the way you are expressing your
disagreement (for example, talking about puking etc) is in pretty
distasteful.  You talk about freedom so much while not wanting anyone else
to be free to use an approach you don't prefer.

Rahul

[Chris Murphy]

On Nov 6, 2013, at 8:11 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:

>  I don't believe in that at all. I think that the Free Software
> community is 
>  happy with the system as it stands now; 
In my estimation, there's a better statistical chance you know what makes a frog
happy, than what the free software community is happy with.

Chris Murphy

[Kevin Kofler]

Michael scherer wrote:
>  PPA are populars, so does OBS. They are not perfect, but they work
> good
>  enough for people ( and it seems good enough for us to replicate, despites
>  PPAs being a time bomb, breaking Ubuntu upgrade in various way ). 
Well, these ARE the way if you really need to ship something that cannot go 
into the distribution repository. Bypassing the whole packaging system is 
not.

Of course, depending on who makes the PPAs, the packages can be really 
really crappy, but users know that and do prefer packages from a reviewed 
repository or at least from a PPA done by a decent packager. (Packages done 
by upstream tend to be the crappiest of all.)

        Kevin Kofler

[Mathieu Bridon]

On Mon, 2013-11-04 at 21:02 +0100, Reindl Harald wrote:
>  
>  Am 04.11.2013 20:56, schrieb drago01:
>  > Again those are NOT MUTUALLY EXCLUSIVE. You can have sandboxed *and*
>  > rpm packaged apps at the same time.
>  
>  the most imporant word in your answer is *CAN*
>  
>  but you will not, nobody will package whatever application
>  as RPM if he is fine with the app-store, so you *could*
>  have both but i doubt at the end of the day it will happen 
As Michael said, it will happen if people keep seeing the value in
having RPM packaged apps.

You clearly (and others) see the value in that, but you still think it
won't happen.

Does it mean that even though you personally think that RPM packaged
apps are important, you won't make the effort to package apps?

If you (someone who think it's important) won't do it, then you have to
understand and accept that others (who don't see it as important) might
not want to do it either.


-- 
Mathieu

[Josh Boyer]

On Mon, Nov 4, 2013 at 2:49 PM, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
>  Am 04.11.2013 20:43, schrieb Josh Boyer:
> > On Mon, Nov 4, 2013 at 2:34 PM, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
> >> and why do different distributions exist?
> >> guess what: because they have different goals and userbases
> >>
> >> otherwise we could join all distributions in a big one with
> >> doing all but nothing good
> >>
> >> i started to *really* use Fedora at a time where Ubuntu got
> >> really popular and i took Fedora and built a ecosystem around
> >> it because Fedora is waht it is - don't taint that
> >
> > The addition of a new piece of functionality does not immediately
> > taint or modify the core of what Fedora is.  Maybe instead of just
> > steadfastly asserting there should be no Change, you could work _with_
> > people as they try to include Change to address specific needs that
> > aren't being met.
> >
> > Successful distros are evolutionary projects.  There is no "done" or
> > "final state" with them.  That doesn't mean they rip out the core
> > concepts and start over, but it does mean they adapt to new usecases
> > and challenges as they come up
>
>  that's all true but you can be pretty sure if a "app-store" with
>  bundeled applications exists *nobody* would package and maintain
>  them as RPM -> everybody would point with his finger to the app 
That remains entirely to be seen.  I can certainly see things starting
in the app store while they're new and unstable in terms of ABI/API,
and migrating to the distro as they mature.  I mean, that's
essentially how things work today, it's just that we suck at making it
easy for people to consume those new things right now.  Also, if we
are the ones providing the app store then we're certainly able to
monitor that more closely.

(I'm not entirely sure at what point "app store" came into the
discussion to be honest.  There's a big difference between "app store"
and "containerized apps".)

>  if it goes in that direction, and it starts faster than anybody
> likes
>  you do a dramatical harm to the userbase which likes the consistent
>  package managment and *really used* conecpt of shared libraries 
For a large number of upstream projects, they don't care at all about
being in a distro.  They just focus on their project and someone else
integrates it into the distro.  Containerized apps are just another
way to do that.

I understand your concern and it is something we should watch for, but
I don't think avoiding doing it is going to be a good long term
solution.  Like everything else in life, there has to be balance.

josh

[Mattias Ellert]

mån 2013-11-04 klockan 14:58 -0500 skrev Josh Boyer:

>  For a large number of upstream projects, they don't care at all
> about
>  being in a distro.  They just focus on their project and someone else
>  integrates it into the distro.  Containerized apps are just another
>  way to do that. 
No, it is another way not to do that.

	Mattias

[Josh Boyer]

On Mon, Nov 4, 2013 at 5:17 PM, Mattias Ellert
<mattias.ellert(a)fysast.uu.se&gt; wrote:
>  mån 2013-11-04 klockan 14:58 -0500 skrev Josh Boyer:
>
> > For a large number of upstream projects, they don't care at all about
> > being in a distro.  They just focus on their project and someone else
> > integrates it into the distro.  Containerized apps are just another
> > way to do that.
>
>  No, it is another way not to do that. 
Then don't do it?  That shouldn't prevent someone else from being able to.

josh

[Kevin Kofler]

Josh Boyer wrote:
>  The addition of a new piece of functionality does not immediately
>  taint or modify the core of what Fedora is.  Maybe instead of just
>  steadfastly asserting there should be no Change, you could work _with_
>  people as they try to include Change to address specific needs that
>  aren't being met. 
So now after the "good balance", you bring up the "Change" with a
capital 
'C' (plagiarized from Barack Obama). Can you please cut down on the 
buzzword-loaden rhetoric bullshit?

No, sorry, change is not always for the good. Statistically, a random change 
has 50% probability of not being an improvement. So somebody opposing one 
particular change is not necessarily a change-phobic luddite. You need to 
convince us that the proposal you defend actually makes things better, not 
just different, and I'm not convinced at all (in fact I'm actually convinced 
that it makes things worse), sorry.

        Kevin Kofler

[Kevin Kofler]

I wrote:
>  So now after the "good balance", you bring up the
> "Change" with a capital
>  'C' (plagiarized from Barack Obama). Can you please cut down on the
>  buzzword-loaden rhetoric bullshit? 
PS: Since it has been pointed out to me that it can be misunderstood as 
such, please don't take this as a rant against Obama. It's a rant against 
plagiarizing the "Change" rhetoric to promote just about anything as long as 
it's different. Riding the buzzword wave to promote just about anything with 
a regurgitation of somebody else's fashionable discourse is easy, but not 
the way to win any argument.

        Kevin Kofler

[Florian Weimer]

On 11/04/2013 12:32 PM, Mateusz Marzantowicz wrote:
>  On 04.11.2013 12:18, Florian Müllner wrote: 
> > So what do you suggest? We can either
> >
> > (1) restrict the functionality extension can provide (e.g. "add an icon
> > with a menu to the top bar" - of course that'd mean no alternate-tab,
> > shell-shape, alternative-status-menu etc.)
> >
> > (2) cease development of gnome-shell
> >
> > (1) will cause an understandable outrage as it would mean the end for a
> > large percentage of extensions, and (2) is not an option. 
>  Just see how others does this. Linux Kernel is one example, Django
> is
>  another. This two projects from very different corners are able to
>  provide stable API/ABI for some longer time period. 
Emacs is probably a better example: It's extensible from within the 
running process and shows that it is possible to provide quite a bit of 
backwards compatibility in a GUI application without halting new 
development.  It uses a dynamically-typed extension language, just like 
GNOME Shell.

-- 
Florian Weimer / Red Hat Product Security Team

[Bastien Nocera]

Emacs is more than 30 years old, gnome-shell is nearing 3 years since its first stable
release. When gnome-shell is this mature, I'm sure the extensions breaking will be
less of a problem :)

----- Original Message -----
>  On 11/04/2013 12:32 PM, Mateusz Marzantowicz wrote:
>  > On 04.11.2013 12:18, Florian Müllner wrote:
>  
>  >> So what do you suggest? We can either
>  >>
>  >> (1) restrict the functionality extension can provide (e.g. "add an icon
>  >> with a menu to the top bar" - of course that'd mean no alternate-tab,
>  >> shell-shape, alternative-status-menu etc.)
>  >>
>  >> (2) cease development of gnome-shell
>  >>
>  >> (1) will cause an understandable outrage as it would mean the end for a
>  >> large percentage of extensions, and (2) is not an option.
>  
>  > Just see how others does this. Linux Kernel is one example, Django is
>  > another. This two projects from very different corners are able to
>  > provide stable API/ABI for some longer time period.
>  
>  Emacs is probably a better example: It's extensible from within the
>  running process and shows that it is possible to provide quite a bit of
>  backwards compatibility in a GUI application without halting new
>  development.  It uses a dynamically-typed extension language, just like
>  GNOME Shell.
>  
>  --
>  Florian Weimer / Red Hat Product Security Team
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Matthew Miller]

On Mon, Nov 04, 2013 at 12:18:16PM +0100, Florian Müllner wrote:
>  > GNOME decided to break it all the time (can't even get
> extensions work
>  > from one gnome-shell version to the next one and no gracefully disabling
>  > is still functional breakage).
>  So what do you suggest? We can either
>  (1) restrict the functionality extension can provide (e.g. "add an icon
>  with a menu to the top bar" - of course that'd mean no alternate-tab,
>  shell-shape, alternative-status-menu etc.)
>  (2) cease development of gnome-shell 
I think there's probably a third way. It used to be that Firefox extensions
broke with every update, but now that really rarely happens. That's partly
because the base program has kind of stablized, but also because there's a
nice developer ecosystem, with good supporting documentation and tons of
tutorials. I think it's important to grow that for Gnome Shell, with good
communication about migrating extensions as new versions come out.



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[drago01]

On Mon, Nov 4, 2013 at 4:58 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Mon, Nov 04, 2013 at 12:18:16PM +0100, Florian Müllner wrote:
> > > GNOME decided to break it all the time (can't even get extensions work
> > > from one gnome-shell version to the next one and no gracefully disabling
> > > is still functional breakage).
> > So what do you suggest? We can either
> > (1) restrict the functionality extension can provide (e.g. "add an icon
> > with a menu to the top bar" - of course that'd mean no alternate-tab,
> > shell-shape, alternative-status-menu etc.)
> > (2) cease development of gnome-shell
>
>  I think there's probably a third way. It used to be that Firefox extensions
>  broke with every update, but now that really rarely happens. That's partly
>  because the base program has kind of stablized, but also because there's a
>  nice developer ecosystem, with good supporting documentation and tons of
>  tutorials. I think it's important to grow that for Gnome Shell, with good
>  communication about migrating extensions as new versions come out. 
No sorry but that's nonsense. Tutorials do not change anything here.
The problem is how extension work. You can either have a fixed API
with defined entry points,
which you can commit to keep stable but it would limit what extensions
can do. Or you allow
extensions to change the code directly (through monkey patching etc)
which means they have
the freedom to do whatever they want but at the same time any code
change in the area you modify
directly would break it. Gnome-shell currently does the latter.

[Matthew Miller]

On Mon, Nov 04, 2013 at 05:02:21PM +0100, drago01 wrote:
>  > I think there's probably a third way. It used to be that
> Firefox extensions
>  > broke with every update, but now that really rarely happens. That's partly
>  > because the base program has kind of stablized, but also because there's a
>  > nice developer ecosystem, with good supporting documentation and tons of
>  > tutorials. I think it's important to grow that for Gnome Shell, with good
>  > communication about migrating extensions as new versions come out.
>  
>  No sorry but that's nonsense. Tutorials do not change anything here. The
>  problem is how extension work. You can either have a fixed API with
>  defined entry points, which you can commit to keep stable but it would
>  limit what extensions can do. Or you allow extensions to change the code
>  directly (through monkey patching etc) which means they have the freedom
>  to do whatever they want but at the same time any code change in the area
>  you modify directly would break it. Gnome-shell currently does the latter. 
I don't see how anything you say makes what I said "nonsense". Maybe I just
wasn't clear enough. I'm not suggesting that extensions would be kept
working unmodified. Instead, make it easy for extension authors to keep
their extensions up to date with the changes.

https://wiki.gnome.org/GnomeShell/Extensions#Creating_an_Extension is a good
start, but compare https://developer.mozilla.org/en-US/docs/Extensions. I'm
not meaning to criticize by any means -- I just think this would be a good
area to emulate.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[drago01]

On Mon, Nov 4, 2013 at 5:17 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Mon, Nov 04, 2013 at 05:02:21PM +0100, drago01 wrote:
> > > I think there's probably a third way. It used to be that Firefox extensions
> > > broke with every update, but now that really rarely happens. That's partly
> > > because the base program has kind of stablized, but also because there's a
> > > nice developer ecosystem, with good supporting documentation and tons of
> > > tutorials. I think it's important to grow that for Gnome Shell, with good
> > > communication about migrating extensions as new versions come out.
> >
> > No sorry but that's nonsense. Tutorials do not change anything here. The
> > problem is how extension work. You can either have a fixed API with
> > defined entry points, which you can commit to keep stable but it would
> > limit what extensions can do. Or you allow extensions to change the code
> > directly (through monkey patching etc) which means they have the freedom
> > to do whatever they want but at the same time any code change in the area
> > you modify directly would break it. Gnome-shell currently does the latter.
>
>  I don't see how anything you say makes what I said "nonsense". Maybe I
> just
>  wasn't clear enough. I'm not suggesting that extensions would be kept
>  working unmodified. 
That's how I read your other mail which made no sense to me hence the
"nonsense" ;)

>  Instead, make it easy for extension authors to keep
>  their extensions up to date with the changes. 
Sure but given that extensions can modify pretty much anything that
would imply documenting every code change.
We kind of have that in the code repos but having separate
documentation for everything would not scale
with the man power we have. But given that the code does not change as
much as it used to (that's not a guarantee though)
such problems might become less common in the feature.

Extension authors also have some time to adjust to changes during the
prerelease period.

[Matthew Miller]

On Mon, Nov 04, 2013 at 05:30:06PM +0100, drago01 wrote:
>  > Instead, make it easy for extension authors to keep
>  > their extensions up to date with the changes.
>  Sure but given that extensions can modify pretty much anything that
>  would imply documenting every code change. 
Well, in an ideal world.... :)

But, even given reality, there's some amount of pragmatic information which
could help without needing to go that far. See Firefox again for an example:
https://blog.mozilla.org/addons/2013/09/30/compatibility-for-firefox-25/

And there's this statement:

  Please let me know in the comments if there’s anything
  missing or incorrect on these lists. If your add-on breaks on Firefox 25,
  I’d like to know.

Which, alone, is pretty awesome. Obviously that takes a level of commitment,
including (possibly a lot of) someone's time, but I kind of think that
investment would pay off.


I found this
http://blog.fpmurphy.com/2011/11/updating-gnome-shell-extensions-to-work-...
for Gnome 3.2, but unfortunately nothing like it for newer releases.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[drago01]

On Mon, Nov 4, 2013 at 6:10 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:

>  I found this
>
> http://blog.fpmurphy.com/2011/11/updating-gnome-shell-extensions-to-work-...
>  for Gnome 3.2, but unfortunately nothing like it for newer releases. 
Because we didn't change that API since then. Those changes where
needed when we introduced extension.gnome.org (it is about how
extension are loaded / unloaded) and this hasn't changes since.

[Matthew Miller]

On Mon, Nov 04, 2013 at 06:14:05PM +0100, drago01 wrote:
>  > I found this
>  >
> http://blog.fpmurphy.com/2011/11/updating-gnome-shell-extensions-to-work-...
>  > for Gnome 3.2, but unfortunately nothing like it for newer releases.
>  Because we didn't change that API since then. Those changes where
>  needed when we introduced extension.gnome.org (it is about how
>  extension are loaded / unloaded) and this hasn't changes since. 
But, clearly other things _have_ changed. The larger point was that it'd be
nice to have something like what Mozilla has around documentation and
support for extensions and version updates. Or at least aiming in that
direction.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Owen Taylor]

On Mon, 2013-11-04 at 10:58 -0500, Matthew Miller wrote:
>  On Mon, Nov 04, 2013 at 12:18:16PM +0100, Florian Müllner wrote:
>  > > GNOME decided to break it all the time (can't even get extensions work
>  > > from one gnome-shell version to the next one and no gracefully disabling
>  > > is still functional breakage).
>  > So what do you suggest? We can either
>  > (1) restrict the functionality extension can provide (e.g. "add an icon
>  > with a menu to the top bar" - of course that'd mean no alternate-tab,
>  > shell-shape, alternative-status-menu etc.)
>  > (2) cease development of gnome-shell
>  
>  I think there's probably a third way. It used to be that Firefox extensions
>  broke with every update, but now that really rarely happens. That's partly
>  because the base program has kind of stablized, but also because there's a
>  nice developer ecosystem, with good supporting documentation and tons of
>  tutorials. I think it's important to grow that for Gnome Shell, with good
>  communication about migrating extensions as new versions come out. 
Firefox intentionally avoided creating any sort of API for extensions
for a number of years, which allowed them to see what sort of things
people wanted to do and how to create an API. That was the foundation of
the Firefox ecosystem and inspired me. We may also eventually create
more of an API for shell extensions - it remains to be seen.

Without doing that, there are a number of things we can do, including.

 * Improve documentation of extension creation. The documentation about
   how to create an extension is fragmentary and scattered.
 * Improve documentation of the shell codebase. Never hurts!
 * Have VM images available for extension testing when a GNOME release
   freezes.
 * Actively notify extension author to update their extension for the
   next release.
 
I'd like to invite anybody who or has ideas or wants to help out with
this  to take this up further in desktop(a)lists.fedoraproject.org or,
better, in GNOME communication channels - this is a long ways from
subject of this thread. :-)

- Owen

[Bastien Nocera]

You're confusing stand-alone applications and extensions to the core desktop.
An easy mistake to make.

----- Original Message -----
>  
>  Le Dim 3 novembre 2013 19:34, drago01 a écrit :
>  > On Sun, Nov 3, 2013 at 6:44 PM, Reindl Harald <h.reindl(a)thelounge.net&gt;
>  > wrote:
>  >
>  >> since it is a free operating system it does not need to be commerical
>  >> successfull and so it needs to satisfy it's *existing* and potential
>  >> userbase
>  >> but not obsessive attrative for *everybody*
>  >
>  >
>  > No. If you loose to the competion you become irrelevant which means
>  > less / no support from third parties, less (new) contributors etc etc.
>  
>  The competition worked hard at API stability. Even abandoned experiments
>  like silverlight are going to work identically for years in new os
>  versions.
>  
>  GNOME decided to break it all the time (can't even get extensions work
>  from one gnome-shell version to the next one and no gracefully disabling
>  is still functional breakage).
>  
>  And thus it 'lost to the competition'. No amount of indirection and
>  sandboxing is going to hide the utter lack of regard for stability of our
>  core desktop project
>  
>  --
>  Nicolas Mailhot
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Nicolas Mailhot]

Le Lun 4 novembre 2013 12:28, Bastien Nocera a écrit :
>  You're confusing stand-alone applications and extensions to the
> core
>  desktop.
>  An easy mistake to make. 
And the distinction has zero merit for the end-users you want to won

And I suspect it has also zero merit for the famous third-party apps that
want to integrate in their target desktops

-- 
Nicolas Mailhot

[Matthias Clasen]

On Mon, 2013-11-04 at 11:37 +0100, Nicolas Mailhot wrote:

>  GNOME decided to break it all the time (can't even get extensions
> work
>  from one gnome-shell version to the next one and no gracefully disabling
>  is still functional breakage). 
So, you take the one API that is explicitly declared non-stable to judge
GNOME wrt to API stability ? Not a very strong case, I'm afraid.

[Kevin Kofler]

Chris Murphy wrote:
>  Right, because that's a model for success that shouldn't be
> either
>  emulated or improved upon, it's better for each little fiefdom's paradise
>  to erect walls to ensure cross influence isn't happening. 
Your insulting the Free Software community as a "fiefdom" really offends me.

>  And that word we you keep using? I don't think it means, what you
> think it
>  means. Try to find the huevos to use the word I, seeing as that's what you
>  mean. 
As your dictionary would tell you (I could point you to 
http://en.wiktionary.org/wiki/we#Pronoun , but you probably only believe 
proprietary dictionaries), "we" means "I and at least 1 other person".
And 
there are actually several people agreeing with me, so "we" is the correct 
pronoun to use.

>  What you're arguing for is no one should like, or should have the
> choice
>  of liking let alone having "Apple-like" apps, or better. Yes, let's have
>  no choice for apps that are sometimes complete blackboxes, that run
>  contained from each other, from a monostore that collects a perpetual 30%
>  finder's fee, and also no options to improve upon this model without the
>  tie in. 
You write that as if "complete blackboxes" and "a monostore that collects a

perpetual 30%" parasite middleman tax were a good thing. Those stores also 
typically have barriers to entry in the form of one-time fees which mean 
people distributing their software free of charge actually LOSE money on 
them (a system to subtly pressure developers into making their software 
payware and thus also cashing in on commissions, all at the detriment of 
you, the user). And their terms are usually very unfriendly to Free 
Software. (According to the FSF, at least Apple's terms are NOT compatible 
with the GPL, and they got FSF-owned GPLed software pulled from the store 
due to that. And of course, Apple's user-unfriendly "if in doubt, delete it"

policy made it easy to get it pulled, Apple didn't even try to argue the 
issue, let alone consider changing their terms.)

Sure, we could make app stores which are less abusive (e.g. by having terms 
compatible with Free Software licenses, by listing software distributed at 
no charge without charging for the listing, etc.), but the app store model 
is still not designed for us in many ways, as I already described in my 
previous post (and you ignored in your reply).

>  You're proposing a continuation of the adolescent state of Linux
> on the
>  Desktop with its barriers to growing the market. Yes, let's build
>  artificial walls keeping out new users and developers who don't agree with
>  the existing community worldview who might, duh, change the platform to
>  meet their needs. That's just too scary. 
I disagree with the premise that to get anywhere, we would need to bend over 
backwards to the proprietary market and adopt their inferior software 
distribution strategies. If that were true, we could give up right here, 
we'd have already lost.

>  Essentially all you're arguing for is a different version of
> closed that
>  just so happens to cost no money. 
It's not just about the money. It's also about your freedoms as a user.

Now I do also think that being free of charge is a great property of our 
repository system that it would suck to throw away! And the freedoms to 
redistribute software with or without modification that Free Software 
licenses ensure also allow this model to work. (Hint: If your license does 
not allow the inclusion of the software in our free-of-charge repositories, 
it is definitely NOT a Free Software license. Of course, the converse does 
not hold, but we do not allow proprietary freeware in Fedora repositories by 
policy, even where the license would allow us to redistribute it, and IMHO 
that's a good policy.)

>  OH WAIT, OS X is now free! 
OS X is actually NOT free (of charge). It is tied to the hardware in a shady 
bundling scheme (neither can you buy a Mac without OS X, nor are you allowed 
by the restrictive license to run OS X on any other machine), and thus the 
OS is actually paid for by buying the hardware. They may have stopped 
charging for upgrades (I haven't followed the news there), but that doesn't 
mean you aren't paying for the initial copy!

And of course OS X is most definitely not Free as in Speech.

>  Making it easier for free and non-free apps to actually work on a
> platform
>  isn't going to kill it. It's like fertilizer. Instead of advocating
>  platform sabotage as your comforting pacifier, how about you just not use,
>  support, or advocate whatever apps you don't like for whatever subjective
>  reasons you don't like them? 
Polluting our ecosystem with app stores is the "platform sabotage"!

Not only does this infect our Free (as in Speech) systems with parasitic 
proprietary software, but it is also sabotaging one of our core technical 
advantages (the repository and dependency resolution system) which are a 
direct consequence of the Free Software licensing model (proprietary 
software has a really hard time working with that model for several reasons, 
which is why its developers are pushing so hard for the app store model).

>  If Adobe were to want Photoshop on a linux desktop, I think that
> would be
>  great news. It would be hugely disruptive. 
Hugely disruptive to your freedom, indeed… What's wrong with GIMP?

        Kevin Kofler

[Olav Vitters]

On Mon, Nov 04, 2013 at 06:19:48PM +0100, Kevin Kofler wrote:
>  I disagree with the premise that to get anywhere, we would need to
> bend over 
>  backwards to the proprietary market and adopt their inferior software 
>  distribution strategies. If that were true, we could give up right here, 
>  we'd have already lost. 
[..]
>  > If Adobe were to want Photoshop on a linux desktop, I think that
> would be
>  > great news. It would be hugely disruptive.
>  
>  Hugely disruptive to your freedom, indeed… What's wrong with GIMP? 
I don't get why you want to force your view of freedom onto everyone.

These sandboxed applications is not just for proprietary software. I
don't think it'll replace the current distribution model. It will
generate some competition. IMO competition is good, instead of
preventing sandboxed applications, show that the packaged applications
are preferred.

Now such distribution of applications also easily allow proprietary
applications: Awesome, finally! Easy to run Steam, Photoshop, etc.

The kernel is GPL and doesn't force this licence on Adobe. You can have
whatever license you want as application. These sandboxed applications
do suffer from various drawbacks, so better to believe in your solution
than to try and block another view IMO.

-- 
Regards,
Olav

[Simo Sorce]

On Mon, 2013-11-04 at 18:19 +0100, Kevin Kofler wrote:
>  Chris Murphy wrote:
>  > Right, because that's a model for success that shouldn't be either
>  > emulated or improved upon, it's better for each little fiefdom's paradise
>  > to erect walls to ensure cross influence isn't happening.
>  
>  Your insulting the Free Software community as a "fiefdom" really offends me.
Well Kevin, I normally agree with a lot of what you say, but if
"fiefdom" offends you, your pretense to decide for the users *really*
offends me.

I will not cite every passage here, but you keep complaining that
allowing a different distribution model somehow implicitly will cast
doom on Free Software.

First of all that is plain nonsense, the distribution model has nothing
to do with licenses and a Free software App store is no more proprietary
than a distribution specific repository, which in our case is exactly
the default "Fedora App Store" if you want.

But what I find terrible is that you want to make technical decisions
that *limit* users freedom, and this is *inexcusable*.

One of the most important things about freedom is to let the user be
*free*. Yes, to the point he can entrap himself. Our duty as Free
Software developers is to provide Free Software alternatives, not to
make life difficult for our users to try to force them in our own world
view, that's what totalitarianism is about.

Users will choose anyway, so the only thing you attain when trying to
put bars around a user is to have the users go away. Nobody likes cages
not even if they are made of Free Software bars.

>  Hugely disruptive to your freedom, indeed… What's wrong with
> GIMP? 
Yeah and what's wrong with the *actual* Freedom to choose what to use ?

We are not talking about distributing proprietary apps in fedora or
making them better than Free Software apps, so stop being stubborn and
look at the reality of things. Users want a better experience, and
upstreams are often in a position to do so, we just need to provide them
with the tools to do it w/o compromising the platform in the process.

A system that allows a user to install sandboxed[*] applications is
better than what we have now for some cases, and I see no reason why you
should be so upset about allowing a technical solution to a problem
users have whether you like what they are going to do with it or not.

Simo.



* and *ideally* I mean SELinux sanbdboxed with specific APIs that must
be used to interact with the rest of the system, so that the application
doesn't have free reign over users files.

-- 
Simo Sorce * Red Hat, Inc * New York

[Kevin Kofler]

Simo Sorce wrote:
>  * and *ideally* I mean SELinux sanbdboxed with specific APIs that
> must
>  be used to interact with the rest of the system, so that the application
>  doesn't have free reign over users files. 
So you want to remove my freedom to disable SELinux? <SARCASM>Way to go…
</SARCASM>

        Kevin Kofler

[Simo Sorce]

On Wed, 2013-11-06 at 01:13 +0100, Kevin Kofler wrote:
>  Simo Sorce wrote:
>  > * and *ideally* I mean SELinux sanbdboxed with specific APIs that must
>  > be used to interact with the rest of the system, so that the application
>  > doesn't have free reign over users files.
>  
>  So you want to remove my freedom to disable SELinux? <SARCASM>Way to go…
>  </SARCASM> 
If this is all you have to say about what I wrote (strawman on a note
and ignore completely the rest) you have nothing valid to say in this
discussion.

Go away troll.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[Kevin Kofler]

Simo Sorce wrote:

>  On Wed, 2013-11-06 at 01:13 +0100, Kevin Kofler wrote:
> > Simo Sorce wrote:
> > > * and *ideally* I mean SELinux sanbdboxed with specific APIs that must
> > > be used to interact with the rest of the system, so that the
> > > application doesn't have free reign over users files.
> > 
> > So you want to remove my freedom to disable SELinux? <SARCASM>Way to go…
> > </SARCASM>
>  
>  If this is all you have to say about what I wrote (strawman on a note
>  and ignore completely the rest) you have nothing valid to say in this
>  discussion. 
If the system relies on SELinux to sandbox apps, it means that SELinux 
becomes mandatory to use it, which definitely does remove my freedom to 
disable it. So where's the strawman?

        Kevin Kofler

[Tadej Janež]

Kevin,

On Thu, 2013-11-07 at 04:12 +0100, Kevin Kofler wrote: 
>  So where's the strawman? 
please stop with this.

Simo wrote a rather long email post and argued he's view on users'
freedom and all you did in reply was to nitpick on a footnote.

Or in Simo's words again:

On Tue, 2013-11-05 at 23:12 -0500, Simo Sorce wrote:
>  If this is all you have to say about what I wrote (strawman on a
> note
>  and ignore completely the rest) you have nothing valid to say in this
>  discussion.  
Regards,
Tadej

[Daniel J Walsh]

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

On 11/06/2013 10:12 PM, Kevin Kofler wrote:
>  Simo Sorce wrote:
>  
> > On Wed, 2013-11-06 at 01:13 +0100, Kevin Kofler wrote:
> >> Simo Sorce wrote:
> >>> * and *ideally* I mean SELinux sanbdboxed with specific APIs that
> >>> must be used to interact with the rest of the system, so that the 
> >>> application doesn't have free reign over users files.
> >> 
> >> So you want to remove my freedom to disable SELinux? <SARCASM>Way to
> >> go… </SARCASM>
> > 
> > If this is all you have to say about what I wrote (strawman on a note and
> > ignore completely the rest) you have nothing valid to say in this 
> > discussion.
>  
>  If the system relies on SELinux to sandbox apps, it means that SELinux 
>  becomes mandatory to use it, which definitely does remove my freedom to 
>  disable it. So where's the strawman?
>  
>  Kevin Kofler
>   
There will not be a requirement to run with SELinux.  We can also mitigate
some of the risks with using the namespacing, mounting over ~ and /tmp.  As
well as user_namespace if it is working well.  Of course DAC permissions and
capabilities will still be in place.

Security is about layers.  Removing SELiux will make it less secure but not
totally insecure.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJ7lZIACgkQrlYvE4MpobOyJwCg5lrmiMx7Os8wGWN9PoreJPjE
> 5cYAnROJXHeqnFYhVL0st2W58I3NLpzi
> =+5uZ
> -----END PGP SIGNATURE-----

[Ray Strode]

Hi,

I think this is a pretty good starting point for our development direction, and
sets the stage for us making positive progress in the new working group model.

I do think we should keep it open to tweaks in the future as things
play out, (at
the discretion of the 9 members on the working group).  In other words, I think
it lays a solid outline for enabling us all to know which direction to go, but
i want to make sure if it doesn't ever "get in the way". The working
group should
treat it as a living document that gets updated as necessary to
reflect changes in
the landscape.

Some comments inline below (mostly nits):

>  Fedora Workstation PRD
>
>  Mission statement
>  The Fedora Workstation working group aims to create  a reliable,
>  user-friendly and powerful operating system for laptops and PC hardware.
>  The system will primary be aimed at providing a platform for development 
Extra
space between "create" and "a reliable"
s/primary/primarily/

>  Target audience
>  General:
>  Programming Environment: web languages and tools, open source databases, IDE,
>  Compilers, debug tools, performance monitoring
>  Desktop apps should be sufficient to make this system the users's only computer.
s/users's/user's/

While I'd certainly like us to aim more generally, I understand we have to have
some focus, and given the technical pre-existing userbase this is a pretty good
one.

I think if we do a good job, we'll be able to attract all sorts of users
outside of our prescribed target audience, though.

>  Case 1: Student
>  Engineering/CS student who needs a personal system for software class wor and
>  personal projects. Software class work may require particular tool chain
>  versions. Tries out new versions of open source applications when released.
>  Uses computer to play games. 
s/class wor/classwork/

I think this is a good one to target, because the student pool is a good place
to recruit new contributors, and they're more likely to show up if we're making
something they want to use.

>  Ability to play 3D games from commercial publishers distributing
> games for
>  Linux. 
makes sense.

>  Multiple developer environments i.e. school standard for class work,
>  latest tools for personal use. 
s/i.e./, e.g.,/

I guess this may also involve a virtual machine, if the class is standardizing
on some windows tools.

>  Case 2: Independent Developer
>  Personal development system for an independent software developer doing
>  contract work or developing apps for a new opportunity.
>
>  Desktop Apps: Up to date desktop with email client, browser, productivity
>  suite, messaging, and  complete set of desktop apps and utilities.  Desktop
>  apps should be sufficient to make  this system the developer's only computer.
s/and  complete/and a complete/
s/make  this/make this/

[... snip other use cases that sound good ...]

>  Other users
>  While the developer workstation is the main target of this system and what we
>  try to design this for, we do of course also welcome other users to the
>  Fedora Workstation. In fact many of the changes and improvements we expect to
>  implement for developers will be equally beneficial to other user segments, 
I think
this is a really important point.  Developers are users, too,
just trying
to get their work done.  We should make sure the OS doesn't get in the way, and
that it doesn't enforce artificial barriers to entry.  Just because a user may
know how the sausage is made, doesn't mean we should make them stuff their own
(so to speak).  And if a user/developer doesn't know the inner workings of
Fedora, that's okay, too.  We should be enabling the user to get the things
done he/she cares about, not forcing them to learn the things we care about.

There should be no "You must be this tall to ride Fedora Workstation" signs.


>  Overall plans and policies for the product
>  Bullet list numerating the technical goals and design principles of the product 
s/numerating/enumerating/. Though, maybe the fact that it's a bullet list is
self-evident.  How about just, "Technical goals and design principles:"

>  Robust Upgrades
>  Upgrading the system multiple times through the upgrade process should give a
>  result that is the same as an original install of Fedora Workstation. Upgrade
>  should be a safe and process that never leaves the system needing manual
>  intervention. 
safe and what? safe and pleasant? safe and reliable?  It might be good to have
some notion of frequency of updates.  Do we keep them asynchronous?  Do we ask
rel-eng to queue them up into batches?  I've seen some people complain about
the "fedora firehose".  Maybe that's a discussion for a different time, and
not
this document.  I don't know.

>  Encapsulation of development environments 
[...]
>  Quality releases 
[...]
>  Container based application install 
[...]

I'd reorder these so they are grouped better.  Put Encapsulation and Containers
next to each other, and put Quality Releases and Robust Upgrades next to each
other, too.

>  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. 
s/working/collaborating/

Drop one of the "for instance" fragments from this sentence.

So we're not going to host and non-free software, but we are going to
facilitate installing non-free software on the back end (by maintaining
relationships with ISVs).  What about facillating it on the front end?  Are we
going to do anything in the OS to help the user get to the non-fedora software
they want access to? Access from the app installer?  Help documents linking to
instructions?  I assume there are limits to what we can do, but I don't know
what they are.

>  Fedora ecosystem integration 
[... snip good bits about
integrating with output of other working groups ...]

>  Core Platform Components
>  The Workstation working group will define a set of packages that are
>  considered required be installed in order for the system to qualify as a
>  Fedora Workstation. Through policy users will be strongly advised against
>  uninstalling any of these packages and there will also be no option in the
>  graphical software installer to uninstall them. Any optional packages for the
>  Fedora Workstation can not obsolete or in any other way try to remove or
>  disable these packages. 
I assume, then, that there may ultimately be derivative
projects that switch
out some core platform components. I guess they won't carry the "Fedora
Workstation" name. I guess, at some point, we should figure out the branding
story there, though maybe that's a bridge we'll cross when we come to it?

>  These installed packages will together form the basis of the API and
> service
>  promises the system makes to 3rd party developers. 
Makes sense.  We have to have a
solid platform with well defined interfaces, if
we want ISV buy in.

[... snip sensible paragraph talking about minimum software
integration requirements ...]

>  The working group will also specify policies in terms of branding,
> themeing
>  and desktop graphics. 
s/themeing/theming/

>  Work model 
>  We will at any given time try to have one major engineering effort
> underway
>  for the Fedora Workstation. The definition of a major engineering effort is
>  something that requires changes in a wide set of packages and tools. At the
>  same time we will be working on smaller projects to improve various aspects
>  of the distribution and also setting things up to be ready for the next major
>  effort. We will try to announce and plan these things well in advance, but
>  putting up a public timeline, but of course resources and changing market
>  conditions might make changes to the plans necessary on an ongoing basis. 
I think it's good the document formalizes that we should be focused.  I do think
the number of focal points may increase down the road if we scale up
contributors.
If that happens, we can update the text, I guess.

>  Marketable features
>  Each release is to have at least one item developed for it that we present as
>  a 'developer feature'. These items might be small or large in terms of the
>  effort behind them, but it they will be a core part of our messaging of being
>  a great first choice for developers. Examples include Software collections,
>  Developer Assistant, LinuxApps, new features in Boxes, IDE integration
>  and so on. 
I guess we should make sure that whatever that feature is, it's
showcased on our
live image (or at least testable on the image).

>  Other tasks for working group
>  The working group will also be responsible for defining release schedule
>  while also taking the needs of the other working groups into consideration
>  and the resources available from the Fedora infrastructure team. 
Should mention
Fedora QA next to Fedora infrastructure.

--Ray

[Paul W. Frields]

On Mon, Nov 04, 2013 at 09:21:15AM -0500, Ray Strode wrote:
>  I think this is a pretty good starting point for our development
>  direction, and sets the stage for us making positive progress in the
>  new working group model.
>  
>  I do think we should keep it open to tweaks in the future as things
>  play out, (at the discretion of the 9 members on the working group).
>  In other words, I think it lays a solid outline for enabling us all
>  to know which direction to go, but i want to make sure if it doesn't
>  ever "get in the way". The working group should treat it as a living
>  document that gets updated as necessary to reflect changes in the
>  landscape. 
Agreed, it's a good start.  One question...

>  > Case 2: Independent Developer
>  > Personal development system for an independent software developer doing
>  > contract work or developing apps for a new opportunity.
>  >
>  > Desktop Apps: Up to date desktop with email client, browser, productivity
>  > suite, messaging, and  complete set of desktop apps and utilities.  Desktop
>  > apps should be sufficient to make  this system the developer's only computer.
>  s/and  complete/and a complete/
>  s/make  this/make this/
>  
>  [... snip other use cases that sound good ...]
>  
>  > Other users
>  > While the developer workstation is the main target of this system and what we
>  > try to design this for, we do of course also welcome other users to the
>  > Fedora Workstation. In fact many of the changes and improvements we expect to
>  > implement for developers will be equally beneficial to other user segments,
>  I think this is a really important point.  Developers are users, too,
>  just trying
>  to get their work done.  We should make sure the OS doesn't get in the way, and
>  that it doesn't enforce artificial barriers to entry.  Just because a user may
>  know how the sausage is made, doesn't mean we should make them stuff their own
>  (so to speak).  And if a user/developer doesn't know the inner workings of
>  Fedora, that's okay, too.  We should be enabling the user to get the things
>  done he/she cares about, not forcing them to learn the things we care about.
>  
>  There should be no "You must be this tall to ride Fedora Workstation" signs.
[...snip...]

Is it the intent that the developer cases here completely subsume the
case of a developer who is working primarily on Fedora itself
(including the Worsktation)?  Perhaps we should call that out to
correctly prioritize integration of the various developer tools
currently available or planned for the Workstation.

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
    The open source story continues to grow: http://opensource.com

[Ray Strode]

Hi,

----- Original Message -----
>  > We should be enabling the user to get the things
>  > done he/she cares about, not forcing them to learn the things we care
>  > about.
>  > 
>  > There should be no "You must be this tall to ride Fedora Workstation"
>  > signs.
>  [...snip...]
>  
>  Is it the intent that the developer cases here completely subsume the
>  case of a developer who is working primarily on Fedora itself
>  (including the Worsktation)?  Perhaps we should call that out to
>  correctly prioritize integration of the various developer tools
>  currently available or planned for the Workstation. 
That's a good point, too. My mail is trying to make sure we consider 
developers who don't work on Fedora, but just use Fedora for development.
Paul makes a very reasonable point that we should be clear to accomodate 
(and not alienate) ourselves (Fedora contributors) as well.

So, as a throw-away example..., It might not make sense to have fedpkg in
the default install, but having an easily obtainable Fedora SDK of sorts
that includes all the bits needed to get up and going might be a good idea.

--Ray

[Ryan Lerch]

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

[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" <rlerch(a)redhat.com&gt;
To: "Discussions about development for the Fedora desktop"
<desktop(a)lists.fedoraproject.org&gt;, devel(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Miloslav Trmač]

On Sat, Nov 2, 2013 at 5:20 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  I think it is a very bad idea to try to explicitly and officially
> support
>  third-party software, especially proprietary third-party software. 
The thing is, making third-party software easier to maintain and
deploy will in the vast majority of causes also make in-distribution
software easier to maintain and deploy.  And being actively hostile to
third-party software, feeling free to break APIs and ABIs because Open
Source can in theory adapt, and, in the extreme, celebrating actions
that are hostile to third-party software, often ends up to also being
hostile to in-distribution software with limited number of interested
contributors.

Look at all the software that has been written for GTK1 and obsolete
libraries that hasn't been ported and therefore no longer runs on
Fedora.  Wouldn't it have been nice to continue to have a practical
option to use that software, even if it doesn't integrate that well
and it no longer has an active maintainer?
     Mirek

[Reindl Harald]

Am 05.11.2013 17:22, schrieb Miloslav Trmač:
>  Look at all the software that has been written for GTK1 and obsolete
>  libraries that hasn't been ported and therefore no longer runs on
>  Fedora.  Wouldn't it have been nice to continue to have a practical
>  option to use that software, even if it doesn't integrate that well
>  and it no longer has an active maintainer? 
no because exactly that is terrible from security point of view
this means unmaintained code careless in the distribution

you can be pretty sure that in the case bad tings happening later
Fedora as distribution and Linux at all will be made responsible
for such bad behavior "look they have the same troubles and no
longer more secure than OSX and Windows"

[Kevin Kofler]

Miloslav Trmač wrote:
>  Look at all the software that has been written for GTK1 and obsolete
>  libraries that hasn't been ported and therefore no longer runs on
>  Fedora.  Wouldn't it have been nice to continue to have a practical
>  option to use that software, even if it doesn't integrate that well
>  and it no longer has an active maintainer? 
You're talking to the person who is doing most of the maintenance effort on 
qt3 and kdelibs3 and who is always vetoing any proposals to retire them.

I do care about keeping the stuff we ship working, a lot even. But keeping 
compatibility libraries for old sonames where a simple rebuild is enough to 
fix all the software we ship is just useless. Compatibility libraries only 
make sense where porting is not trivial.

        Kevin Kofler

[Paul W. Frields]

On Fri, Nov 01, 2013 at 10:24:20AM -0400, 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. 
Here's a statement we may need to better clarify on p. 3:

"The working group will also specify policies in terms of branding,
themeing and desktop graphics."

I think we should be clear that any branding efforts need to fit into
the overall branding framework of Fedora.  We should be careful to
avoid having branding diverge between the products to an extent that
makes it harder for us to identify them as part of a family of Fedora
products.

In my time as an FPL, I worked extensively with Fedora folks on
trademark and brand guidelines.  I suspect Robyn has done quite the
same wherever possible.  It would be a step backward to make it harder
for people to readily identify any of the Fedora products with
Fedora.

This is really a suggestion for all the working groups, so I'm cc'ing
server@ and cloud@ lists too.

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
    The open source story continues to grow: http://opensource.com

[Frank Murphy]

On Fri, 01 Nov 2013 10:24:20 -0400
Christian Fredrik Kalager Schaller <cschalle(a)redhat.com&gt; 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

[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" <frankly3d(a)gmail.com&gt;
>  To: devel(a)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 <cschalle(a)redhat.com&gt; 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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct