Hi,
There is a package (london pictures) under review[1], which I consider to be a corner case wrt. "Code vs. content"[2].
The problem I have with this package providing a precedence of how to circumvent Fedora's regulations/guidelines etc. to use Fedora as means to distribute "mere content".
In other words, I fear this package is a precedence to opens a can of worms for content packages.
What to do about this package and about this issue in general?
My gut feeling is, Fedora should refine their "code vs. content" rules, otherwise we will soon Fedora being filled up with arbitrary "photo/sound/video collections" disguised as "backgrounds", "sound fonts", etc.
Ralf
[1] https://bugzilla.redhat.com/show_bug.cgi?id=538557
[2] https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content
Just this morning I was noting ("complaining about", I guess) this on IRC.
"RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> The problem I have with this package providing a precedence of how RC> to circumvent Fedora's regulations/guidelines etc. to use Fedora as RC> means to distribute "mere content".
Well, the interesting thing is that it's not this package which would provide the precedent. In fact, there are already several precedents in the distro, depending on which facet of the code vs. content issue you choose to examine.
RC> What to do about this package and about this issue in general?
All I know is that it's terribly difficult for anyone to finely define the boundary of acceptability here. Program documentation is obviously OK. What about programming documentation? A Perl tutorial or Dive into Python? A generic book on Java programming? It's not too far from there to all of Project Gutenberg, and it hasn't really been that long since the issue of books was discussed to death on fedora-devel. Not to mention that even if you could somehow accurately lay out a boundary of acceptability, you'd then have to turn around and address the issue of quality.
I have to admit, though, that pictures of your favorite city or amphibian or whatever just don't seem to me to have much point, even if they are wrapped in the necessary bits so that they work as a screensaver. But then we ship a bunch of "*-backgrounds*" packages and nobody seems to complain.
In the end, it isn't really up to FPC to make the policy on what's acceptable here, and if we're concerned about limiting the size of the distro then there's plenty of other cruft that you'd have to put up on the chopping block as well. I think FESCo is going to have to address this sooner or later, because it's not a big jump from some pictures of London to pictures of hot girls and who knows what else.
For some reason this makes me wonder if we still patch out the "penis" configuration from the snake screensaver.
- J<
On 11/20/2009 05:53 AM, Jason L Tibbitts III wrote:
Just this morning I was noting ("complaining about", I guess) this on IRC.
"RC" == Ralf Corsepiusrc040203@freenet.de writes:
RC> The problem I have with this package providing a precedence of how RC> to circumvent Fedora's regulations/guidelines etc. to use Fedora as RC> means to distribute "mere content".
Well, the interesting thing is that it's not this package which would provide the precedent. In fact, there are already several precedents in the distro, depending on which facet of the code vs. content issue you choose to examine.
I wasn't aware about this. Which packages are you referring to?
RC> What to do about this package and about this issue in general?
All I know is that it's terribly difficult for anyone to finely define the boundary of acceptability here.
Exactly.
Program documentation is obviously OK. What about programming documentation? A Perl tutorial or Dive into Python? A generic book on Java programming? It's not too far from there to all of Project Gutenberg, and it hasn't really been that long since the issue of books was discussed to death on fedora-devel. Not to mention that even if you could somehow accurately lay out a boundary of acceptability, you'd then have to turn around and address the issue of quality.
I for one, don't have much problems with such kind of content, as long as its somehow directly related to Linux and/or Fedora.
I have to admit, though, that pictures of your favorite city or amphibian or whatever just don't seem to me to have much point, even if they are wrapped in the necessary bits so that they work as a screensaver.
This is what I feel is going to happen here - Which "content collection" will be next?
<sarcasm> We should try to contact the tourism offices, marketing agencies and photographers all around the world and point them to the marketing opportunities Fedora offers to them. </sarcasm>
But then we ship a bunch of "*-backgrounds*" packages and nobody seems to complain.
Well, may-be these packages should be revisited and re-reviewed?
In the end, it isn't really up to FPC to make the policy on what's acceptable here,
Agreed. Finding a solution would be FESCO's and/or FPB's job.
and if we're concerned about limiting the size of the distro then there's plenty of other cruft that you'd have to put up on the chopping block as well. I think FESCo is going to have to address this sooner or later, because it's not a big jump from some pictures of London to pictures of hot girls and who knows what else.
For some reason this makes me wonder if we still patch out the "penis" configuration from the snake screensaver.
My concern isn't cultural issues/differences, mine is "mass" and "usefulness".
Ralf
nn2009/11/20 Ralf Corsepius rc040203@freenet.de:
Hi,
There is a package (london pictures) under review[1], which I consider to be a corner case wrt. "Code vs. content"[2].
The problem I have with this package providing a precedence of how to circumvent Fedora's regulations/guidelines etc. to use Fedora as means to distribute "mere content".
In other words, I fear this package is a precedence to opens a can of worms for content packages.
What to do about this package and about this issue in general?
My gut feeling is, Fedora should refine their "code vs. content" rules, otherwise we will soon Fedora being filled up with arbitrary "photo/sound/video collections" disguised as "backgrounds", "sound fonts", etc.
This is really tricky since there's essentially a continuum from content that has no purpose in Fedora (project Gutenberg) to content that must be in fedora (default wallpapers). Just my 0.02 EUR in the situation, i wonder if it is a good idea to start up a third party repo, like the Repo-He-Who-Shall-Not-Be-Named that provides everything that's questionable from a purpose perspective. This could include packaging all the bits found in {gnome,kde}-look and similar sites. Then we can judge by how popular it is, and how the situation develops, how critical and necessary it is for Fedora's greater Purpose.
I'd rather see the possibility to enable people to do this if they want than to categorically reject some idea, especially if it's done in a third party space.
-Yaakov
PS, i have to do something with those 2 eurocent coins i got in Germany, no one takes them here.
On 11/20/2009 01:22 PM, Yaakov Nemoy wrote:
nn2009/11/20 Ralf Corsepiusrc040203@freenet.de:
Hi,
There is a package (london pictures) under review[1], which I consider to be a corner case wrt. "Code vs. content"[2].
The problem I have with this package providing a precedence of how to circumvent Fedora's regulations/guidelines etc. to use Fedora as means to distribute "mere content".
In other words, I fear this package is a precedence to opens a can of worms for content packages.
What to do about this package and about this issue in general?
My gut feeling is, Fedora should refine their "code vs. content" rules, otherwise we will soon Fedora being filled up with arbitrary "photo/sound/video collections" disguised as "backgrounds", "sound fonts", etc.
This is really tricky since there's essentially a continuum from content that has no purpose in Fedora (project Gutenberg) to content that must be in fedora (default wallpapers). Just my 0.02 EUR in the situation, i wonder if it is a good idea to start up a third party repo, like the Repo-He-Who-Shall-Not-Be-Named that provides everything that's questionable from a purpose perspective.
Yes, this idea also had come to my mind. The more I think about it, the more I like it.
However, I am having doubts if this would be practical and if it would have a long term perpective.
Actually I'd expect such a repository to either starve out soon or to evolve into a huge Fedora "-media", "-tube", "-tunes", "-flickr" or similar.
This could include packaging all the bits found in {gnome,kde}-look and similar sites. Then we can judge by how popular it is, and how the situation develops, how critical and necessary it is for Fedora's greater Purpose.
One problem would remain on Fedora's side: Where to draw the line between "contents allowed in Fedora" and "content not allowed in Fedora"?
Ralf
Le samedi 21 novembre 2009 à 04:31 +0100, Ralf Corsepius a écrit :
On 11/20/2009 01:22 PM, Yaakov Nemoy wrote:
This is really tricky since there's essentially a continuum from content that has no purpose in Fedora (project Gutenberg) to content that must be in fedora (default wallpapers). Just my 0.02 EUR in the situation, i wonder if it is a good idea to start up a third party repo, like the Repo-He-Who-Shall-Not-Be-Named that provides everything that's questionable from a purpose perspective.
Yes, this idea also had come to my mind. The more I think about it, the more I like it.
Well I don't, unless you decide to evaluate the "purpose" of every binary in Fedora. The "purpose" of "content" is that someone found it useful enough to jump through the hoops of Fedora packager sponsorship and Fedora review. Just like the "purpose" of a random binary.
When you see the stuff that ends in the repo nowadays I don't see why "non-code" packagers should be guettoized just because they're not dealing with exalted code such as an nth broken music player, MUA, <insert random crap we package here>.
The "code" vs "content" terminology is completely broken. No one really defined what "code" was. So people take "code" for "stuff produced by coders", and anything else, even if it's useful to our target audience, even if it's produced through a similar process to C code, even if it participates in the same "Free/Libre stuff" movement as code, is rejected, if the person producing does not call himself a "coder". OTOH if you are a "coder" you have free reign as long as you know someone ready to review you.
PS Had someone packaged project Gutenberg cleanly in the past, I'm quite sure OLPC and edu Fedora spins would have been delighted.
On 11/21/2009 10:42 AM, Nicolas Mailhot wrote:
Le samedi 21 novembre 2009 à 04:31 +0100, Ralf Corsepius a écrit :
On 11/20/2009 01:22 PM, Yaakov Nemoy wrote:
This is really tricky since there's essentially a continuum from content that has no purpose in Fedora (project Gutenberg) to content that must be in fedora (default wallpapers). Just my 0.02 EUR in the situation, i wonder if it is a good idea to start up a third party repo, like the Repo-He-Who-Shall-Not-Be-Named that provides everything that's questionable from a purpose perspective.
Yes, this idea also had come to my mind. The more I think about it, the more I like it.
Well I don't, unless you decide to evaluate the "purpose" of every binary in Fedora. The "purpose" of "content" is that someone found it useful enough to jump through the hoops of Fedora packager sponsorship and Fedora review.
You will always find somebody who finds any arbitrary content useful for something, ...
When you see the stuff that ends in the repo nowadays I don't see why "non-code" packagers should be guettoized just because they're not dealing with exalted code such as an nth broken music player, MUA, <insert random crap we package here>.
We are talking about _mere content_ packages, here, ie. strictly optional "eye/ear" candy packages, things like background package of "your favorite city", "your child", "your pet", "your car/house/boat", ...
In this case, we are talking about somebody having submitted pictures of London as background images ...
The "code" vs "content" terminology is completely broken. No one really defined what "code" was.
Well, we had discussed this 100s of times before, however the topic is non-trivial.
Ralf
Le samedi 21 novembre 2009 à 11:43 +0100, Ralf Corsepius a écrit :
On 11/21/2009 10:42 AM, Nicolas Mailhot wrote:
Le samedi 21 novembre 2009 à 04:31 +0100, Ralf Corsepius a écrit :
Well I don't, unless you decide to evaluate the "purpose" of every binary in Fedora. The "purpose" of "content" is that someone found it useful enough to jump through the hoops of Fedora packager sponsorship and Fedora review.
You will always find somebody who finds any arbitrary content useful for something, ...
So what? You will always find somebody who finds any arbitrary binary useful
When you see the stuff that ends in the repo nowadays I don't see why "non-code" packagers should be guettoized just because they're not dealing with exalted code such as an nth broken music player, MUA, <insert random crap we package here>.
We are talking about _mere content_ packages, here, ie. strictly optional "eye/ear" candy packages, things like background package of "your favorite city", "your child", "your pet", "your car/house/boat", ...
As opposed to _mere binary_ packages, ie strictly optional ego-gratification badly written binaries, things like yet another MUA, yet another music player, yet another id3 editor, wanda the fish or weyes, another cpu load viewer applet, etc?
Get of your ivory tower, there is nothing in "content" that makes it magically less suitable than "code" for Fedora purposes (or the reverse)
One of the "mere content" examples given in this thread, project Gutemberg, would be massively more useful than a lot of the "code" in Fedora today (if packaged properly)
On Sat, Nov 21, 2009 at 12:26:35 +0100, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Get of your ivory tower, there is nothing in "content" that makes it magically less suitable than "code" for Fedora purposes (or the reverse)
I think that some guidance might come out of who Fedora is for and what we are going to do for them discussions going on.
One of the "mere content" examples given in this thread, project Gutemberg, would be massively more useful than a lot of the "code" in Fedora today (if packaged properly)
There are other interesting data sets that could also be put to interesting uses, for example the Tiger database covering roads and some other things in the US. I know of at least some databases with locations of municipal entities worldwide, and I haven't looked at this before Google started their mapping project, so there might be a lot more data available.
2009/11/21 Ralf Corsepius rc040203@freenet.de:
On 11/20/2009 01:22 PM, Yaakov Nemoy wrote:
nn2009/11/20 Ralf Corsepiusrc040203@freenet.de:
Hi,
There is a package (london pictures) under review[1], which I consider to be a corner case wrt. "Code vs. content"[2].
The problem I have with this package providing a precedence of how to circumvent Fedora's regulations/guidelines etc. to use Fedora as means to distribute "mere content".
In other words, I fear this package is a precedence to opens a can of worms for content packages.
What to do about this package and about this issue in general?
My gut feeling is, Fedora should refine their "code vs. content" rules, otherwise we will soon Fedora being filled up with arbitrary "photo/sound/video collections" disguised as "backgrounds", "sound fonts", etc.
This is really tricky since there's essentially a continuum from content that has no purpose in Fedora (project Gutenberg) to content that must be in fedora (default wallpapers). Just my 0.02 EUR in the situation, i wonder if it is a good idea to start up a third party repo, like the Repo-He-Who-Shall-Not-Be-Named that provides everything that's questionable from a purpose perspective.
Yes, this idea also had come to my mind. The more I think about it, the more I like it.
However, I am having doubts if this would be practical and if it would have a long term perpective.
Actually I'd expect such a repository to either starve out soon or to evolve into a huge Fedora "-media", "-tube", "-tunes", "-flickr" or similar.
That is exactly the idea.
1) It starves, and then we say, told you so, now get back to doing real packaging work.
2) It turns into a blob of a media repository, attracts a certain kind of attention and grows into its own project, i don't see anything wrong there either. This has some potential for alot of people, such as OLPC. Having Fedora's expertise on how to do packaging right means this project gets better quality too.
3) It finds a middle ground between the two. Now we're stuck with the tricky part where we have to evaluate if it fits in Fedora or not. The catch is we can't predict how it will develop though, so we can't even begin to discuss it.
In all three scenarios, the idea is to let such a concept play out. Rather than trying to discuss it's merits now, just let it happen, and we can make a better decision later.
This could include packaging all the bits found in {gnome,kde}-look and similar sites. Then we can judge by how popular it is, and how the situation develops, how critical and necessary it is for Fedora's greater Purpose.
One problem would remain on Fedora's side: Where to draw the line between "contents allowed in Fedora" and "content not allowed in Fedora"?
As long as there's a blessed third party repo (maybe we should call them second party repos), then if there's a doubt if it's really relevant, we can be conservative and say it doesn't belong in Fedora. Right now, the situation is that we're fussing around about where the line is. This is important because if something falls outside of the lines, then we don't include it, and we have nowhere clear for that kind of content to go. If we have an alternative destination, we're in a similar situation with the Repo Who Shall Not Be Named. Instead of saying, 'Sorry, No Dice', we can suggest, 'Try going here?'. There's no need to feel like we're being mean and obsessing about doing the wrong thing because both decisions are 'right'. (Disclaimer: Only if you believe in the idea of good and bad.)
-Yaakov
On Sat, Nov 21, 2009 at 12:26:38PM +0100, Yaakov Nemoy wrote:
Actually I'd expect such a repository to either starve out soon or to evolve into a huge Fedora "-media", "-tube", "-tunes", "-flickr" or similar.
That is exactly the idea.
- It starves, and then we say, told you so, now get back to doing
real packaging work.
- It turns into a blob of a media repository, attracts a certain kind
of attention and grows into its own project, i don't see anything wrong there either. This has some potential for alot of people, such as OLPC. Having Fedora's expertise on how to do packaging right means this project gets better quality too.
- It finds a middle ground between the two. Now we're stuck with the
tricky part where we have to evaluate if it fits in Fedora or not. The catch is we can't predict how it will develop though, so we can't even begin to discuss it.
In all three scenarios, the idea is to let such a concept play out. Rather than trying to discuss it's merits now, just let it happen, and we can make a better decision later.
One technical point -- I don't think that Fedora rpm packaging is really the right technology for this. I don't think it scales to what we want. I don't know of any code-oriented packaging that would.
Here are some of the limitations I see: * namespace: I package londonpictures. You also have pictures of london... what do you call your package? * repository size: How many individual photos are there on flikr? Potentially, we can have photo packages on that order of magnitude. * description and search: We're getting to the point where we have good searching via yum for packages. But how do we do the same thing for collections of photos? Let's say I want pictures of rubbish bins. How does that pull a single picture out of the londonpictures package?
Is content useful? Yes, I think so. Should there be free software means of delivering content to others, yes I think so. Should there be a way to manage content on your computer? Yes, I think so. Is rpm packaging the right way to do that? No, I don't think so. Is the Fedora Project a venue where we can try to launch a free software means of doing this? I do think it fits in with our mission. I'm unsure of the overall benefit to our users (there *are* definite benefits in certain areas -- like being able to search Project Gutenberg, use a netbook like an ebook reader, have data for mapping software, etc) however, there might be other, distro neutral projects that we should work more closely with to achieve these goal -- for instance, partner with open street maps to let people upload and share mapping information there but provide a standard location for it to be on the filesystem, help code libraries and APIs to search and download them from the network to the local machine, and building desktop tools that use that information.
-Toshio
2009/11/21 Toshio Kuratomi a.badger@gmail.com:
On Sat, Nov 21, 2009 at 12:26:38PM +0100, Yaakov Nemoy wrote:
Actually I'd expect such a repository to either starve out soon or to evolve into a huge Fedora "-media", "-tube", "-tunes", "-flickr" or similar.
That is exactly the idea.
- It starves, and then we say, told you so, now get back to doing
real packaging work.
- It turns into a blob of a media repository, attracts a certain kind
of attention and grows into its own project, i don't see anything wrong there either. This has some potential for alot of people, such as OLPC. Having Fedora's expertise on how to do packaging right means this project gets better quality too.
- It finds a middle ground between the two. Now we're stuck with the
tricky part where we have to evaluate if it fits in Fedora or not. The catch is we can't predict how it will develop though, so we can't even begin to discuss it.
In all three scenarios, the idea is to let such a concept play out. Rather than trying to discuss it's merits now, just let it happen, and we can make a better decision later.
One technical point -- I don't think that Fedora rpm packaging is really the right technology for this. I don't think it scales to what we want. I don't know of any code-oriented packaging that would.
Here are some of the limitations I see:
- namespace: I package londonpictures. You also have pictures of london...
what do you call your package?
- repository size: How many individual photos are there on flikr?
Potentially, we can have photo packages on that order of magnitude.
- description and search: We're getting to the point where we have good
searching via yum for packages. But how do we do the same thing for collections of photos? Let's say I want pictures of rubbish bins. How does that pull a single picture out of the londonpictures package?
Point taken. Can we agree this is just a technical issue though?
Is content useful? Yes, I think so. Should there be free software means of delivering content to others, yes I think so. Should there be a way to manage content on your computer? Yes, I think so. Is rpm packaging the right way to do that? No, I don't think so. Is the Fedora Project a venue where we can try to launch a free software means of doing this? I do think it fits in with our mission. I'm unsure of the overall benefit to our users (there *are* definite benefits in certain areas -- like being able to search Project Gutenberg, use a netbook like an ebook reader, have data for mapping software, etc) however, there might be other, distro neutral projects that we should work more closely with to achieve these goal -- for instance, partner with open street maps to let people upload and share mapping information there but provide a standard location for it to be on the filesystem, help code libraries and APIs to search and download them from the network to the local machine, and building desktop tools that use that information.
I'm thinking this might be a good candidate for a GSoC / Newcomer project. We can discuss it further, but if you find someone who's looking to become a new contributor somehow, i'm willing to mentor such an initiative. I think this goes beyond the scope of just creating another blessed third party repo but it's probably very useful in the end.
-Yaakov
On Sun, Nov 22, 2009 at 03:05:49PM +0100, Yaakov Nemoy wrote:
2009/11/21 Toshio Kuratomi a.badger@gmail.com:
One technical point -- I don't think that Fedora rpm packaging is really the right technology for this. I don't think it scales to what we want. I don't know of any code-oriented packaging that would.
Point taken. Can we agree this is just a technical issue though?
For me the big thing is the technical issue.
Is content useful? Yes, I think so. Should there be free software means of delivering content to others, yes I think so. Should there be a way to manage content on your computer? Yes, I think so. Is rpm packaging the right way to do that? No, I don't think so. Is the Fedora Project a venue where we can try to launch a free software means of doing this? I do think it fits in with our mission. I'm unsure of the overall benefit to our users (there *are* definite benefits in certain areas -- like being able to search Project Gutenberg, use a netbook like an ebook reader, have data for mapping software, etc) however, there might be other, distro neutral projects that we should work more closely with to achieve these goal -- for instance, partner with open street maps to let people upload and share mapping information there but provide a standard location for it to be on the filesystem, help code libraries and APIs to search and download them from the network to the local machine, and building desktop tools that use that information.
I'm thinking this might be a good candidate for a GSoC / Newcomer project. We can discuss it further, but if you find someone who's looking to become a new contributor somehow, i'm willing to mentor such an initiative. I think this goes beyond the scope of just creating another blessed third party repo but it's probably very useful in the end.
Possibly. But this is one which requires large amounts of non-coding skills. It's not about pure code here. There's a need to build something that crosses several different upstream projects. The data provider is the best place to host "packages". The other unixy distros need to be consulted to agree on where to put the files. Various desktop environments need to be influenced to agree on an API that the tools they promote can use.
Actual coding parts of the project would be the library to access the data and creating the infrstructure upstream to take submissions of new data, search their data, and make sure their data can be retrieved programmatically (and scalably).
-Toshio
2009/11/22 Toshio Kuratomi a.badger@gmail.com:
On Sun, Nov 22, 2009 at 03:05:49PM +0100, Yaakov Nemoy wrote:
2009/11/21 Toshio Kuratomi a.badger@gmail.com:
One technical point -- I don't think that Fedora rpm packaging is really the right technology for this. I don't think it scales to what we want. I don't know of any code-oriented packaging that would.
Point taken. Can we agree this is just a technical issue though?
For me the big thing is the technical issue.
Is content useful? Yes, I think so. Should there be free software means of delivering content to others, yes I think so. Should there be a way to manage content on your computer? Yes, I think so. Is rpm packaging the right way to do that? No, I don't think so. Is the Fedora Project a venue where we can try to launch a free software means of doing this? I do think it fits in with our mission. I'm unsure of the overall benefit to our users (there *are* definite benefits in certain areas -- like being able to search Project Gutenberg, use a netbook like an ebook reader, have data for mapping software, etc) however, there might be other, distro neutral projects that we should work more closely with to achieve these goal -- for instance, partner with open street maps to let people upload and share mapping information there but provide a standard location for it to be on the filesystem, help code libraries and APIs to search and download them from the network to the local machine, and building desktop tools that use that information.
I'm thinking this might be a good candidate for a GSoC / Newcomer project. We can discuss it further, but if you find someone who's looking to become a new contributor somehow, i'm willing to mentor such an initiative. I think this goes beyond the scope of just creating another blessed third party repo but it's probably very useful in the end.
Possibly. But this is one which requires large amounts of non-coding skills. It's not about pure code here. There's a need to build something that crosses several different upstream projects. The data provider is the best place to host "packages". The other unixy distros need to be consulted to agree on where to put the files. Various desktop environments need to be influenced to agree on an API that the tools they promote can use.
Actual coding parts of the project would be the library to access the data and creating the infrstructure upstream to take submissions of new data, search their data, and make sure their data can be retrieved programmatically (and scalably).
Depends on how the project is done. I'd rather take on a project with a new comer that is willing to work with both sides of the angle.
I see a number of issues here. We need to decide how to take in various kinds of media, pictures, icons, annoying bleeps and bloops for the desktop, creative works such as window manager themes, and so on. We need to decide how to store it. How to deliver it to a particular machine (KDE has a decent example of this where you can go online to get new wallpaper). A way to manage the content stored on the machine. A way to mass deploy content. A way to manage 'collections' such as themes. All the nitty gritty file system details. How to do things system wide. Per Distro. etc...
Part of this is just saying, 'we need', in a very general purpose manner, 'a system for sharing "content" that goes beyond packaging', and listen to the newcomer, potentially a GSoC student, to propose a plan that works.
But that's my 0.02 cents.
-Yaakov
On Fri, Nov 20, 2009 at 04:56:39AM +0100, Ralf Corsepius wrote:
There is a package (london pictures) under review[1], which I consider to be a corner case wrt. "Code vs. content"[2]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=538557
I downloaded this package and looked at the pictures.
Firstly, I have no objection to such a package. It's only 2.6 MB, and even if it "opens the floodgates" to having a corresponding package for every other city in the world, I wouldn't mind.
However, the problem is that the pictures in this particular package are *rubbish*. (In some cases, they are pictures *of* rubbish!) Don't take my word for it, take a look for yourselves:
http://annexia.org/tmp/londonpictures/
So I feel unfortunately this is a bad case. Superb, high-quality pictures from cities around the world would make a fantastic screensaver ...
Rich.
"RWMJ" == Richard W M Jones rjones@redhat.com writes:
RWMJ> So I feel unfortunately this is a bad case.
Except that it's actually a spectacularly good case, because it perfectly illustrates the problem. Someone thinks this is a good package and wants it in Fedora. (Either that or they're actively trolling us to see what crap they can push through the review process.) It doesn't violate any guidelines. You happen to not like the content. Does that means the package stays out? I don't personally want to be the quality czar, but I also don't want to see people pushing their vacation photos into Fedora.
Isn't there already a screensaver that will work from a directory of pictures? Isn't that good enough to cover all of these cases without us actually having to carry a bunch of pictures?
- J<
Jason L Tibbitts III wrote:
"RWMJ" == Richard W M Jones rjones@redhat.com writes:
RWMJ> So I feel unfortunately this is a bad case.
Except that it's actually a spectacularly good case, because it perfectly illustrates the problem. Someone thinks this is a good package and wants it in Fedora. (Either that or they're actively trolling us to see what crap they can push through the review process.) It doesn't violate any guidelines. You happen to not like the content. Does that means the package stays out? I don't personally want to be the quality czar, but I also don't want to see people pushing their vacation photos into Fedora.
Isn't there already a screensaver that will work from a directory of pictures? Isn't that good enough to cover all of these cases without us actually having to carry a bunch of pictures?
- J<
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
There is. I woke it up to read this. Works great. On any pictures I want, scads of formats.
Now, write a new screensaver that does something different, and includes these pix as the default fodder for it, and you've got something else entirely. I'd err on the side of keeping this out.
-J
On Fri, Nov 20, 2009 at 01:02:05PM -0600, Jason L Tibbitts III wrote:
"RWMJ" == Richard W M Jones rjones@redhat.com writes:
RWMJ> So I feel unfortunately this is a bad case.
Except that it's actually a spectacularly good case, because it perfectly illustrates the problem. Someone thinks this is a good package and wants it in Fedora. (Either that or they're actively trolling us to see what crap they can push through the review process.) It doesn't violate any guidelines. You happen to not like the content. Does that means the package stays out? I don't personally want to be the quality czar, but I also don't want to see people pushing their vacation photos into Fedora.
No, I still think it's a bad case.
Consider the cosmos screensaver that we carry:
$ rpm -qf /usr/share/backgrounds/cosmos gnome-screensaver-2.28.0-1.fc12.x86_64
Those are some really beautiful NASA photographs, and I don't think anyone would object to the 3.9 MB consumed by those lovely pictures, particularly if you are in any way interested by space technology or science.
I think if these were really beautiful pictures of London, no one would object to 2.6 MB. But because it's a bunch of rather crap pictures, it makes a bad case for what I think could potentially be a wonderful thing.
Isn't there already a screensaver that will work from a directory of pictures? Isn't that good enough to cover all of these cases without us actually having to carry a bunch of pictures?
A directory of pictures isn't a hand-chosen set of great photographs that get installed from a single yum command.
Rich.
"RWMJ" == Richard W M Jones rjones@redhat.com writes:
RWMJ> A directory of pictures isn't a hand-chosen set of great RWMJ> photographs that get installed from a single yum command.
To someone, the londonpictures thing is a hand-chosen set of great photographs that get installed with a single yum command. You're just not that someone.
- J<
On Fri, Nov 20, 2009 at 01:36:30PM -0600, Jason L Tibbitts III wrote:
To someone, the londonpictures thing is a hand-chosen set of great photographs [...]
I don't want to go on arguing about this, but really this is different.
I'm not being an "art ponce" and having some fine art debate about the londonpictures set. Even I can see that there are massive technical problems with them.
This one has obvious aliasing problems, as if it was resized without using a decent scaling algorithm:
http://annexia.org/tmp/londonpictures/londonpictures_01.jpg
This one is a picture of a dog litter bin, with a camera flash and the photographer's shadow clearly visible:
http://annexia.org/tmp/londonpictures/londonpictures_18.jpg
No one (sane) would choose these as great photographs.
So any argument around this particular set of photographs is going to be based on a poor example. I think it would be better to frame this in terms of good photographs. What if someone submitted a similar package, but with photos like these:
http://commons.wikimedia.org/wiki/File:Palace_of_Westminster.jpg http://commons.wikimedia.org/wiki/File:London_Eye,_London.JPG http://commons.wikimedia.org/wiki/File:Tube_station_2_cz.jpg
(Not just an RSS feed but a hand-picked selection of the best city photos from Wikicommons).
Rich.
"RWMJ" == Richard W M Jones rjones@redhat.com writes:
RWMJ> I don't want to go on arguing about this, but really this is RWMJ> different.
The only difference I can see is that you personally like some photographs and don't like others, and you want to shift the discussion to photographs that you like. I can't comprehend what difference it makes to the underlying issue. I'm sure that it's easy to take photographs that satisfy all of those technical requirements you set out, with no aliasing problems, no visible camera flashes or photographer shadows, which would still elicit the same discussion.
I have to agree with an earlier message in this thread: we have an art team, and I'd sure love to be able to defer to their opinion on this kind of thing. Of course, then you get into the tough issue of defining when something needs to be approved by the art team, and that's probably just as intractable a problem.
- J<
Jason L Tibbitts III (tibbs@math.uh.edu) said:
Isn't there already a screensaver that will work from a directory of pictures?
Yes.
Isn't that good enough to cover all of these cases without us actually having to carry a bunch of pictures?
Maybe? I suspect the 'proper' solution is to implement a RSS-fed screensaver, so you can point it at whatever flickr/shutterfly/etc. feeds that you want.
Bill
Le vendredi 20 novembre 2009 à 13:02 -0600, Jason L Tibbitts III a écrit :
You happen to not like the content. Does that means the package stays out? I don't personally want to be the quality czar, but I also don't want to see people pushing their vacation photos into Fedora.
I don't see why such decisions could not be pushed to the art team. They're responsible for the artistic decisions in Fedora.
On Fri, Nov 20, 2009 at 08:24:22PM +0100, Nicolas Mailhot wrote:
Le vendredi 20 novembre 2009 à 13:02 -0600, Jason L Tibbitts III a écrit :
You happen to not like the content. Does that means the package stays out? I don't personally want to be the quality czar, but I also don't want to see people pushing their vacation photos into Fedora.
I don't see why such decisions could not be pushed to the art team. They're responsible for the artistic decisions in Fedora.
Well... banning certain packages is a FESCo decision. they are welcome to delegate, though :-)
I'd rather have a FESCo decision on what content is acceptable from FESCo, though. The art team can evaluate the quality of the art but that's not really waht we're after -- we want to know to what extent content is acceptable. Is it a free for all? Is it a must be releavant to computers? Is it relevant to computers or chosen by the art team?
-Toshio
packaging@lists.fedoraproject.org
-
Bill Nottingham -
Bruno Wolff III -
Jason L Tibbitts III -
Jon Ciesla -
Nicolas Mailhot -
Ralf Corsepius -
Richard W.M. Jones -
Toshio Kuratomi -
Yaakov Nemoy