Am Mittwoch, den 24.02.2010, 23:38 -0600 schrieb Matt Domsch:
These questions were originally posted to the Spins SIG a couple weeks ago. At the following SIG meeting, members suggested that these questions would be better posed to the individual spin owners, or teams that are working on the spins, in addition to the SIG.
The Spins SIG consists of the spin owners and we already discussed this in the Spins SIG meetings of the last two weeks. I think most of the spin owners already outlined their point of view in the meetings, some also relied to your mail.
In addition to this I already wrote something on the board's mailing list last week. Nevertheless I will try to answer the question once again, this time a little more detailed.
[snipped]
Board-level Question: Can Spins/SIGS or Fedora remixes define their own target audience?
Background
[snipped]
Possible Solutions
- Board sets target audience broadly, spins tailor to a subset
thereof.
- Board sets target audience broadly, spins tailor to either a
subset thereof, or to additional audiences outside that scope so long as there are no conflicts.
- Board does not set target audience, leaves it to each Spin to
set their specific target audience. 1. requires spins to be much more than consumers of Fedora content. 2. audience of some spins may overlap. That's OK. 3. audience of some spins may technically conflict. How to resolve conflicts? Spins -> FESCo -> Board.
As members contributing to Spins, how do you view the above, and how would you like to see Spins interact with the larger Project with respect to defining target audiences?
I don't really understand all this discussion about a target audience or potential problems. The definitions are on a completely different level.
The board is the political body of the Fedora Project. Thus their definition of a target audience is a political decision. The Spins SIG on the other hand works on technical implementations, this means their definition of target audience is more technical.
So far, the board has defined a "working" target audience. Early adopters who always want the latest and greatest technology and who are not afraid of changes. Active users who are interested in development. People who don't mind searching the net for a solution to a technical problems. People who like to contribute.
I think all spin maintainers can subscribe to this point of view, otherwise we would not contribute to Fedora. Same goes for the users: They may want to use this or that spin, but first off all they want to use Fedora as such. If they don't like Fedora, they will not use our KDE Spin but another KDE-based distro.
Given the boards definition remains political, I have no problems with ether one of the possible answers. The technical implementation of the spins is automatically a subset of the board's definition. But if the boards starts defining technical goals such as "lets prefer GNOME users because Red Hat contributes to GNOME a lot and the Desktop Spin is our flagship product" we will run into trouble. Then the spins must be able to define their own target audience, even outside the audience defined by the board.
Let's face it: Although we already have a target audience, we have case 3.3: Spins technically do conflict. I will explain this below. What I want to say is that IMO the answers lack another possibility: The board sets a target audience but still there are conflicts.
So before I can decide on one of the possible solutions, I'd like to hear a definition of "target audience". I know this is a bit of a chicken and egg problem, but I think at the current state the board should be able to at least say on what level will this audience be defined. Political and theoretical or technical and applied?
Board-level Question: Can Spins/SIGS or Fedora remixes change the code enough to meet their goals?
Background
[snipped]
Given the present situation:
- Has any Spin found the present situation unduly restrictive?
- If so, how specifically?
A spin is defined as installable Live-CD. This means it must ship anaconda and firstboot. firstboot requires system-config-keyboard requires metacity requires GConf2 and tons of other GNOME stuff. There are other dependency chains as well (e.g. notification-daemon), but this is the worst one.
- Has any Spin found they cannot address their target audience properly?
- If so, in what way?
Xfce users want Xfce, LXDE users want LXDE. Both want a lightweight system, otherwise they would likely be using GNOME. But what they get is more or less GNOME. Without all the GNOME packages we would have significantly more space on the media.
2. Is the root problem that all packages must be in the official repositories?
No, the root of the problems are the GNOME maintainers refuse to consider other desktops and their users.
I'm convinced that we can address these issues on a technical level in one repository. OpenSUSE already does a great job here: They have different branding packages wich contain the SUSE specific changes. This is similar to what we do with fedora-logos, but it's a more complete approach.
For example, there is a package called gconf2-branding-openSUSE which contains all the modified GConf schemas. By replacing this package, you can change the complete settings of the GNOME desktop. This would be useful for us too, think of a GNOME based Fedora Mini Spin for Netbooks, that wants to use another other panel layout. We cannot do this in Fedora ATM, but it is possible. For more info about OpenSUSE's branding, see http://en.opensuse.org/Packaging/Branding
We must not break up into different projects like Ubuntu with Kubuntu, Xubuntu and Lubuntu because this results in a duplication of work and incompatible packages. Instead everything should happen under the umbrella of the Fedora Project. We need to work out the problems on a technical level instead of forking. I'm sure we can do it if all desktop SIGs cooperate.
- How are you addressing this today?
We cannot. Currently *all* spins must ship metacity and all it's dependencies.
- How would you like to address this in the future?
With more fine grained packaging. Introduce a virtual provides for window-managers instead of hardcoding one. system-config-keyboard maintainer refused to do this in the past, but now that we have the critical paths set for each desktop, I don't see why the virtual provides would introduce problems.
- Are the resources you would need readily available?
- If not, what would you need to properly address this?
* Webspace for direct downloads of the spins. not only torrents. * A way to count these downloads. * Officially labeled live media of the spins for promotion. In EMEA we currently have GNOME, not even KDE.
- Is the transition from "Spin" to "Remix" onerous?
- If so, what can be done to make it less so?
I don't think the transition from a spin to a remix is onerous, but from a remix to a spin it's problematic because one has to follow all the Fedora guidelines and restrictions. This is why I think we need the remixes and we cannot really forbid them.
However I think we should not advocate remixes, at least not if they are questionable. I never understood why the board approved the Fedora Russia Remix and allowed it to use the Fedora trademark. It contains non-free software or codecs and thus violates our very basic foundations.
As long as a spin follows the Fedora foundations, I have no problems with it. Maybe it's necessary because some things are technically not possible in Fedora ATM. This is one more reason why I think we need to work on solving technical issues with the spins in Fedora: The more free the spin maintainers are, the less reason they have to do a remix instead of a proper spin.
Regards, Christoph
Christoph Wickert (christoph.wickert@googlemail.com) said:
[snipped]
Given the present situation:
- Has any Spin found the present situation unduly restrictive?
- If so, how specifically?
A spin is defined as installable Live-CD. This means it must ship anaconda and firstboot. firstboot requires system-config-keyboard requires metacity requires GConf2 and tons of other GNOME stuff. There are other dependency chains as well (e.g. notification-daemon), but this is the worst one.
I'm not sure what your objection is here. Are you objecting to the fact that it must be a LiveCD, the fact that the LiveCD installer uses anaconda/firstboot, or the dependencies of anaconda/firstboot?
The first is a policy issue that could be redressed. The second is unlikely to change (and would imply you'd be signing up to write your own if you didn't want to use anaconda/firstboot, which I can't imagine is what you want), and the third probably requires patch submissions.
(Note: due to the requirements for a window manager at installation time, anaconda may very well require metacity in the near future.)
For example, there is a package called gconf2-branding-openSUSE which contains all the modified GConf schemas. By replacing this package, you can change the complete settings of the GNOME desktop. This would be useful for us too, think of a GNOME based Fedora Mini Spin for Netbooks, that wants to use another other panel layout. We cannot do this in Fedora ATM, but it is possible.
What prevents you doing in in Fedora? Have you submitted a package review, or an example spec?
Bill
On 02/25/2010 04:50 PM, Bill Nottingham wrote:
Christoph Wickert (christoph.wickert@googlemail.com) said:
[snipped]
Given the present situation:
- Has any Spin found the present situation unduly restrictive?
- If so, how specifically?
A spin is defined as installable Live-CD. This means it must ship anaconda and firstboot. firstboot requires system-config-keyboard requires metacity requires GConf2 and tons of other GNOME stuff. There are other dependency chains as well (e.g. notification-daemon), but this is the worst one.
I'm not sure what your objection is here. Are you objecting to the fact that it must be a LiveCD, the fact that the LiveCD installer uses anaconda/firstboot, or the dependencies of anaconda/firstboot?
Or maybe just the requirement that the LiveCD must be installable?
-- Jeroen
Am Donnerstag, den 25.02.2010, 10:50 -0500 schrieb Bill Nottingham:
Christoph Wickert (christoph.wickert@googlemail.com) said:
[snipped]
Given the present situation:
- Has any Spin found the present situation unduly restrictive?
- If so, how specifically?
A spin is defined as installable Live-CD. This means it must ship anaconda and firstboot. firstboot requires system-config-keyboard requires metacity requires GConf2 and tons of other GNOME stuff. There are other dependency chains as well (e.g. notification-daemon), but this is the worst one.
I'm not sure what your objection is here. Are you objecting to the fact that it must be a LiveCD, the fact that the LiveCD installer uses anaconda/firstboot, or the dependencies of anaconda/firstboot?
Sorry if i was unclear: I am objecting to the dependencies of system-config-keyboard. AFAICS it is not run embedded in firstboot and there is no need for a window-manager at that point. authconfig-gtk on the other hand requires one because it starts popup windows, but these work fine with whatever window manager is available. You can see this in the spins already.
The first is a policy issue that could be redressed. The second is unlikely to change (and would imply you'd be signing up to write your own if you didn't want to use anaconda/firstboot, which I can't imagine is what you want), and the third probably requires patch submissions.
(Note: due to the requirements for a window manager at installation time, anaconda may very well require metacity in the near future.)
Why not a virtual provide and let the spin maintainers and users decide? In F12 we changed anaconda to use any display manager that has a virtual provides for "service(graphical-login)" instead of hardcoding a list of display managers. We should do the same for window manager. Introducing a new hardcoded requirement for metacity with all it's overhead is a step backwards and a punch in the face of all people who are not using GNOME.
For example, there is a package called gconf2-branding-openSUSE which contains all the modified GConf schemas. By replacing this package, you can change the complete settings of the GNOME desktop. This would be useful for us too, think of a GNOME based Fedora Mini Spin for Netbooks, that wants to use another other panel layout. We cannot do this in Fedora ATM, but it is possible.
What prevents you doing in in Fedora? Have you submitted a package review, or an example spec?
I cannot submit a package review because the files included in the package conflict with the current packages. Before we can change something we need a packaging policy and in the past the GNOME maintainers have been unwilling to support these kind of changes.
Bill
Regards, Christoph
Christoph Wickert (christoph.wickert@googlemail.com) said:
The first is a policy issue that could be redressed. The second is unlikely to change (and would imply you'd be signing up to write your own if you didn't want to use anaconda/firstboot, which I can't imagine is what you want), and the third probably requires patch submissions.
(Note: due to the requirements for a window manager at installation time, anaconda may very well require metacity in the near future.)
Why not a virtual provide and let the spin maintainers and users decide? In F12 we changed anaconda to use any display manager that has a virtual provides for "service(graphical-login)" instead of hardcoding a list of display managers. We should do the same for window manager.
anaconda, firstboot, and whatever would need a mechanism to start random-window-manager of the day and adjust the configuration as needed. If that's important to people, they should submit patches.
There's also have the requirement that the window manager used support certain EWMH properties, although I suppose if you try and compose with twm you get all the pieces.
What prevents you doing in in Fedora? Have you submitted a package review, or an example spec?
I cannot submit a package review because the files included in the package conflict with the current packages.
How so? Just package up some settings in the /etc/gconf.xml.system directory.
Bill
Am Donnerstag, den 25.02.2010, 18:00 -0500 schrieb Bill Nottingham:
Christoph Wickert (christoph.wickert@googlemail.com) said:
The first is a policy issue that could be redressed. The second is unlikely to change (and would imply you'd be signing up to write your own if you didn't want to use anaconda/firstboot, which I can't imagine is what you want), and the third probably requires patch submissions.
(Note: due to the requirements for a window manager at installation time, anaconda may very well require metacity in the near future.)
Why not a virtual provide and let the spin maintainers and users decide? In F12 we changed anaconda to use any display manager that has a virtual provides for "service(graphical-login)" instead of hardcoding a list of display managers. We should do the same for window manager.
anaconda, firstboot, and whatever would need a mechanism to start random-window-manager of the day and adjust the configuration as needed. If that's important to people, they should submit patches.
It is not random but defined by the user or maintainer. All the spins except the Desktop Spin already (have to) configure /etc/sysconfig/desktop.
There's also have the requirement that the window manager used support certain EWMH properties, although I suppose if you try and compose with twm you get all the pieces.
I guess all WMs in Fedora should support these properties.
What prevents you doing in in Fedora? Have you submitted a package review, or an example spec?
I cannot submit a package review because the files included in the package conflict with the current packages.
How so? Just package up some settings in the /etc/gconf.xml.system directory.
First of all I'm not interested in GNOME any longer, so there is no reason for me to submit such a package. I just named it as an example for smarter packaging.
Second: If the files do not confligt, how to prevent gnome-panel from reading other /etc/gconf/schemas/panel-* files? How to resolve conflicting settings?
Bill
Regards, Christoph
Christoph Wickert (christoph.wickert@googlemail.com) said:
The first is a policy issue that could be redressed. The second is unlikely to change (and would imply you'd be signing up to write your own if you didn't want to use anaconda/firstboot, which I can't imagine is what you want), and the third probably requires patch submissions.
(Note: due to the requirements for a window manager at installation time, anaconda may very well require metacity in the near future.)
Why not a virtual provide and let the spin maintainers and users decide? In F12 we changed anaconda to use any display manager that has a virtual provides for "service(graphical-login)" instead of hardcoding a list of display managers. We should do the same for window manager.
anaconda, firstboot, and whatever would need a mechanism to start random-window-manager of the day and adjust the configuration as needed. If that's important to people, they should submit patches.
It is not random but defined by the user or maintainer. All the spins except the Desktop Spin already (have to) configure /etc/sysconfig/desktop.
Getting arbitrary things into the anaconda image isn't trivial - it involves explicitly listing packages and files to use. firstboot's a little better, as it's actually working on an installed system. As I said, if you or others have interest in making this possible, the way to start is with patches or patch proposals. Get all the WMs that people might want for this providing something that can automatically determine the command to run. Make sure that they all do the right thing without needing random arguments passed to them. Then work from there with patches to apps.
What prevents you doing in in Fedora? Have you submitted a package review, or an example spec?
I cannot submit a package review because the files included in the package conflict with the current packages.
How so? Just package up some settings in the /etc/gconf.xml.system directory.
First of all I'm not interested in GNOME any longer, so there is no reason for me to submit such a package. I just named it as an example for smarter packaging.
Second: If the files do not confligt, how to prevent gnome-panel from reading other /etc/gconf/schemas/panel-* files? How to resolve conflicting settings?
It's a heirarchy, it's how gconf works. But, really, when your argument goes:
S: This is a problem!
A: OK, why not work for it?
S: I can't, there are conflicts!
A: No, here's how you can do it.
S: But I'm not interested in doing that anyway.
... ugh. If you've got technical concerns you're willing to solve, I and others can try and point out the best way to solve them. If you're just tossing out complaints with no intention of working towards a solution...
Bill
On Fri, Feb 26, 2010 at 4:41 PM, Bill Nottingham notting@redhat.com wrote:
Christoph Wickert (christoph.wickert@googlemail.com) said:
The first is a policy issue that could be redressed. The second is unlikely to change (and would imply you'd be signing up to write your own if you didn't want to use anaconda/firstboot, which I can't imagine is what you want), and the third probably requires patch submissions.
(Note: due to the requirements for a window manager at installation time, anaconda may very well require metacity in the near future.)
Why not a virtual provide and let the spin maintainers and users decide? In F12 we changed anaconda to use any display manager that has a virtual provides for "service(graphical-login)" instead of hardcoding a list of display managers. We should do the same for window manager.
anaconda, firstboot, and whatever would need a mechanism to start random-window-manager of the day and adjust the configuration as needed. If that's important to people, they should submit patches.
It is not random but defined by the user or maintainer. All the spins except the Desktop Spin already (have to) configure /etc/sysconfig/desktop.
Getting arbitrary things into the anaconda image isn't trivial - it involves explicitly listing packages and files to use. firstboot's a little better, as it's actually working on an installed system. As I said, if you or others have interest in making this possible, the way to start is with patches or patch proposals. Get all the WMs that people might want for this providing something that can automatically determine the command to run. Make sure that they all do the right thing without needing random arguments passed to them. Then work from there with patches to apps.
I would like to see it support at least mutter, not sure that this should be too hard as its based on metacity anyway. For a gnome-shell based gnome or Mobline/Meego it seems a little overkill having metacity and deps just for install.
I'd also like to see the removal of the requirement of perl (via perl scripts in syslinux) as it added about 10% to the F-12 test LiveCDs I did off Moblin. Anaconda uses a single of these scripts and only for the creation of hybrid boot cds (see bugs 544136 and 559644 ), This is also relevant for the Sugar on a Stick spin as well. Its the last dep remaining on perl in both those spins (and I suspect the desktop spins as well).
Peter
I ran into this just this week too. Isohybrid script is pretty small and could be re-written in C by someone who passed C 101 in a day or so I'd think.
-----Original Message----- From: Peter Robinson pbrobinson@gmail.com Date: Tue, 30 Mar 2010 17:08:06 To: The Spin Special Interest Group mailing listspins@lists.fedoraproject.org Subject: Re: [Fedora-spins] Board SWG questions for Spins Owners
On Fri, Feb 26, 2010 at 4:41 PM, Bill Nottingham notting@redhat.com wrote:
Christoph Wickert (christoph.wickert@googlemail.com) said:
The first is a policy issue that could be redressed. The second is unlikely to change (and would imply you'd be signing up to write your own if you didn't want to use anaconda/firstboot, which I can't imagine is what you want), and the third probably requires patch submissions.
(Note: due to the requirements for a window manager at installation time, anaconda may very well require metacity in the near future.)
Why not a virtual provide and let the spin maintainers and users decide? In F12 we changed anaconda to use any display manager that has a virtual provides for "service(graphical-login)" instead of hardcoding a list of display managers. We should do the same for window manager.
anaconda, firstboot, and whatever would need a mechanism to start random-window-manager of the day and adjust the configuration as needed. If that's important to people, they should submit patches.
It is not random but defined by the user or maintainer. All the spins except the Desktop Spin already (have to) configure /etc/sysconfig/desktop.
Getting arbitrary things into the anaconda image isn't trivial - it involves explicitly listing packages and files to use. firstboot's a little better, as it's actually working on an installed system. As I said, if you or others have interest in making this possible, the way to start is with patches or patch proposals. Get all the WMs that people might want for this providing something that can automatically determine the command to run. Make sure that they all do the right thing without needing random arguments passed to them. Then work from there with patches to apps.
I would like to see it support at least mutter, not sure that this should be too hard as its based on metacity anyway. For a gnome-shell based gnome or Mobline/Meego it seems a little overkill having metacity and deps just for install.
I'd also like to see the removal of the requirement of perl (via perl scripts in syslinux) as it added about 10% to the F-12 test LiveCDs I did off Moblin. Anaconda uses a single of these scripts and only for the creation of hybrid boot cds (see bugs 544136 and 559644 ), This is also relevant for the Sugar on a Stick spin as well. Its the last dep remaining on perl in both those spins (and I suspect the desktop spins as well).
Peter _______________________________________________ spins mailing list spins@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/spins
On Tue, Mar 30, 2010 at 16:38:08 +0000, Matt Domsch matt@domsch.com wrote:
I ran into this just this week too. Isohybrid script is pretty small and could be re-written in C by someone who passed C 101 in a day or so I'd think.
Maybe a request should be made to Fedora Engineering Services?
-----Original Message----- From: Peter Robinson pbrobinson@gmail.com Date: Tue, 30 Mar 2010 17:08:06 To: The Spin Special Interest Group mailing listspins@lists.fedoraproject.org Subject: Re: [Fedora-spins] Board SWG questions for Spins Owners
On Fri, Feb 26, 2010 at 4:41 PM, Bill Nottingham notting@redhat.com wrote:
Christoph Wickert (christoph.wickert@googlemail.com) said:
The first is a policy issue that could be redressed. The second is unlikely to change (and would imply you'd be signing up to write your own if you didn't want to use anaconda/firstboot, which I can't imagine is what you want), and the third probably requires patch submissions.
(Note: due to the requirements for a window manager at installation time, anaconda may very well require metacity in the near future.)
Why not a virtual provide and let the spin maintainers and users decide? In F12 we changed anaconda to use any display manager that has a virtual provides for "service(graphical-login)" instead of hardcoding a list of display managers. We should do the same for window manager.
anaconda, firstboot, and whatever would need a mechanism to start random-window-manager of the day and adjust the configuration as needed. If that's important to people, they should submit patches.
It is not random but defined by the user or maintainer. All the spins except the Desktop Spin already (have to) configure /etc/sysconfig/desktop.
Getting arbitrary things into the anaconda image isn't trivial - it involves explicitly listing packages and files to use. firstboot's a little better, as it's actually working on an installed system. As I said, if you or others have interest in making this possible, the way to start is with patches or patch proposals. Get all the WMs that people might want for this providing something that can automatically determine the command to run. Make sure that they all do the right thing without needing random arguments passed to them. Then work from there with patches to apps.
I would like to see it support at least mutter, not sure that this should be too hard as its based on metacity anyway. For a gnome-shell based gnome or Mobline/Meego it seems a little overkill having metacity and deps just for install.
I'd also like to see the removal of the requirement of perl (via perl scripts in syslinux) as it added about 10% to the F-12 test LiveCDs I did off Moblin. Anaconda uses a single of these scripts and only for the creation of hybrid boot cds (see bugs 544136 and 559644 ), This is also relevant for the Sugar on a Stick spin as well. Its the last dep remaining on perl in both those spins (and I suspect the desktop spins as well).
Peter _______________________________________________ spins mailing list spins@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/spins _______________________________________________ spins mailing list spins@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/spins
Christoph, thanks for your insighful comments. I've incorporated them into the discussion the SWG is having today.
On Thu, Feb 25, 2010 at 02:25:27PM +0100, Christoph Wickert wrote:
However I think we should not advocate remixes, at least not if they are questionable. I never understood why the board approved the Fedora Russia Remix and allowed it to use the Fedora trademark. It contains non-free software or codecs and thus violates our very basic foundations.
On this point, I think there is confusion.
The Board did not grant a trademark license for a Fedora Russia remix. Remixes are explicitly not granted trademark licenses.
The Board did grant a trademark license for the web site name, russianfedora.ru, as is our practice for community web sites.
The board did grant a trademark license for non-software goods (e.g. T-shirts), however, this does not appear to have been completed by Alexey or anyone else in the Russian Fedora organization.
Thanks, Matt
-
Bill Nottingham -
Bruno Wolff III -
Christoph Wickert -
Jeroen van Meeuwen -
Matt Domsch -
Peter Robinson