[RFC] Maemo package guidelines: mandatory categories
Hi all, Here is my first suggestion to clean up the complete mess we have at the moment when it comes to package categories in the maemo extras repository. There is no official list of categories, which has brought us to state we are in now. We have these nice categories for example: 'Boingo', 'Canola'. Those should never be a category by themselves. We also have a lot of duplicates like 'cli' ,'Commandline' and 'Web','www' and 'Utilities','utils'. This really has to stop as this is confusing for end users. We, the maemo community, need to find a solution and fix this. If we look at Debian, we can see that they have the following list of categories[1]: admin, base, comm, contrib, devel, doc, editors, electronics, embedded, games, gnome, graphics, hamradio, interpreters, kde, libs, libdevel, mail, math, misc, net, news, non-free, oldlibs, otherosfs, perl, python, science, shells, sound, tex, text, utils, web, x11 My suggestion would be to base our list off the Debian list and remove the categories that are not suitable for Maemo. We might also want to add some categories if we find some missing. admin, comm, devel, doc, editors, games, graphics, interpreters, mail, net, news, utils and add: desktop, database, education, internet, multimedia, office, scientific, security, system, travel Please feel free to suggest other categories. Try to keep them as broad as possible. I would really like to get a list of categories where every application can be in at least one category. It would be nice not to need the 'misc' or 'other' category. Perhaps it would also be a good idea to have the Application Manager display the pretty name for each category. e.g. comm - Communication. That might be step 2 though. I also would like your feedback on this idea: For diablo we only accept packages in the extras/extras-devel repositories when they have a valid category. I'm really not sure if we can do this in time for diablo, but at least we can try to get the community to agree on this. I don't think we can do anything for existing repositories, but at least we could try for the new ones. Please respond with your ideas, but keep it to the category subject only. - Niels [1]Debian Sections: http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [RFC] Maemo package guidelines: mandatory categories
ext Niels Breet [EMAIL PROTECTED] writes: There is no official list of categories, which has brought us to state we are in now. There is, http://hildon-app-mgr.garage.maemo.org/packaging-stable.html: Ok, we need to get this in the official documentation. I don't think many developers will find it there! At least it is not listed here: http://maemo.org/development/documentation/how-tos/4-x/creating_a_debian_package.html [snip] user/accessoriesAccessories user/communication Communication user/games Games user/multimedia Multimedia user/office Office user/other Other user/programmingProgramming user/supportSupport user/themes Themes user/tools Tools Do we need more categories? I think this is not enough for all applications. in your control information. If you want to put it into Ringtones (which is not pre-defined), use Section: user/Ringtones I think this is bad. This is how we ended up with the mess we are in now. We need to come up with an official list and don't allow new categories to be created unless the community feels it is needed. - Niels ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [RFC] Maemo package guidelines: mandatory categories
ext Niels Breet [EMAIL PROTECTED] writes: There is no official list of categories, which has brought us to state we are in now. There is, http://hildon-app-mgr.garage.maemo.org/packaging-stable.html: Segments and Sections By default, the AM only shows packages in certain segments to the user. This has been done to hide the existence of the hundreds of system packages that make up the operating system itself. The AM is, at this point, not intended to let the user manage the whole system, only a smaller set of third party applications. The AM only shows packages in the user segment. Thus, your Section field in the control file should be of the form Section: user/SECTION where SECTION is arbitrary. SECTION should be a nice capitalised, English word like Ringtones. There is no support for localising that word yet, unfortunately. However, there is also a predefined set of sections. If your package fits into one of these sections, you should put it there. This will avoid fragmenting the section names, and the names of these sections will be correctly localised. The list of predefined sections and their English names is: user/accessoriesAccessories user/communication Communication user/games Games user/multimedia Multimedia user/office Office user/other Other user/programmingProgramming user/supportSupport user/themes Themes user/tools Tools Thus, if you want to put your package into the Office section, include the field Section: user/office in your control information. If you want to put it into Ringtones (which is not pre-defined), use Section: user/Ringtones ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: [RFC] Maemo package guidelines: mandatory categories
user/accessoriesAccessories user/communication Communication user/games Games user/multimedia Multimedia user/office Office user/other Other user/programmingProgramming user/supportSupport user/themes Themes user/tools Tools Do we need more categories? I think this is not enough for all applications. in your control information. If you want to put it into Ringtones (which is not pre-defined), use Section: user/Ringtones I think this is bad. This is how we ended up with the mess we are in now. Can the Debian system support multiple sub-categories? E.g. user/multimedia/Ringtones Would the package manager work with this? It seems like a cleaner way of separating out the packages to me. Or is there some limitation to the depth of the categories and/or way it's supposed/allowed to be used? Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [RFC] Maemo package guidelines: mandatory categories
ext Simon Pickering [EMAIL PROTECTED] writes: Can the Debian system support multiple sub-categories? E.g. user/multimedia/Ringtones That would be debtags, http://debtags.alioth.debian.org/ We have been talking about using debtags instead of the Section: user/FOO hack to control visibility, but my opinion right now is that we can not use the existing Debian tag vocabulary for expressing visibility (just as we can't use the existing list of sections of Debian), so it is 'only' a implementation detail whether to use the Section or the Tags field to control visibility. But of course, debtags are better in every regard than sections, so we should not ignore them in our plans. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [RFC] Maemo package guidelines: mandatory categories
On Thu, Apr 17, 2008 at 12:33 PM, Marius Vollmer [EMAIL PROTECTED] wrote: ext Niels Breet [EMAIL PROTECTED] writes: We need to come up with an official list and don't allow new categories to be created unless the community feels it is needed. I am sure you notice the conflict here: whatever list you come up with will be unsuitable for someone. You want strict policy enforcement, based on community 'feelings'. How can that work? Can it be any worse than the mess we're in now? Having said that, perhaps the MOTU-style proposal of gatekeepers doing QA checks could help here. Deviation is permitted, if it gets through a gatekeeper: http://lists.maemo.org/pipermail//maemo-developers/2008-January/013889.html One approach in a situation where consensus is clearly beneficial is to make a first shot at a concrete policy that everybody is supposed to follow, but make it possible to deviate from that policy in practice. That's what we've got now! There's a pre-defined list of categories and a note saying don't deviate from these if you don't want to. It's not worked. Apps from Nokia's own commercial partners, and high-visibility apps like Canola either think the guidelines don't apply to them; the guidelines don't cover the cases they have to support or aren't aware of them. That way, you end up with the people willing to put in the effort to be the ones who define the policy. Yeah, agreed. This goes back to the gatekeepers suggestion. For example, Pidgin might want a category of its own since it has many related packages that would otherwise be scattered all over the place. We could maybe improve the Application manager UI to make this a non-issue by grouping related packages in other ways (say, installing Pidgin gives a list with checkboxes where you can select additional components, based on the Recommends and Suggests fields of a package). Personally, I can only use All to find stuff, because of the bad categorisation; but this view is effectively spammed by large numbers of plugins for Canola, Pidgin, gcompris etc. Hierarchy is probably necessary here, with the Pidgin plugins being in Communications/Pidgin etc. Cheers, Andrew -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [RFC] Maemo package guidelines: mandatory categories
Niels Breet wrote: Hi all, Here is my first suggestion to clean up the complete mess we have at the moment when it comes to package categories in the maemo extras repository. There is no official list of categories, which has brought us to state we are in now. We have these nice categories for example: 'Boingo', 'Canola'. Those should never be a category by themselves. We also have a lot of duplicates like 'cli' ,'Commandline' and 'Web','www' and 'Utilities','utils'. I agree, but apparently many do not. You may remember I posted about this a few months ago: In addition to complaining I also filed dozens of bugs in various places. A few packages were fixed as a result (thanks to all the maintainers who did this), but during the same period many more broken packages appeared... The only visible result of my work: We now know that any guidelines on this category issue must be enforced, maintainers will not follow them otherwise. I would really hope the maintainers who oppose these category ideas step up now -- I know they exist since several of my bugs were marked as WONTFIX or just left unanswered. I've asked them to take their issues to this list, but this has not really happened AFAICT. An example reply from Canola bug database: * Eduardo Lima: This specific section was created with the idea in mind that we would have lots of plugins (not related to multimedia), themes and other packages such as i18n and we did not know how to label them. The application manager itself is flexible enough to let us create these specific sections so we did it. Eduardos concern about the hypothetical mass of packages is probably a real one but his solution (a category per application) makes the categories useless, IMO. I also would like your feedback on this idea: For diablo we only accept packages in the extras/extras-devel repositories when they have a valid category. Approve with comments: the i18n/plugin issue must be resolved, but I don't see it as show-stopper for diablo. Also, fixing categories probably cannot fix the underlying AM usability problem completely: debtags or something like it may well be needed additionally (I see Marius just commented on this): This should be taken into account when planning. Jussi -- Jussi Kukkonen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [RFC] Maemo package guidelines: mandatory categories
ext Andrew Flegg [EMAIL PROTECTED] writes: On Thu, Apr 17, 2008 at 12:33 PM, Marius Vollmer I am sure you notice the conflict here: whatever list you come up with will be unsuitable for someone. You want strict policy enforcement, based on community 'feelings'. How can that work? Can it be any worse than the mess we're in now? (Yes, I actually think it could be worse, but I think we agree on the important points, so let's not get distracted about this.) Having said that, perhaps the MOTU-style proposal of gatekeepers doing QA checks could help here. Deviation is permitted, if it gets through a gatekeeper: Yes, I agree. I was proposing this, in a more fine fashion: in addition to being able to say who goes in and who doesn't, the gatekeeper could also say: You go in but I am going to change your category to something sensible whether you want to or not. (I.e., the category of a package can be overwritten by the repository.) One approach in a situation where consensus is clearly beneficial is to make a first shot at a concrete policy that everybody is supposed to follow, but make it possible to deviate from that policy in practice. That's what we've got now! Yeah, but you cut the important part: At the same time, make it possible for people to improve policy compliance by doing concrete work (i.e., enable them to fix non-compliant things). The gatekeepers would be the ones fixing non-compliance (by rejecting violations, or by correcting them directly). ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [RFC] Maemo package guidelines: mandatory categories
On Thu, Apr 17, 2008 at 1:36 PM, Marius Vollmer [EMAIL PROTECTED] wrote: ext Andrew Flegg [EMAIL PROTECTED] writes: That's what we've got now! Yeah, but you cut the important part: At the same time, make it possible for people to improve policy compliance by doing concrete work (i.e., enable them to fix non-compliant things). The gatekeepers would be the ones fixing non-compliance (by rejecting violations, or by correcting them directly). I agree. Excellent, we've got the start of consensus :-) Cheers, Andrew -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [RFC] Maemo package guidelines: mandatory categories
On Thursday 17 April 2008 12:33:26 Marius Vollmer wrote: I am sure you notice the conflict here: whatever list you come up with will be unsuitable for someone. You want strict policy enforcement, based on community 'feelings'. How can that work? I am strongly against strict enforcement. All that strict enforcement will achieve is (i) packages won't be put in extras, or (ii) packages will be put into an inappropriate category. Both these cures are much worse than the current category problem. There are two separate parts to the category problem. The first problem, and the easiest to fix, is packages that appear which should not appear at all. For example, the various GPE library packages used to do that by having sections such as user/lib (I believe I have fixed all those now, at least for chinook -- let me know if you find any more). These are just straight packaging bugs which need to be reported to the package maintainer. The second problem is the real problem: categories are random, overlapp or are just variant words for the same thing and are not translated. As someone suggested when this was last discussed, some months ago, I believe there should be a Wiki page which lists all the package names the community finds acceptable. That list should be editable by anyone who has upload rights and who thinks they need a new category. If the addition of the new category is disputed, it would be discussed here and the community would come to a consensus. If a package in extras has a category that is not on this list it should be reported as a packaging bug to the maintainer of the package. They should (eventually) either fix it or edit the Wiki page. The tools to upload packages and to promote packages from extras-devel to extras should highlight if the category is not on the list (providing a link to the list, of course), but should still allow the user to go ahead if they insist. Someone can even write a whole page on why category explosion is a bad thing if they like -- but don't prevent the upload. As part of this, I would also want Nokia to commit to the community that new software releases would include translations for all the package names in the Wiki page (at some data prior to the release, of course). That would be an added incentive for package maintainers to use the list. I guess this proposal arises from my view that people would be willing to use standard categories if it was (a) made easy, and (b) reduced some pain. But that there are many, many cases where a new category will be useful and we shouldn't be trying to fix the list. I think we should be giving this a try -- if it is being abused we can then look at adding enforcement or override. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [RFC] Maemo package guidelines: mandatory categories
On Thursday 17 April 2008 13:33:31 Jussi Kukkonen wrote: I agree, but apparently many do not. You may remember I posted about this a few months ago: In addition to complaining I also filed dozens of bugs in various places. That was very useful, thanks. For GPE I fixed the packages appearing at the user level which should not be there. But I did not change the section (user/pim) for the ones which should be visible to users and have no plans to do so. If we had a scheme for changing the official list of categories (for example the Wiki page suggestion) I would submit pim -- and we could have a useful discussion on whether it should be pim, or PIM or whatever. But, in any case, it won't be one of the existing categories. A few packages were fixed as a result (thanks to all the maintainers who did this), but during the same period many more broken packages appeared... The only visible result of my work: We now know that any guidelines on this category issue must be enforced, maintainers will not follow them otherwise. I strongly disagree. Enforcement will just move us back into the problem that people don't put packages in extras and users can't find them, decreasing the success of the Maemo platform in the world. The right answer is a better GUI, probably with hierarchical categories, but that is not going to happen any time soon. I would really hope the maintainers who oppose these category ideas step up now -- I know they exist since several of my bugs were marked as WONTFIX or just left unanswered. I've asked them to take their issues to this list, but this has not really happened AFAICT. An example reply from Canola bug database: Although I do not think we want a category for *every* application I have some sympathy with Canola. I see no reason to ban categories for applications -- the criterion should just be whether they are helpful to the users. If a category for an application bundles up a lot of entries which would otherwise get in the way of people who don't use the application then I say great!. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [RFC] Maemo package guidelines: mandatory categories
On Thursday 17 April 2008 13:36:15 Marius Vollmer wrote: ext Andrew Flegg [EMAIL PROTECTED] writes: Having said that, perhaps the MOTU-style proposal of gatekeepers doing QA checks could help here. Deviation is permitted, if it gets through a gatekeeper: Yes, I agree. I was proposing this, in a more fine fashion: in addition to being able to say who goes in and who doesn't, the gatekeeper could also say: You go in but I am going to change your category to something sensible whether you want to or not. (I.e., the category of a package can be overwritten by the repository.) NO. NO. NO! No one gets to change my package! At least not without changing the version number, adding a changelog, changing the maintainer address and resubmitting it signed with their own key, not mine (essentially a NMU). If/when we ever get gatekeepers (which I suspect may still be a long time away) then having gatekeepers review the category, check it against the master list and either reject it or update the master list is fine. But all a gatekeeper can do is reject a package, not change it. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [RFC] Maemo package guidelines: mandatory categories
At Thu, 17 Apr 2008 13:52:07 +0100, Graham Cobb wrote: The second problem is the real problem: categories are random, overlapp or are just variant words for the same thing and are not translated. As someone suggested when this was last discussed, some months ago, I believe there should be a Wiki page which lists all the package names the community finds acceptable. That list should be editable by anyone who has upload rights and who thinks they need a new category. If the addition of the new category is disputed, it would be discussed here and the community would come to a consensus. This is an interesting idea and has made me think of the following: there could be a file that list the name of a category and synonyms for that category. The AM could download this file regularly (i.e., at update time) and sort applications according to the list of category names. This fixes all the problems that you noted except the translation problem. The translation problem could be fixed in that for each language, the category name is different but the synonyms are the same. But, I don't know anything about localization. Neal ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [RFC] Maemo package guidelines: mandatory categories
I agree with what Graham suggests. Good maintainers will follow the category list and try to figure out where to put their packages and are still able to create a new one (eventually accepted or rejected) by the community. Bad ones will be reported of their mistakes. The AM could follow the official list and put the remaining new categories in an Extra Categories subsection when displaying the categories to the user. The list of non extras categories could a regular deb package that can be updated on the device the usual way. -- anidel On Thu, Apr 17, 2008 at 2:52 PM, Graham Cobb [EMAIL PROTECTED][EMAIL PROTECTED] wrote: On Thursday 17 April 2008 12:33:26 Marius Vollmer wrote: I am sure you notice the conflict here: whatever list you come up with will be unsuitable for someone. You want strict policy enforcement, based on community 'feelings'. How can that work? I am strongly against strict enforcement. All that strict enforcement will achieve is (i) packages won't be put in extras, or (ii) packages will be put into an inappropriate category. Both these cures are much worse than the current category problem. There are two separate parts to the category problem. The first problem, and the easiest to fix, is packages that appear which should not appear at all. For example, the various GPE library packages used to do that by having sections such as user/lib (I believe I have fixed all those now, at least for chinook -- let me know if you find any more). These are just straight packaging bugs which need to be reported to the package maintainer. The second problem is the real problem: categories are random, overlapp or are just variant words for the same thing and are not translated. As someone suggested when this was last discussed, some months ago, I believe there should be a Wiki page which lists all the package names the community finds acceptable. That list should be editable by anyone who has upload rights and who thinks they need a new category. If the addition of the new category is disputed, it would be discussed here and the community would come to a consensus. If a package in extras has a category that is not on this list it should be reported as a packaging bug to the maintainer of the package. They should (eventually) either fix it or edit the Wiki page. The tools to upload packages and to promote packages from extras-devel to extras should highlight if the category is not on the list (providing a link to the list, of course), but should still allow the user to go ahead if they insist. Someone can even write a whole page on why category explosion is a bad thing if they like -- but don't prevent the upload. As part of this, I would also want Nokia to commit to the community that new software releases would include translations for all the package names in the Wiki page (at some data prior to the release, of course). That would be an added incentive for package maintainers to use the list. I guess this proposal arises from my view that people would be willing to use standard categories if it was (a) made easy, and (b) reduced some pain. But that there are many, many cases where a new category will be useful and we shouldn't be trying to fix the list. I think we should be giving this a try -- if it is being abused we can then look at adding enforcement or override. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- anidel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [RFC] Maemo package guidelines: mandatory categories
ext Graham Cobb [EMAIL PROTECTED] writes: On Thursday 17 April 2008 13:36:15 Marius Vollmer wrote: ext Andrew Flegg [EMAIL PROTECTED] writes: Having said that, perhaps the MOTU-style proposal of gatekeepers doing QA checks could help here. Deviation is permitted, if it gets through a gatekeeper: Yes, I agree. I was proposing this, in a more fine fashion: in addition to being able to say who goes in and who doesn't, the gatekeeper could also say: You go in but I am going to change your category to something sensible whether you want to or not. (I.e., the category of a package can be overwritten by the repository.) NO. NO. NO! No one gets to change my package! Don't worry, nobody is going to do that. :-) I was thinking about the normal Debian 'overrides' machinery. Only the repository indices would be affected; essentially, instead of taking the Section field for your package from your package when creating the Packages file for the repository, it is taken from a overrides file. This is OK, since it doesn't change the effect your package has when being installed. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [RFC] Maemo package guidelines: mandatory categories
ext Andrew Flegg [EMAIL PROTECTED] writes: The gatekeepers would be the ones fixing non-compliance (by rejecting violations, or by correcting them directly). I agree. Excellent, we've got the start of consensus :-) But we still need someone that is able/willing to actually execute things... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [RFC] Maemo package guidelines: mandatory categories
On Thursday 17 April 2008 14:46:04 Marius Vollmer wrote: ext Graham Cobb [EMAIL PROTECTED] writes: NO. NO. NO! No one gets to change my package! Don't worry, nobody is going to do that. :-) I was thinking about the normal Debian 'overrides' machinery. I realised that was the mechanism you were proposing and I still strongly disagree. I have no problem with the gatekeepers *offering* to override the category to save me the effort of rebuilding but if do not agree to the change the only option is to reject the package. Or for someone else to build, submit and maintain a different version of the package. If I submit a package, the community can take it or leave it. Or they can use GPL rights (if available) to build their own version. But they shouldn't change or misrepresent my version without my permission. That is an absolute requirement. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [RFC] Maemo package guidelines: mandatory categories
Yes! Yes! A thousand times, yes! -- Allen Brown http://brown.armoredpenguin.com/~abrown Hi all, Here is my first suggestion to clean up the complete mess we have at the moment when it comes to package categories in the maemo extras repository. There is no official list of categories, which has brought us to state we are in now. We have these nice categories for example: 'Boingo', 'Canola'. Those should never be a category by themselves. We also have a lot of duplicates like 'cli' ,'Commandline' and 'Web','www' and 'Utilities','utils'. This really has to stop as this is confusing for end users. We, the maemo community, need to find a solution and fix this. If we look at Debian, we can see that they have the following list of categories[1]: admin, base, comm, contrib, devel, doc, editors, electronics, embedded, games, gnome, graphics, hamradio, interpreters, kde, libs, libdevel, mail, math, misc, net, news, non-free, oldlibs, otherosfs, perl, python, science, shells, sound, tex, text, utils, web, x11 My suggestion would be to base our list off the Debian list and remove the categories that are not suitable for Maemo. We might also want to add some categories if we find some missing. admin, comm, devel, doc, editors, games, graphics, interpreters, mail, net, news, utils and add: desktop, database, education, internet, multimedia, office, scientific, security, system, travel Please feel free to suggest other categories. Try to keep them as broad as possible. I would really like to get a list of categories where every application can be in at least one category. It would be nice not to need the 'misc' or 'other' category. Perhaps it would also be a good idea to have the Application Manager display the pretty name for each category. e.g. comm - Communication. That might be step 2 though. I also would like your feedback on this idea: For diablo we only accept packages in the extras/extras-devel repositories when they have a valid category. I'm really not sure if we can do this in time for diablo, but at least we can try to get the community to agree on this. I don't think we can do anything for existing repositories, but at least we could try for the new ones. Please respond with your ideas, but keep it to the category subject only. - Niels [1]Debian Sections: http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
