Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Maemo: Developers

[RFC] Maemo package guidelines: mandatory categories

 

 

Maemo developers RSS feed   Index | Next | Previous | View Threaded


maemo at breet

Apr 17, 2008, 2:41 AM

Post #1 of 22 (5472 views)
Permalink
[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 [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


marius.vollmer at nokia

Apr 17, 2008, 3:32 AM

Post #2 of 22 (5428 views)
Permalink
Re: [RFC] Maemo package guidelines: mandatory categories [In reply to]

"ext Niels Breet" <maemo [at] breet> 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/accessories Accessories
user/communication Communication
user/games Games
user/multimedia Multimedia
user/office Office
user/other Other
user/programming Programming
user/support Support
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 [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


maemo at breet

Apr 17, 2008, 3:46 AM

Post #3 of 22 (5421 views)
Permalink
Re: [RFC] Maemo package guidelines: mandatory categories [In reply to]

> "ext Niels Breet" <maemo [at] breet> 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/accessories Accessories
> user/communication Communication
> user/games Games
> user/multimedia Multimedia
> user/office Office
> user/other Other
> user/programming Programming
> user/support Support
> 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 [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


S.G.Pickering at bath

Apr 17, 2008, 3:56 AM

Post #4 of 22 (5422 views)
Permalink
RE: [RFC] Maemo package guidelines: mandatory categories [In reply to]

> > user/accessories Accessories
> > user/communication Communication
> > user/games Games
> > user/multimedia Multimedia
> > user/office Office
> > user/other Other
> > user/programming Programming
> > user/support Support
> > 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 [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


marius.vollmer at nokia

Apr 17, 2008, 4:33 AM

Post #5 of 22 (5405 views)
Permalink
Re: [RFC] Maemo package guidelines: mandatory categories [In reply to]

"ext Niels Breet" <maemo [at] breet> writes:

>> 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!

True. I just quoted that document because I knew where it was.

>At least it is not listed here:
> http://maemo.org/development/documentation/how-tos/4-x/creating_a_debian_package.html

It's here as well:

http://maemo.org/development/documentation/how-tos/4-x/making_application_packages.html

>> [concrete list of categories]
>
> Do we need more categories? I think this is not enough for all
> applications.
>
>> [how to use categories that are not in the list]
>
> 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.

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?


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.
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).

That way, you end up with the people willing to put in the effort to be
the ones who define the policy.


In this concrete case, it would mean to give to whoever wants it the
ability to centrally override the categories used by the packages in the
maemo Extras repositories, and maybe also the ability to block entry
into these repositories based on the categories they use.


There is more to this, of course, like pushing people more to actually
use maemo Extras for their packages in the first place, and reducing the
need for new categories. 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). Fixing the Application manager to get
category translations from the repositories, say. Controlling the whole
application browsing experience from the repository server, by pushing
some HTML/CSS/etc to the Application manager that just shows it using a
web runtime. Using PackageKit. Etc.

Lot's of room for improvement...
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


marius.vollmer at nokia

Apr 17, 2008, 5:05 AM

Post #6 of 22 (5424 views)
Permalink
Re: [RFC] Maemo package guidelines: mandatory categories [In reply to]

"ext Simon Pickering" <S.G.Pickering [at] bath> 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 [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


andrew at bleb

Apr 17, 2008, 5:21 AM

Post #7 of 22 (5415 views)
Permalink
Re: [RFC] Maemo package guidelines: mandatory categories [In reply to]

On Thu, Apr 17, 2008 at 12:33 PM, Marius Vollmer
<marius.vollmer [at] nokia> wrote:
> "ext Niels Breet" <maemo [at] breet> 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:andrew [at] bleb | http://www.bleb.org/
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


jhkukkon at cc

Apr 17, 2008, 5:33 AM

Post #8 of 22 (5411 views)
Permalink
Re: [RFC] Maemo package guidelines: mandatory categories [In reply to]

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 [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


marius.vollmer at nokia

Apr 17, 2008, 5:36 AM

Post #9 of 22 (5430 views)
Permalink
Re: [RFC] Maemo package guidelines: mandatory categories [In reply to]

"ext Andrew Flegg" <andrew [at] bleb> 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 [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


andrew at bleb

Apr 17, 2008, 5:42 AM

Post #10 of 22 (5425 views)
Permalink
Re: [RFC] Maemo package guidelines: mandatory categories [In reply to]

On Thu, Apr 17, 2008 at 1:36 PM, Marius Vollmer
<marius.vollmer [at] nokia> wrote:
> "ext Andrew Flegg" <andrew [at] bleb> 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:andrew [at] bleb | http://www.bleb.org/
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


g+770 at cobb

Apr 17, 2008, 5:52 AM

Post #11 of 22 (5431 views)
Permalink
Re: [RFC] Maemo package guidelines: mandatory categories [In reply to]

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 [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


g+770 at cobb

Apr 17, 2008, 6:12 AM

Post #12 of 22 (5428 views)
Permalink
Re: [RFC] Maemo package guidelines: mandatory categories [In reply to]

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 [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


g+770 at cobb

Apr 17, 2008, 6:23 AM

Post #13 of 22 (5403 views)
Permalink
Re: [RFC] Maemo package guidelines: mandatory categories [In reply to]

On Thursday 17 April 2008 13:36:15 Marius Vollmer wrote:
> "ext Andrew Flegg" <andrew [at] bleb> 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 [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


neal at walfield

Apr 17, 2008, 6:25 AM

Post #14 of 22 (5419 views)
Permalink
Re: [RFC] Maemo package guidelines: mandatory categories [In reply to]

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 [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


anidel at gmail

Apr 17, 2008, 6:31 AM

Post #15 of 22 (5410 views)
Permalink
Re: [RFC] Maemo package guidelines: mandatory categories [In reply to]

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
<g+770 [at] cobb<g%2B770 [at] cobb>>
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 [at] maemo
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>



--
anidel


marius.vollmer at nokia

Apr 17, 2008, 6:46 AM

Post #16 of 22 (5445 views)
Permalink
Re: [RFC] Maemo package guidelines: mandatory categories [In reply to]

"ext Graham Cobb" <g+770 [at] cobb> writes:

> On Thursday 17 April 2008 13:36:15 Marius Vollmer wrote:
>> "ext Andrew Flegg" <andrew [at] bleb> 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 [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


marius.vollmer at nokia

Apr 17, 2008, 6:48 AM

Post #17 of 22 (5437 views)
Permalink
Re: [RFC] Maemo package guidelines: mandatory categories [In reply to]

"ext Andrew Flegg" <andrew [at] bleb> 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 [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


g+770 at cobb

Apr 17, 2008, 8:56 AM

Post #18 of 22 (5387 views)
Permalink
Re: [RFC] Maemo package guidelines: mandatory categories [In reply to]

On Thursday 17 April 2008 14:46:04 Marius Vollmer wrote:
> "ext Graham Cobb" <g+770 [at] cobb> 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 [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


kees.jongenburger at gmail

Apr 17, 2008, 9:35 AM

Post #19 of 22 (5413 views)
Permalink
Re: [RFC] Maemo package guidelines: mandatory categories [In reply to]

On Thu, Apr 17, 2008 at 1:33 PM, Marius Vollmer
<marius.vollmer [at] nokia> 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 guess we are talking about the package manager right?
on the cli and on the website it is all different and we do not depend
on the Sections field

I would like a search option in the package manager. that would make
me agnostic to the importent result of this disc
I do get very furstrated when I use something else then the "all" button

greetings
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


abrown at peak

Apr 17, 2008, 10:19 AM

Post #20 of 22 (5398 views)
Permalink
Re: [RFC] Maemo package guidelines: mandatory categories [In reply to]

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 [at] maemo
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>


_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


maemo at breet

Apr 17, 2008, 10:42 AM

Post #21 of 22 (5441 views)
Permalink
Re: [RFC] Maemo package guidelines: mandatory categories [In reply to]

> 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.

I'm all for the gentle help instead of enforce and scare away. We have to
keep in mind that most developers want their packages in the hand of
users. I hope that the current situation is caused by not knowing what is
'right' and not their evil plan to mess up the repositories.

>
> 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.
>

I think this is what we can use the policy for. We can always create a
newer version if there are changes. Perhaps the only thing we need to
enforce is that there is a known email address from the maintainer of a
package. Again, I think most would be willing to fix any problems.

Another problem is that developers now only have top-level categories to
use, so the really don't have any options. If we can do grouping or sub
categories, their problem would be solved.

>
> 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.
>

Maybe we can add two modes, a strict one and a one that only warns the
developer. The uploader can pick which mode he/she likes?

> 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.

We can even make that a community project :) I'm sure we can arrange
something to translate these categories.

> 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.
>

Agreed.

> Graham

- Niels


_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


maemo at breet

Apr 17, 2008, 11:04 AM

Post #22 of 22 (5388 views)
Permalink
Re: [RFC] Maemo package guidelines: mandatory categories [In reply to]

-- to the list too this time..
>
>> At least it is not listed here:
>> http://maemo.org/development/documentation/how-tos/4-x/creating_a_debian
>> _package.html
>>
>
> It's here as well:
>
>
> http://maemo.org/development/documentation/how-tos/4-x/making_application
> _packages.html
>

I stand corrected. We might want to cross link between them?

> 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?
>

You are right in that there will always be a category which is not
suitable for your specific application. But we can at least try to get it
better than what we have now. Most of the applications available are
created by the community, they should have a say in this. This really
isn't a task that needs to be done by Nokia alone.

>
> 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. 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).
>

I think we can try to work towards policy. Let's start with a wiki page
and see if we can create some list. We can create a policy and see how it
works in practice. After a while we can evaluate it and see if we can
better it.

> That way, you end up with the people willing to put in the effort to be
> the ones who define the policy.

I think that is a good idea.
>
> In this concrete case, it would mean to give to whoever wants it the
> ability to centrally override the categories used by the packages in the
> maemo Extras repositories, and maybe also the ability to block entry into
> these repositories based on the categories they use.
>
>
> There is more to this, of course, like pushing people more to actually
> use maemo Extras for their packages in the first place, and reducing the
> need for new categories.

This is another project we are working on, more on that soon.

> 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).

This would be an elegant solution, although we would need to see if we can
make that finger friendly too :)

- Niels



_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers

Maemo developers RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.