I agree with what Graham suggests.<br>Good maintainers will follow the category list and try to figure out where to put their<br>packages and are still able to create a new one (eventually accepted or rejected) by<br>the community.<br>
Bad ones will be reported of their mistakes.<br><br>The AM could follow the official list and put the remaining "new" categories in an<br>"Extra Categories" subsection when displaying the categories to the user.<br>
<br>The list of non extras categories could a regular deb package that can be updated on the device<br>the usual way.<br><br>--<br>anidel<br><br><div class="gmail_quote">On Thu, Apr 17, 2008 at 2:52 PM, Graham Cobb <<a href="mailto:g%2B770@cobb.uk.net">g+770@cobb.uk.net</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Thursday 17 April 2008 12:33:26 Marius Vollmer wrote:<br>
> I am sure you notice the conflict here: whatever list you come up with<br>
> will be unsuitable for someone. You want strict policy enforcement,<br>
> based on community 'feelings'. How can that work?<br>
<br>
</div>I am strongly against strict enforcement. All that strict enforcement will<br>
achieve is (i) packages won't be put in extras, or (ii) packages will be put<br>
into an inappropriate category. Both these cures are much worse than the<br>
current category problem.<br>
<br>
There are two separate parts to the category problem. The first problem, and<br>
the easiest to fix, is packages that appear which should not appear at all.<br>
For example, the various GPE library packages used to do that by having<br>
sections such as user/lib (I believe I have fixed all those now, at least for<br>
chinook -- let me know if you find any more). These are just straight<br>
packaging bugs which need to be reported to the package maintainer.<br>
<br>
The second problem is the real problem: categories are random, overlapp or are<br>
just variant words for the same thing and are not translated. As someone<br>
suggested when this was last discussed, some months ago, I believe there<br>
should be a Wiki page which lists all the package names the community finds<br>
acceptable. That list should be editable by anyone who has upload rights and<br>
who thinks they need a new category. If the addition of the new category is<br>
disputed, it would be discussed here and the community would come to a<br>
consensus.<br>
<br>
If a package in extras has a category that is not on this list it should be<br>
reported as a packaging bug to the maintainer of the package. They should<br>
(eventually) either fix it or edit the Wiki page.<br>
<br>
The tools to upload packages and to promote packages from extras-devel to<br>
extras should highlight if the category is not on the list (providing a link<br>
to the list, of course), but should still allow the user to go ahead if they<br>
insist. Someone can even write a whole page on why category explosion is a<br>
bad thing if they like -- but don't prevent the upload.<br>
<br>
As part of this, I would also want Nokia to commit to the community that new<br>
software releases would include translations for all the package names in the<br>
Wiki page (at some data prior to the release, of course). That would be an<br>
added incentive for package maintainers to use the list.<br>
<br>
I guess this proposal arises from my view that people would be willing to use<br>
standard categories if it was (a) made easy, and (b) reduced some pain. But<br>
that there are many, many cases where a new category will be useful and we<br>
shouldn't be trying to fix the list. I think we should be giving this a<br>
try -- if it is being abused we can then look at adding enforcement or<br>
override.<br>
<font color="#888888"><br>
Graham<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
maemo-developers mailing list<br>
<a href="mailto:maemo-developers@maemo.org">maemo-developers@maemo.org</a><br>
<a href="https://lists.maemo.org/mailman/listinfo/maemo-developers" target="_blank">https://lists.maemo.org/mailman/listinfo/maemo-developers</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>anidel