I wanted to resurface the third party repository topic before we get to next week's meeting. Currently we have the following page drafted that discusses the new disabled repo feature currently in Fedora 22 Workstation:
https://fedoraproject.org/wiki/Workstation/3rdPartyApps
Currently there's a policy from the Council (nee Board) on third party repos here:
https://fedoraproject.org/wiki/Third_Party_Repository_Policy
This policy doesn't address one of the problems I believe we're trying to solve in software -- making developer access to non-libre (but legally OK) tools on Fedora less convoluted and burdensome.
So there's not just the question of implementation and curation, but also getting a policy change approved by the Council.
On Thu, Feb 26, 2015 at 8:56 AM, Paul W. Frields stickster@gmail.com wrote:
I wanted to resurface the third party repository topic before we get to next week's meeting. Currently we have the following page drafted that discusses the new disabled repo feature currently in Fedora 22 Workstation:
https://fedoraproject.org/wiki/Workstation/3rdPartyApps
Currently there's a policy from the Council (nee Board) on third party repos here:
https://fedoraproject.org/wiki/Third_Party_Repository_Policy
Actually, that policy was written by FESCo. As noted on the bottom of the page, it's a FESCo policy which means changes likely need to go through them.
This policy doesn't address one of the problems I believe we're trying to solve in software -- making developer access to non-libre (but legally OK) tools on Fedora less convoluted and burdensome.
So there's not just the question of implementation and curation, but also getting a policy change approved by the Council.
For clarification the Board did review the FESCo policy at this meeting:
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-01-23/fedora_board.20...
The two key points here are:
"The board believes that shipping repository metadata that points at non-free software is incompatible with Fedora's foundations"
and
"The board believes that reducing technical barriers to explicit user choice to install third-party software (non-free or otherwise) is compatible with Fedora's foundations."
The latter statement led to some of the disabled repo work that Richard did, IIRC. It leaves a lot open to interpretation.
josh
On 26 February 2015 at 14:35, Josh Boyer jwboyer@fedoraproject.org wrote:
These are the latest designs from Allan that I've implemented in GNOME Software in F22 and rawhide: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/sof...
"The board believes that shipping repository metadata that points at non-free software is incompatible with Fedora's foundations" and "The board believes that reducing technical barriers to explicit user choice to install third-party software (non-free or otherwise) is compatible with Fedora's foundations."
I had trouble interpreting those two statements, given that the only technical barrier for finding non-free or not-yet-in-fedora software *is* repo metadata itself. I assumed the first statement actually meant "shipping enabled repository metadata" so we don't show it by default without some other important step.
The latter statement led to some of the disabled repo work that Richard did, IIRC. It leaves a lot open to interpretation.
Right, as a simple proposal, would it be acceptable for a package to install something like this into /etc/yum.repos.d:
[google-chrome] name=google-chrome baseurl=http://dl.google.com/linux/chrome/rpm/stable/x86_64 enabled=0 gpgcheck=1 repo_gpgcheck=1 enabled_metadata=1 gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub
So the only time we'd access that repo is with PackageKit when searching with gnome-software, and we'd only prompt to enable the repo if it matched a search keyword like "chrome", and then did that with a big dialog like the mockups warning about the perils and morality of using nonfree software. Using dnf or yum it would be completely invisible due to the enabled=0 line. This was basically my proposal here: http://blogs.gnome.org/hughsie/2015/01/09/finding-hidden-applications-with-g... which didn't seem too controversial at the time.
I imagined that we'd ship a fedora-repos-extra package which we could pull onto just the workstation product using comps, but I'm open for ideas.
Richard
On Thu, 2015-02-26 at 14:58 +0000, Richard Hughes wrote:
On 26 February 2015 at 14:35, Josh Boyer jwboyer@fedoraproject.org wrote:
These are the latest designs from Allan that I've implemented in GNOME Software in F22 and rawhide: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/sof...
This may be nitpicking, but what about the cases for things that ARE free and open-source, but may still be illegal in certain jurisdictions? (Such as patent-encumbered codecs).
"The board believes that shipping repository metadata that points at non-free software is incompatible with Fedora's foundations" and "The board believes that reducing technical barriers to explicit user choice to install third-party software (non-free or otherwise) is compatible with Fedora's foundations."
I had trouble interpreting those two statements, given that the only technical barrier for finding non-free or not-yet-in-fedora software *is* repo metadata itself. I assumed the first statement actually meant "shipping enabled repository metadata" so we don't show it by default without some other important step.
(The following statement is my interpretation, not the official position of the Council): I think that what this means is that they did not want us shipping /etc/yum.repos.d/google-chrome.repo (enabled *or* disabled), but that it's acceptable for GNOME Software to make it easier to acquire that repo file and enable/disable it.
For example, installing a default MIME-type handler for files ending in .repo that allows GNOME Software to be launched and prompt you to load it if you click on such a path in a web browser. I think that would be in line with both statements.
The latter statement led to some of the disabled repo work that Richard did, IIRC. It leaves a lot open to interpretation.
Right, as a simple proposal, would it be acceptable for a package to install something like this into /etc/yum.repos.d:
[google-chrome] name=google-chrome baseurl=http://dl.google.com/linux/chrome/rpm/stable/x86_64 enabled=0 gpgcheck=1 repo_gpgcheck=1 enabled_metadata=1 gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub
So the only time we'd access that repo is with PackageKit when searching with gnome-software, and we'd only prompt to enable the repo if it matched a search keyword like "chrome", and then did that with a big dialog like the mockups warning about the perils and morality of using nonfree software. Using dnf or yum it would be completely invisible due to the enabled=0 line. This was basically my proposal here: http://blogs.gnome.org/hughsie/2015/01/09/finding-hidden-applications-with-g... which didn't seem too controversial at the time.
I imagined that we'd ship a fedora-repos-extra package which we could pull onto just the workstation product using comps, but I'm open for ideas.
I'd say that this is probably directly against the intent of the first statement above, but it may be worth bringing that to the new Council directly. It may have a different result this time around.
On 26 February 2015 at 15:30, Stephen Gallagher sgallagh@redhat.com wrote:
This may be nitpicking, but what about the cases for things that ARE free and open-source, but may still be illegal in certain jurisdictions? (Such as patent-encumbered codecs).
I'm treating that as non-free and possibly patented. In my head I couldn't call something "free and open source" if it's got patent concerns that stop you using it.
For example, installing a default MIME-type handler for files ending in .repo that allows GNOME Software to be launched and prompt you to load it if you click on such a path in a web browser. I think that would be in line with both statements.
I don't actually think that buys us anything in terms of usability. You might as well just go to the website and download the foo-release.rpm file, which is even better as it'll install the GPG key too.
It also doesn't fix the issue that when you type "steam" into gnome-software, nothing comes up. That's what we have to fix.
Richard
On Thu, 2015-02-26 at 16:14 +0000, Richard Hughes wrote:
On 26 February 2015 at 15:30, Stephen Gallagher <sgallagh@redhat.com
wrote: This may be nitpicking, but what about the cases for things that ARE free and open-source, but may still be illegal in certain jurisdictions? (Such as patent-encumbered codecs).
I'm treating that as non-free and possibly patented. In my head I couldn't call something "free and open source" if it's got patent concerns that stop you using it.
For example, installing a default MIME-type handler for files ending in .repo that allows GNOME Software to be launched and prompt you to load it if you click on such a path in a web browser. I think that would be in line with both statements.
I don't actually think that buys us anything in terms of usability. You might as well just go to the website and download the foo- release.rpm file, which is even better as it'll install the GPG key too.
It also doesn't fix the issue that when you type "steam" into gnome- software, nothing comes up. That's what we have to fix.
To be clear, I wasn't intending to state that this was a good solution to the problem, merely using it as an example to represent what I think is the intent of the Board statement.
As I said, I think it's probably worth reopening the conversation with the Council.
On Thu, 2015-02-26 at 10:30 -0500, Stephen Gallagher wrote:
(The following statement is my interpretation, not the official position of the Council): I think that what this means is that they did not want us shipping /etc/yum.repos.d/google-chrome.repo (enabled *or* disabled), but that it's acceptable for GNOME Software to make it easier to acquire that repo file and enable/disable it.
The council hasn't said anything yet, since we haven't asked them.
We're not looking for interpretations of what the old board said a year ago.
For example, installing a default MIME-type handler for files ending in .repo that allows GNOME Software to be launched and prompt you to load it if you click on such a path in a web browser. I think that would be in line with both statements.
And we're also not looking for technical workarounds that don't solve the user experience problem.
We really want to make it possible to have search in the application installer tell you how to get the things you are searching for, with appropriate advice on why you may not want to after all. So, we need to convince the council to take a different position than the board has in the past.
On Thu, Feb 26, 2015 at 4:58 PM, Richard Hughes hughsient@gmail.com wrote:
[google-chrome] name=google-chrome baseurl=http://dl.google.com/linux/chrome/rpm/stable/x86_64 enabled=0 gpgcheck=1 repo_gpgcheck=1 enabled_metadata=1 gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub
That's metadata for a repo that ships non-free software (regardless if it's enabled=0 or enabled=1). So to my understanding this is not acceptable with the current policy.
On Thu, Feb 26, 2015 at 09:35:17AM -0500, Josh Boyer wrote:
On Thu, Feb 26, 2015 at 8:56 AM, Paul W. Frields stickster@gmail.com wrote:
I wanted to resurface the third party repository topic before we get to next week's meeting. Currently we have the following page drafted that discusses the new disabled repo feature currently in Fedora 22 Workstation:
https://fedoraproject.org/wiki/Workstation/3rdPartyApps
Currently there's a policy from the Council (nee Board) on third party repos here:
https://fedoraproject.org/wiki/Third_Party_Repository_Policy
Actually, that policy was written by FESCo. As noted on the bottom of the page, it's a FESCo policy which means changes likely need to go through them.
Right, but specifically there's this section:
"Repositories that contain non-free software are not allowed in any form as they are contrary to the aims of Fedora. If a product should want to make these repositories discoverable it would require a change in policy from the Fedora Board. Please be sure that FESCo is included on any such request to the Board."
That clearly states the request should go to the Board/Council. Yay confusion!
This policy doesn't address one of the problems I believe we're trying to solve in software -- making developer access to non-libre (but legally OK) tools on Fedora less convoluted and burdensome.
So there's not just the question of implementation and curation, but also getting a policy change approved by the Council.
For clarification the Board did review the FESCo policy at this meeting:
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-01-23/fedora_board.20...
The two key points here are:
"The board believes that shipping repository metadata that points at non-free software is incompatible with Fedora's foundations"
and
"The board believes that reducing technical barriers to explicit user choice to install third-party software (non-free or otherwise) is compatible with Fedora's foundations."
The latter statement led to some of the disabled repo work that Richard did, IIRC. It leaves a lot open to interpretation.
It certainly does. That's why I think we need a clear commitment to OK the disabled repo feature. That makes it possible to ship metadata, but puts the onus of choice on the user, and allows us to clearly state Fedora isn't responsible for or supportive of that content.
Josh The situation is that there are several Fedora Remixes that add the very repositories and extra software that is not integrated within a Fedora distribution.
Without those available remixes, it is truly unlikely that Fedora would continue to have the following it now enjoys. Regards Leslie Mr. Leslie Satenstein Montréal Québec, Canada
From: Josh Boyer jwboyer@fedoraproject.org To: Discussions about development for the Fedora desktop desktop@lists.fedoraproject.org Sent: Thursday, February 26, 2015 9:35 AM Subject: Re: Third party repos
On Thu, Feb 26, 2015 at 8:56 AM, Paul W. Frields stickster@gmail.com wrote:
I wanted to resurface the third party repository topic before we get to next week's meeting. Currently we have the following page drafted that discusses the new disabled repo feature currently in Fedora 22 Workstation:
https://fedoraproject.org/wiki/Workstation/3rdPartyApps
Currently there's a policy from the Council (nee Board) on third party repos here:
https://fedoraproject.org/wiki/Third_Party_Repository_Policy
Actually, that policy was written by FESCo. As noted on the bottom of the page, it's a FESCo policy which means changes likely need to go through them.
This policy doesn't address one of the problems I believe we're trying to solve in software -- making developer access to non-libre (but legally OK) tools on Fedora less convoluted and burdensome.
So there's not just the question of implementation and curation, but also getting a policy change approved by the Council.
For clarification the Board did review the FESCo policy at this meeting:
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-01-23/fedora_board.20...
The two key points here are:
"The board believes that shipping repository metadata that points at non-free software is incompatible with Fedora's foundations"
and
"The board believes that reducing technical barriers to explicit user choice to install third-party software (non-free or otherwise) is compatible with Fedora's foundations."
The latter statement led to some of the disabled repo work that Richard did, IIRC. It leaves a lot open to interpretation.
josh
On Sat, Feb 28, 2015 at 5:55 PM, Leslie S Satenstein lsatenstein@yahoo.com wrote:
Josh
The situation is that there are several Fedora Remixes that add the very repositories and extra software that is not integrated within a Fedora distribution.
Without those available remixes, it is truly unlikely that Fedora would continue to have the following it now enjoys.
Regards
Leslie Mr. Leslie Satenstein Montréal Québec, Canada
As a provider of one such remix, I must say it's a labor of love. A viable supported RPM for Fedora of RStudio Server would render my remix irrelevant.
Honestly, I think my days as a full-on remix are numbered. I can ship a small set of scripts to install what's on my remix to a Fedora Workstation and then distribute everything else as Docker images.
On Feb 26, 2015 6:57 AM, "Paul W. Frields" stickster@gmail.com wrote:
I wanted to resurface the third party repository topic before we get to next week's meeting. Currently we have the following page drafted that discusses the new disabled repo feature currently in Fedora 22 Workstation:
https://fedoraproject.org/wiki/Workstation/3rdPartyApps
Currently there's a policy from the Council (nee Board) on third party repos here:
https://fedoraproject.org/wiki/Third_Party_Repository_Policy
This policy doesn't address one of the problems I believe we're trying to solve in software -- making developer access to non-libre (but legally OK) tools on Fedora less convoluted and burdensome.
So there's not just the question of implementation and curation, but also getting a policy change approved by the Council.
-- 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 --
This would make more sense to me as a Change proposal, with all the process and publicity that comes with that. A change in Fedora like this is much greater than the actual implementation details; treating it like a minor gnome-software feature add isn't representative of the impact on the project.
--Pete
On Thu, Feb 26, 2015 at 08:37:55AM -0700, Pete Travis wrote:
On Feb 26, 2015 6:57 AM, "Paul W. Frields" stickster@gmail.com wrote:
I wanted to resurface the third party repository topic before we get to next week's meeting. Currently we have the following page drafted that discusses the new disabled repo feature currently in Fedora 22 Workstation:
https://fedoraproject.org/wiki/Workstation/3rdPartyApps
Currently there's a policy from the Council (nee Board) on third party repos here:
https://fedoraproject.org/wiki/Third_Party_Repository_Policy
This policy doesn't address one of the problems I believe we're trying to solve in software -- making developer access to non-libre (but legally OK) tools on Fedora less convoluted and burdensome.
So there's not just the question of implementation and curation, but also getting a policy change approved by the Council.
This would make more sense to me as a Change proposal, with all the process and publicity that comes with that. A change in Fedora like this is much greater than the actual implementation details; treating it like a minor gnome-software feature add isn't representative of the impact on the project.
Except the Change process is focused on sorting out changes that make more than the owner do work to integrate, vs. those that don't. I think calling this a Change actually demote this to a purely technical decision, and I don't want to see it treated that way. So I think your suggestion achieves the opposite of what you intend.
On Thu, 2015-02-26 at 15:58 -0500, Paul W. Frields wrote:
On Thu, Feb 26, 2015 at 08:37:55AM -0700, Pete Travis wrote:
On Feb 26, 2015 6:57 AM, "Paul W. Frields" stickster@gmail.com wrote:
I wanted to resurface the third party repository topic before we get to next week's meeting. Currently we have the following page drafted that discusses the new disabled repo feature currently in Fedora 22 Workstation:
https://fedoraproject.org/wiki/Workstation/3rdPartyApps
Currently there's a policy from the Council (nee Board) on third party repos here:
https://fedoraproject.org/wiki/Third_Party_Repository_Policy
This policy doesn't address one of the problems I believe we're trying to solve in software -- making developer access to non- libre (but legally OK) tools on Fedora less convoluted and burdensome.
So there's not just the question of implementation and curation, but also getting a policy change approved by the Council.
This would make more sense to me as a Change proposal, with all the process and publicity that comes with that. A change in Fedora like this is much greater than the actual implementation details; treating it like a minor gnome-software feature add isn't representative of the impact on the project.
Except the Change process is focused on sorting out changes that make more than the owner do work to integrate, vs. those that don't. I think calling this a Change actually demote this to a purely technical decision, and I don't want to see it treated that way. So I think your suggestion achieves the opposite of what you intend.
Paul, you're describing a System-Wide Change there. What Pete is describing is a Self-Contained Change, and this is exactly what those sort of Changes are meant to account for.
On Feb 26, 2015 1:59 PM, "Paul W. Frields" stickster@gmail.com wrote:
On Thu, Feb 26, 2015 at 08:37:55AM -0700, Pete Travis wrote:
On Feb 26, 2015 6:57 AM, "Paul W. Frields" stickster@gmail.com wrote:
I wanted to resurface the third party repository topic before we get to next week's meeting. Currently we have the following page drafted that discusses the new disabled repo feature currently in Fedora 22 Workstation:
https://fedoraproject.org/wiki/Workstation/3rdPartyApps
Currently there's a policy from the Council (nee Board) on third party repos here:
https://fedoraproject.org/wiki/Third_Party_Repository_Policy
This policy doesn't address one of the problems I believe we're trying to solve in software -- making developer access to non-libre (but legally OK) tools on Fedora less convoluted and burdensome.
So there's not just the question of implementation and curation, but also getting a policy change approved by the Council.
This would make more sense to me as a Change proposal, with all the
process
and publicity that comes with that. A change in Fedora like this is
much
greater than the actual implementation details; treating it like a minor gnome-software feature add isn't representative of the impact on the project.
Except the Change process is focused on sorting out changes that make more than the owner do work to integrate, vs. those that don't. I think calling this a Change actually demote this to a purely technical decision, and I don't want to see it treated that way. So I think your suggestion achieves the opposite of what you intend.
-- Paul W. Frields
"Demotion" sounds like we might be on the same page about impact, at least :) The Change process is technically focused, but it's still *the* process for major feature changes to get community review. These changes are almost entirely technical in nature, but FYI-type changes for marketing and documentation purposes happen too. Participation in the process would still allow for policy review, community feedback, coordination with other groups, and maybe even stretch the Change process itself to accommodate less technical proposals.
--Pete
On Thu, Feb 26, 2015 at 02:17:06PM -0700, Pete Travis wrote:
On Feb 26, 2015 1:59 PM, "Paul W. Frields" stickster@gmail.com wrote:
On Thu, Feb 26, 2015 at 08:37:55AM -0700, Pete Travis wrote:
On Feb 26, 2015 6:57 AM, "Paul W. Frields" stickster@gmail.com wrote:
I wanted to resurface the third party repository topic before we get to next week's meeting. Currently we have the following page drafted that discusses the new disabled repo feature currently in Fedora 22 Workstation:
https://fedoraproject.org/wiki/Workstation/3rdPartyApps
Currently there's a policy from the Council (nee Board) on third party repos here:
https://fedoraproject.org/wiki/Third_Party_Repository_Policy
This policy doesn't address one of the problems I believe we're trying to solve in software -- making developer access to non-libre (but legally OK) tools on Fedora less convoluted and burdensome.
So there's not just the question of implementation and curation, but also getting a policy change approved by the Council.
This would make more sense to me as a Change proposal, with all the
process
and publicity that comes with that. A change in Fedora like this is
much
greater than the actual implementation details; treating it like a minor gnome-software feature add isn't representative of the impact on the project.
Except the Change process is focused on sorting out changes that make more than the owner do work to integrate, vs. those that don't. I think calling this a Change actually demote this to a purely technical decision, and I don't want to see it treated that way. So I think your suggestion achieves the opposite of what you intend.
"Demotion" sounds like we might be on the same page about impact, at least :) The Change process is technically focused, but it's still *the* process for major feature changes to get community review. These changes are almost entirely technical in nature, but FYI-type changes for marketing and documentation purposes happen too. Participation in the process would still allow for policy review, community feedback, coordination with other groups, and maybe even stretch the Change process itself to accommodate less technical proposals.
That's completely correct, but without policy the technical feature isn't going to have any impact AFAICT.
On Thu, Feb 26, 2015 at 04:52:03PM -0500, Paul W. Frields wrote:
On Thu, Feb 26, 2015 at 02:17:06PM -0700, Pete Travis wrote:
On Feb 26, 2015 1:59 PM, "Paul W. Frields" stickster@gmail.com wrote:
On Thu, Feb 26, 2015 at 08:37:55AM -0700, Pete Travis wrote:
On Feb 26, 2015 6:57 AM, "Paul W. Frields" stickster@gmail.com wrote:
I wanted to resurface the third party repository topic before we get to next week's meeting. Currently we have the following page drafted that discusses the new disabled repo feature currently in Fedora 22 Workstation:
https://fedoraproject.org/wiki/Workstation/3rdPartyApps
Currently there's a policy from the Council (nee Board) on third party repos here:
https://fedoraproject.org/wiki/Third_Party_Repository_Policy
This policy doesn't address one of the problems I believe we're trying to solve in software -- making developer access to non-libre (but legally OK) tools on Fedora less convoluted and burdensome.
So there's not just the question of implementation and curation, but also getting a policy change approved by the Council.
This would make more sense to me as a Change proposal, with all the
process
and publicity that comes with that. A change in Fedora like this is
much
greater than the actual implementation details; treating it like a minor gnome-software feature add isn't representative of the impact on the project.
Except the Change process is focused on sorting out changes that make more than the owner do work to integrate, vs. those that don't. I think calling this a Change actually demote this to a purely technical decision, and I don't want to see it treated that way. So I think your suggestion achieves the opposite of what you intend.
"Demotion" sounds like we might be on the same page about impact, at least :) The Change process is technically focused, but it's still *the* process for major feature changes to get community review. These changes are almost entirely technical in nature, but FYI-type changes for marketing and documentation purposes happen too. Participation in the process would still allow for policy review, community feedback, coordination with other groups, and maybe even stretch the Change process itself to accommodate less technical proposals.
That's completely correct, but without policy the technical feature isn't going to have any impact AFAICT.
This was a bit perfunctory, and I should have said I'm not violently opposed to filing a late Change. I can see how the Change is still helpful as part of a larger effort.
----- Original Message -----
On Thu, Feb 26, 2015 at 04:52:03PM -0500, Paul W. Frields wrote:
On Thu, Feb 26, 2015 at 02:17:06PM -0700, Pete Travis wrote:
On Feb 26, 2015 1:59 PM, "Paul W. Frields" stickster@gmail.com wrote:
On Thu, Feb 26, 2015 at 08:37:55AM -0700, Pete Travis wrote:
On Feb 26, 2015 6:57 AM, "Paul W. Frields" stickster@gmail.com wrote:
I wanted to resurface the third party repository topic before we get to next week's meeting. Currently we have the following page drafted that discusses the new disabled repo feature currently in Fedora 22 Workstation:
https://fedoraproject.org/wiki/Workstation/3rdPartyApps
Currently there's a policy from the Council (nee Board) on third party repos here:
https://fedoraproject.org/wiki/Third_Party_Repository_Policy
This policy doesn't address one of the problems I believe we're trying to solve in software -- making developer access to non-libre (but legally OK) tools on Fedora less convoluted and burdensome.
So there's not just the question of implementation and curation, but also getting a policy change approved by the Council.
This would make more sense to me as a Change proposal, with all the
process
and publicity that comes with that. A change in Fedora like this is
much
greater than the actual implementation details; treating it like a minor gnome-software feature add isn't representative of the impact on the project.
Except the Change process is focused on sorting out changes that make more than the owner do work to integrate, vs. those that don't. I think calling this a Change actually demote this to a purely technical decision, and I don't want to see it treated that way. So I think your suggestion achieves the opposite of what you intend.
"Demotion" sounds like we might be on the same page about impact, at least :) The Change process is technically focused, but it's still *the* process for major feature changes to get community review. These changes are almost entirely technical in nature, but FYI-type changes for marketing and documentation purposes happen too. Participation in the process would still allow for policy review, community feedback, coordination with other groups, and maybe even stretch the Change process itself to accommodate less technical proposals.
That's completely correct, but without policy the technical feature isn't going to have any impact AFAICT.
This was a bit perfunctory, and I should have said I'm not violently opposed to filing a late Change. I can see how the Change is still helpful as part of a larger effort.
Paul, Change page is definitely just a portion of this larger scale effort but we have also other processes tied to Change page. For example release notes collection (docs guys are doing a great job), we should do more marketing around (especially talking point for Ambassadors) etc.
And to be honest, I'd like to see Change pages more as coordination point than strictly technical description. It's not yet there but with WGs and products gaining more independence, it means not every single page would have to go through FESCo and be technical.
I'm a bit out of topic now, but please, try to work on Change page and let me know once it's ready and I'll do the rest. If you don't mind spending some time on it, to make sure it's open to broader community. The announcements are probably the best thing we have ever did in Fedora for communication!
Jaroslav
-- 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 -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Fri, Feb 27, 2015 at 10:52:26AM -0500, Jaroslav Reznik wrote:
----- Original Message -----
On Thu, Feb 26, 2015 at 04:52:03PM -0500, Paul W. Frields wrote: This was a bit perfunctory, and I should have said I'm not violently opposed to filing a late Change. I can see how the Change is still helpful as part of a larger effort.
Paul, Change page is definitely just a portion of this larger scale effort but we have also other processes tied to Change page. For example release notes collection (docs guys are doing a great job), we should do more marketing around (especially talking point for Ambassadors) etc.
And to be honest, I'd like to see Change pages more as coordination point than strictly technical description. It's not yet there but with WGs and products gaining more independence, it means not every single page would have to go through FESCo and be technical.
I'm a bit out of topic now, but please, try to work on Change page and let me know once it's ready and I'll do the rest. If you don't mind spending some time on it, to make sure it's open to broader community. The announcements are probably the best thing we have ever did in Fedora for communication!
I put this page together:
https://fedoraproject.org/wiki/Changes/DisabledRepoSupport
I'd appreciate some review/edit by folks to make sure it's complete and correct.
Is there any move to allow GIT repositories for the future? RPMs on GIT allow a person to choose a less than most recent version (if there are multiple versions)?
Leslie
From: Pete Travis lists@petetravis.com To: Discussions about development for the Fedora desktop desktop@lists.fedoraproject.org Sent: Thursday, February 26, 2015 10:37 AM Subject: Re: Third party repos
On Feb 26, 2015 6:57 AM, "Paul W. Frields" stickster@gmail.com wrote:
I wanted to resurface the third party repository topic before we get to next week's meeting. Currently we have the following page drafted that discusses the new disabled repo feature currently in Fedora 22 Workstation:
https://fedoraproject.org/wiki/Workstation/3rdPartyApps
Currently there's a policy from the Council (nee Board) on third party repos here:
https://fedoraproject.org/wiki/Third_Party_Repository_Policy
This policy doesn't address one of the problems I believe we're trying to solve in software -- making developer access to non-libre (but legally OK) tools on Fedora less convoluted and burdensome.
So there's not just the question of implementation and curation, but also getting a policy change approved by the Council.
-- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/%C2%A0 - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com --
This would make more sense to me as a Change proposal, with all the process and publicity that comes with that. A change in Fedora like this is much greater than the actual implementation details; treating it like a minor gnome-software feature add isn't representative of the impact on the project.--Pete
On Fri, 2015-02-27 at 14:01 +0000, Leslie S Satenstein wrote:
Is there any move to allow GIT repositories for the future? RPMs on GIT allow a person to choose a less than most recent version (if there are multiple versions)?
See https://wiki.gnome.org/Projects/SandboxedApps for our current efforts. It is based on ostree, not git, but the same idea.
desktop@lists.stg.fedoraproject.org
-
Jaroslav Reznik -
Josh Boyer -
Leslie S Satenstein -
M. Edward (Ed) Borasky -
Matthias Clasen -
Nikos Roussos -
Paul W. Frields -
Pete Travis -
Richard Hughes -
Stephen Gallagher