Re: [arch-general] [arch-dev-public] policy on desktop files?
Hi, i wanted to note that there is http://wiki.archlinux.org/index.php/Desktop_Project maintained by bardo a TU, which mentions absolutely nothing about upstream. Instead it says "I (bardo) will write/modify the necessary files and notify the corresponding maintainers so they can be added to the packages." Additionally there are links to the bug tracker. I have no idea if bardo submitts them upstream as well but i doubt it. Greg
On Thu, May 8, 2008 at 2:29 PM, Grigorios Bouzakis <grbzks@gmail.com> wrote:
Hi, i wanted to note that there is http://wiki.archlinux.org/index.php/Desktop_Project maintained by bardo a TU, which mentions absolutely nothing about upstream. Instead it says "I (bardo) will write/modify the necessary files and notify the corresponding maintainers so they can be added to the packages." Additionally there are links to the bug tracker. I have no idea if bardo submitts them upstream as well but i doubt it.
At the moment I don't. When I announced the project it got a good reaction, so I carried on with it, but after a while creating and providing desktop files through the bug tracker I started receiving the "upstream problem" answer. This has become pretty frequent, so lately I haven't been doing very much on the Arch side. The few developers I tried to contact didn't do anything, so I suppose there's little to no interest from them. The whole thing has started to become more frustrating than anything, so at the moment I'm not working on it anymore. Corrado
On Thursday 08 May 2008 15:58:51 bardo wrote:
On Thu, May 8, 2008 at 2:29 PM, Grigorios Bouzakis <grbzks@gmail.com> wrote:
Hi, i wanted to note that there is http://wiki.archlinux.org/index.php/Desktop_Project maintained by bardo a TU, which mentions absolutely nothing about upstream. Instead it says "I (bardo) will write/modify the necessary files and notify the corresponding maintainers so they can be added to the packages." Additionally there are links to the bug tracker. I have no idea if bardo submitts them upstream as well but i doubt it.
At the moment I don't. When I announced the project it got a good reaction, so I carried on with it, but after a while creating and providing desktop files through the bug tracker I started receiving the "upstream problem" answer. This has become pretty frequent, so lately I haven't been doing very much on the Arch side. The few developers I tried to contact didn't do anything, so I suppose there's little to no interest from them.
The whole thing has started to become more frustrating than anything, so at the moment I'm not working on it anymore.
IMHO, even though I'm aggresively against patching, I don't consider the .desktop files as patches. They are some extra, *non-code* files, that is fair for the distro to provide (like other configuration files). I don't really blame the app developers that don't include them upstream. Dimitris
Corrado
On Thu, May 08, 2008 at 03:53:29PM +0300, Dimitrios Apostolou wrote:
On Thursday 08 May 2008 15:58:51 bardo wrote:
On Thu, May 8, 2008 at 2:29 PM, Grigorios Bouzakis <grbzks@gmail.com> wrote:
Hi, i wanted to note that there is http://wiki.archlinux.org/index.php/Desktop_Project maintained by bardo a TU, which mentions absolutely nothing about upstream. Instead it says "I (bardo) will write/modify the necessary files and notify the corresponding maintainers so they can be added to the packages." Additionally there are links to the bug tracker. I have no idea if bardo submitts them upstream as well but i doubt it.
At the moment I don't. When I announced the project it got a good reaction, so I carried on with it, but after a while creating and providing desktop files through the bug tracker I started receiving the "upstream problem" answer. This has become pretty frequent, so lately I haven't been doing very much on the Arch side. The few developers I tried to contact didn't do anything, so I suppose there's little to no interest from them.
The whole thing has started to become more frustrating than anything, so at the moment I'm not working on it anymore.
IMHO, even though I'm aggresively against patching, I don't consider the .desktop files as patches. They are some extra, *non-code* files, that is fair for the distro to provide (like other configuration files). I don't really blame the app developers that don't include them upstream.
True, they are not patches, but they should be part of the applicqations source. Requering from packagers to write & include a .desktop file in their ditros for actively developed projects is IMO unecceptable today with linux being part of the desktop market. If they dont provide one its quite clear they dont want having one. If i submit a ,desktop file upstream and it gets rejected it should be treated the same as a rejected patch. Exception to the above rule would be projects not being actively developed anymore and only them. Greg
On Thu, May 8, 2008 at 9:27 AM, Grigorios Bouzakis <grbzks@gmail.com> wrote:
On Thu, May 08, 2008 at 03:53:29PM +0300, Dimitrios Apostolou wrote:
On Thursday 08 May 2008 15:58:51 bardo wrote:
On Thu, May 8, 2008 at 2:29 PM, Grigorios Bouzakis <grbzks@gmail.com> wrote:
Hi, i wanted to note that there is http://wiki.archlinux.org/index.php/Desktop_Project maintained by bardo a TU, which mentions absolutely nothing about upstream. Instead it says "I (bardo) will write/modify the necessary files and notify the corresponding maintainers so they can be added to the packages." Additionally there are links to the bug tracker. I have no idea if bardo submitts them upstream as well but i doubt it.
At the moment I don't. When I announced the project it got a good reaction, so I carried on with it, but after a while creating and providing desktop files through the bug tracker I started receiving the "upstream problem" answer. This has become pretty frequent, so lately I haven't been doing very much on the Arch side. The few developers I tried to contact didn't do anything, so I suppose there's little to no interest from them.
The whole thing has started to become more frustrating than anything, so at the moment I'm not working on it anymore.
IMHO, even though I'm aggresively against patching, I don't consider the .desktop files as patches. They are some extra, *non-code* files, that is fair for the distro to provide (like other configuration files). I don't really blame the app developers that don't include them upstream.
True, they are not patches, but they should be part of the applicqations source. Requering from packagers to write & include a .desktop file in their ditros for actively developed projects is IMO unecceptable today with linux being part of the desktop market. If they dont provide one its quite clear they dont want having one. If i submit a ,desktop file upstream and it gets rejected it should be treated the same as a rejected patch. Exception to the above rule would be projects not being actively developed anymore and only them.
Greg
We needn't get bogged down in another "is this the ARCH WAY?!?!" conversation here; I don't think it needs to be a policy decision. If neither Arch nor upstream want to deal with .desktop files (and they both seem to have their reasons), would it be possible to host some space somewhere that users could post their own? It wouldn't need to be Arch-hosted, perhaps this is a sf project waiting to happen; sort of a searchable repository for orphaned .desktop files? I'd be happy to go download .desktops from somewhere if they aren't already included. -- Ryan W Sims
On Thu 2008-05-08 10:06 , Ryan Sims wrote:
We needn't get bogged down in another "is this the ARCH WAY?!?!" conversation here;
I swear I don't want to.
I don't think it needs to be a policy decision. If neither Arch nor upstream want to deal with .desktop files (and they both seem to have their reasons), would it be possible to host some space somewhere that users could post their own? It wouldn't need to be Arch-hosted, perhaps this is a sf project waiting to happen; sort of a searchable repository for orphaned .desktop files? I'd be happy to go download .desktops from somewhere if they aren't already included.
This patch-phobia is getting ludicrous: if an application with a GUI, that users expect to be find in the menus, doesn't have a .desktop file, the maintainer should include it in the package AND submit it upstream. A repository for .desktop? Nonsense. -- Alessio (molok) Bolognino Please send personal email to themolok@gmail.com Public Key http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xFE0270FB GPG Key ID = 1024D / FE0270FB 2007-04-11 Key Fingerprint = 9AF8 9011 F271 450D 59CF 2D7D 96C9 8F2A FE02 70FB
On Thu, May 8, 2008 at 10:32 AM, Alessio Bolognino <themolok.ml@gmail.com> wrote:
On Thu 2008-05-08 10:06 , Ryan Sims wrote:
We needn't get bogged down in another "is this the ARCH WAY?!?!" conversation here;
I swear I don't want to.
I believe you, I just wanted to preempt one.
I don't think it needs to be a policy decision. If neither Arch nor upstream want to deal with .desktop files (and they both seem to have their reasons), would it be possible to host some space somewhere that users could post their own? It wouldn't need to be Arch-hosted, perhaps this is a sf project waiting to happen; sort of a searchable repository for orphaned .desktop files? I'd be happy to go download .desktops from somewhere if they aren't already included.
This patch-phobia is getting ludicrous: if an application with a GUI, that users expect to be find in the menus, doesn't have a .desktop file, the maintainer should include it in the package AND submit it upstream.
A repository for .desktop? Nonsense.
Sorry, I didn't mean a repository like [core],[community] or such; I meant it in the more general sense of "a place where things are kept." They're small files, so a free wiki account somewhere could probably host them without breaking much of a sweat. One should still file bugreports, but a .desktop library would be a stopgap solution while the various devs work out policy. I'm not a dev, so I can't propose dev-oriented solutions, so I thought I'd propose a community-oriented solution. -- Ryan W Sims
On Thu, May 8, 2008 at 9:27 AM, Grigorios Bouzakis <grbzks@gmail.com> wrote:
On Thu, May 08, 2008 at 03:53:29PM +0300, Dimitrios Apostolou wrote:
On Thu, May 8, 2008 at 2:29 PM, Grigorios Bouzakis <grbzks@gmail.com> wrote:
Hi, i wanted to note that there is http://wiki.archlinux.org/index.php/Desktop_Project maintained by bardo a TU, which mentions absolutely nothing about upstream. Instead it says "I (bardo) will write/modify the necessary files and notify the corresponding maintainers so they can be added to
On Thursday 08 May 2008 15:58:51 bardo wrote: the packages." Additionally there are links to the bug tracker. I have no idea if bardo submitts them upstream as well but i doubt it.
At the moment I don't. When I announced the project it got a good
reaction, so I carried on with it, but after a while creating and providing desktop files through the bug tracker I started receiving the "upstream problem" answer. This has become pretty frequent, so lately I haven't been doing very much on the Arch side. The few developers I tried to contact didn't do anything, so I suppose there's little to no interest from them.
The whole thing has started to become more frustrating than
anything, so at the moment I'm not working on it anymore.
IMHO, even though I'm aggresively against patching, I don't consider the .desktop files as patches. They are some extra, *non-code* files, that is fair for the distro to provide (like other configuration files). I don't really blame the app developers that don't include them upstream.
True, they are not patches, but they should be part of the applicqations source. Requering from packagers to write & include a .desktop file in their ditros for actively developed projects is IMO unecceptable today with linux being part of the desktop market. If they dont provide one its quite clear they dont want having one. If i submit a ,desktop file upstream and it gets rejected it should be treated the same as a rejected patch. Exception to the above rule would be projects not being actively developed anymore and only them.
Greg
We needn't get bogged down in another "is this the ARCH WAY?!?!" conversation here; I don't think it needs to be a policy decision. If neither Arch nor upstream want to deal with .desktop files (and they both seem to have their reasons), would it be possible to host some space somewhere that users could post their own? It wouldn't need to be Arch-hosted, perhaps this is a sf project waiting to happen; sort of a searchable repository for orphaned .desktop files? I'd be happy to go download .desktops from somewhere if they aren't already included.
-- Ryan W Sims
Anything that I package that could or should have a .desktop file is supplied in the "arch-binary-tarball" I create, even if it is not upstream. Why ?, well there is no reason NOT to have one in such circumstances, and often the upstream guys are expecting the downstream packagers to supply it. <- And that's o.k. with me. ** There can also be other reasons the upstream guys don't supply a .desktop file; but MOST importantly it is never a situation wherein the upstream guys do not want me to add one. NO ONE has ever said "please do NOT add that file to the binary". So I often do add such a file. And so it goes..... Very best regards; Bob Finch Liviu Librescu - În veci pomenirea lui. (May his memory be eternal.)
On Thu, May 8, 2008 at 6:32 PM, <w9ya@qrparci.net> wrote:
Why ?, well there is no reason NOT to have one in such circumstances, and often the upstream guys are expecting the downstream packagers to supply it. <- And that's o.k. with me.
That's not alright. Anything that causes useless and stupid duplicated work is not alright. In my opinion, here is how things should work: User X notices package foo is missing a .desktop file X checks if a desktop file is already provided in upstream source tarball If yes, he reports a bug on arch bug tracker asking to provide the desktop file, and it's over. If not, he writes a desktop file and submit it upstream. If upstream accepts, it's over. If upstream first refuses, people should keep insisting and trying to make sense of them. Finally, in the (hopefully few) cases where upstream is really too dumb, he can submit it to arch bug tracker as an arch specific desktop file. Hopefully this should reduce the load of arch packagers and move it to arch community and upstream.
Hi, Xavier wrote:
Hopefully this should reduce the load of arch packagers and move it to arch community and upstream.
There is also the situation that upstream may not provide a .desktop file on the basis of: 1) The belief that distributions should decide which menu the item should appear on 2) The desire not to get involved with providing I18N for the .desktop contents If upstream is forced to provide a .desktop file which requires modification of e.g. category or provision of additional I18N content then we're now in the realms of patching .desktop files too. I agree that any .desktop file we create should be submitted upstream, at least for their consideration. Regards, Neil Darlow
On Thu, May 8, 2008 at 6:32 PM, <w9ya@qrparci.net> wrote:
Why ?, well there is no reason NOT to have one in such circumstances, and often the upstream guys are expecting the downstream packagers to supply it. <- And that's o.k. with me.
That's not alright. Anything that causes useless and stupid duplicated work is not alright. In my opinion, here is how things should work: User X notices package foo is missing a .desktop file X checks if a desktop file is already provided in upstream source tarball If yes, he reports a bug on arch bug tracker asking to provide the desktop file, and it's over. If not, he writes a desktop file and submit it upstream. If upstream accepts, it's over. If upstream first refuses, people should keep insisting and trying to make sense of them. Finally, in the (hopefully few) cases where upstream is really too dumb, he can submit it to arch bug tracker as an arch specific desktop file.
Hopefully this should reduce the load of arch packagers and move it to arch community and upstream.
It entails NO 'duplicated work' for me to supply a .desktop file when one is not extent. And my supplying it is not 'useless' (work) either. (And since I work from a template, it is also simple.) Um, your "policy" steps above sure seems to be a lot more steps than just making a .desktop file and including in the package while also submitting it to the upstream package author. Of course IF the upstream adopts the .desktop file then the package maintainer can remove his. <- If you are really advocating *less* "duplicated" and "useless" work, I cannot accept this set of steps you propose as a way to achieve that result. Or put more succinctly, we do NOT need a policy on this past just some plain ol' common sense. i.e. DO what you can for the folks downstream that will be using the package you are maintaining, (make them a .desktop file). And let the folks upstream (that author the program code) know about your .desktop file so they can adopt what you wrote if they choose to. And NO I am NOT gonna generate a "useless" arch bug report about it. Very best regards; Bob Finch Liviu Librescu - În veci pomenirea lui. (May his memory be eternal.)
w9ya@qrparci.net wrote:
It entails NO 'duplicated work' for me to supply a .desktop file when one is not extent. And my supplying it is not 'useless' (work) either. (And since I work from a template, it is also simple.)
Um, your "policy" steps above sure seems to be a lot more steps than just making a .desktop file and including in the package while also submitting it to the upstream package author. Of course IF the upstream adopts the .desktop file then the package maintainer can remove his. <- If you are really advocating *less* "duplicated" and "useless" work, I cannot accept this set of steps you propose as a way to achieve that result.
Or put more succinctly, we do NOT need a policy on this past just some plain ol' common sense. i.e. DO what you can for the folks downstream that will be using the package you are maintaining, (make them a .desktop file). And let the folks upstream (that author the program code) know about your .desktop file so they can adopt what you wrote if they choose to. And NO I am NOT gonna generate a "useless" arch bug report about it.
It's plain ol' common sense that you don't need a bug report if you are maintaining the package yourself... The extra steps are obviously only required for users. Btw, this wasn't meant as a policy but just some guidelines for users who don't know what to do when they notice a missing desktop file and would like to help out.
w9ya@qrparci.net wrote:
It entails NO 'duplicated work' for me to supply a .desktop file when one is not extent. And my supplying it is not 'useless' (work) either. (And since I work from a template, it is also simple.)
Um, your "policy" steps above sure seems to be a lot more steps than just making a .desktop file and including in the package while also submitting it to the upstream package author. Of course IF the upstream adopts the .desktop file then the package maintainer can remove his. <- If you are really advocating *less* "duplicated" and "useless" work, I cannot accept this set of steps you propose as a way to achieve that result.
Or put more succinctly, we do NOT need a policy on this past just some plain ol' common sense. i.e. DO what you can for the folks downstream that will be using the package you are maintaining, (make them a .desktop file). And let the folks upstream (that author the program code) know about your .desktop file so they can adopt what you wrote if they choose to. And NO I am NOT gonna generate a "useless" arch bug report about it.
It's plain ol' common sense that you don't need a bug report if you are maintaining the package yourself... The extra steps are obviously only required for users.
Um no. It should NOT be a requirement for anyone. A requirement is a policy statement. And that is just plain silly for all of your steps to do something so simple to add to create and ad to a PKGBUILD.
Btw, this wasn't meant as a policy but just some guidelines for users who don't know what to do when they notice a missing desktop file and would like to help out.
Uh huh... well the end users can just ask the package maintainer to see what they can do. Just one email. No bug reports and the attendant extra work those usually involve. i.e. Simple and usually exceptionally effective for an easy fix that takes but a few minutes to do. <- What do I mean ?; Well it takes me about 5 minutes to add a working .desktop file to a package. It would take me at least twice that time to log in and clear a bug report. That's wasteful. Very best regards; Bob Finch Liviu Librescu - În veci pomenirea lui. (May his memory be eternal.)
On Mon, May 12, 2008 at 10:49 PM, <w9ya@qrparci.net> wrote:
Uh huh... well the end users can just ask the package maintainer to see what they can do. Just one email. No bug reports and the attendant extra work those usually involve. i.e. Simple and usually exceptionally effective for an easy fix that takes but a few minutes to do. <- What do I mean ?; Well it takes me about 5 minutes to add a working .desktop file to a package. It would take me at least twice that time to log in and clear a bug report. That's wasteful.
Minor off topic gripe here. English has existed for way to long without the need for arrows in the language. I see *waaaaay* too many people talking <- like this recently
On Mon, May 12, 2008 at 10:49 PM, <w9ya@qrparci.net> wrote:
Uh huh... well the end users can just ask the package maintainer to see what they can do. Just one email. No bug reports and the attendant extra work those usually involve. i.e. Simple and usually exceptionally effective for an easy fix that takes but a few minutes to do. <- What do I mean ?; Well it takes me about 5 minutes to add a working .desktop file to a package. It would take me at least twice that time to log in and clear a bug report. That's wasteful.
Minor off topic gripe here. English has existed for way to long without the need for arrows in the language. I see *waaaaay* too many people talking <- like this recently
English has ALWAYS been an evolving language. <- And this is a good thing too, otherwise we would all sound like Chaucer ! Very best regards; -Bob Finch Liviu Librescu - În veci pomenirea lui. (May his memory be eternal.)
On Tue, May 13, 2008 at 5:49 AM, <w9ya@qrparci.net> wrote:
blah blah blah
I have one simple policy for you : "send your freaking desktop file upstream"
On Tue, May 13, 2008 at 5:49 AM, <w9ya@qrparci.net> wrote:
blah blah blah
I am thrilled you liked it so much !!
I have one simple policy for you : "send your freaking desktop file upstream"
As you already know; I have previously said I do just that. And thank you for simplifying your policy recommendation. Very best regards; Bob Finch
participants (9)
-
Aaron Griffin
-
Alessio Bolognino
-
bardo
-
Dimitrios Apostolou
-
Grigorios Bouzakis
-
Neil Darlow
-
Ryan Sims
-
w9ya＠qrparci.net
-
Xavier