Re: [Mageia-dev] RPM groups policy

2012-09-27 Thread Barry Jackson

On 27/09/12 11:07, Pierre-Malo Deniélou wrote:

Le 27/09/12 10:51,Pascal Terjan nous adresse ces quelques mots :

On Thu, Sep 27, 2012 at 10:48 AM, Pierre-Malo Deniélou

For PulseAudio, Sound/Mixer is fine.


I don't agree
If someone wants to install a mixer, pulesaudio in the list will
probably confuse him


As I was saying earlier, no group classification is perfect. In the
situation you describe, having pulseaudio in System/Base would be even
more confusing. But if you were to choose between Sound/Editors and
Convertors, Sound/Midi, Sound/Mixers, Sound/Players, Sound/Utilities,
Sound/Visualization, where would you look first?

You know none fits perfectly, I know that as well, even less for
pulseaudio-module-jack or pulseaudio-module-bluetooth.

But before everyting was in Sound: so confusing is maximum. Now it
becomes a bit (but only a bit) easier. That's the point.


Or perhaps PA should just go in System/Base?


No. It only drowns it in the crowd of completely unrelated packages.


Do you expect someone to want to manually install pulseaudio after
removing it, and search it in mixers?


Yes. By the principle of "Where else?" :-)

Cheers,

Can it not stay in the top level "Sound" or does everything *have* to be 
in a sub group?


Re: [Mageia-dev] RPM groups policy

2012-09-27 Thread Pierre-Malo Deniélou
Le 27/09/12 10:51,Pascal Terjan nous adresse ces quelques mots :
> On Thu, Sep 27, 2012 at 10:48 AM, Pierre-Malo Deniélou
>> For PulseAudio, Sound/Mixer is fine.
> 
> I don't agree
> If someone wants to install a mixer, pulesaudio in the list will
> probably confuse him

As I was saying earlier, no group classification is perfect. In the
situation you describe, having pulseaudio in System/Base would be even
more confusing. But if you were to choose between Sound/Editors and
Convertors, Sound/Midi, Sound/Mixers, Sound/Players, Sound/Utilities,
Sound/Visualization, where would you look first?

You know none fits perfectly, I know that as well, even less for
pulseaudio-module-jack or pulseaudio-module-bluetooth.

But before everyting was in Sound: so confusing is maximum. Now it
becomes a bit (but only a bit) easier. That's the point.

>>> Or perhaps PA should just go in System/Base?
>>
>> No. It only drowns it in the crowd of completely unrelated packages.
> 
> Do you expect someone to want to manually install pulseaudio after
> removing it, and search it in mixers?

Yes. By the principle of "Where else?" :-)

Cheers,
-- 
Malo



Re: [Mageia-dev] RPM groups policy

2012-09-27 Thread Pascal Terjan
On Thu, Sep 27, 2012 at 10:48 AM, Pierre-Malo Deniélou
 wrote:
> Le 27/09/12 10:04,Colin Guthrie nous adresse ces quelques mots :
>> Just ran into my first practical problem and would like your feedback.
>
> I'm guessing your email is just the first of a long list :-).
> The new RPM group will indeed cause some head scratching for many packages.
>
>> PulseAudio packages used to just be in "Sound" group, but now I have to
>> sub-categorise them as Sound/*. This is fine and I put everything in the
>> Sound/Mixer category for now as this is one of the tasks PA does, mix
>> your audio, but I get the feeling this group was more designed to
>> represent graphical mixer UIs rather than infrastructure level stuff.
>
> RPM groups are for users, not necessarily technical users (technical
> users already know which packages interest them).
> So the main advice to find the category of a given package is:
>
> Where would it make sense for a user browsing through a list to find it?
>
> For PulseAudio, Sound/Mixer is fine.

I don't agree
If someone wants to install a mixer, pulesaudio in the list will
probably confuse him

>> Or perhaps PA should just go in System/Base?
>
> No. It only drowns it in the crowd of completely unrelated packages.

Do you expect someone to want to manually install pulseaudio after
removing it, and search it in mixers?


Re: [Mageia-dev] RPM groups policy

2012-09-27 Thread Pierre-Malo Deniélou
Le 27/09/12 10:04,Colin Guthrie nous adresse ces quelques mots :
> Just ran into my first practical problem and would like your feedback.

I'm guessing your email is just the first of a long list :-).
The new RPM group will indeed cause some head scratching for many packages.

> PulseAudio packages used to just be in "Sound" group, but now I have to
> sub-categorise them as Sound/*. This is fine and I put everything in the
> Sound/Mixer category for now as this is one of the tasks PA does, mix
> your audio, but I get the feeling this group was more designed to
> represent graphical mixer UIs rather than infrastructure level stuff.

RPM groups are for users, not necessarily technical users (technical
users already know which packages interest them).
So the main advice to find the category of a given package is:

Where would it make sense for a user browsing through a list to find it?

For PulseAudio, Sound/Mixer is fine.

> Should there be a group that represents this better? e.g.
> 
> Sound/Plumbing
> System/Sound
> Plumbing/Sound

Or Sound/PulseAudio ... :-P

That's the Suse approach, but it does not work. It only multiplies the
groups, with 3 or 4 subdivision depths (Amusements/Games/Strategy/Turn
Based ...), with some groups only having a handful of packages. Many of
the subdivisions make sense from a packaging point of view, but from a
user point of view it makes browsing too precise. I personally think
that groups are meant for the exploration by people who don't know what
they are looking for.

> Or perhaps PA should just go in System/Base?

No. It only drowns it in the crowd of completely unrelated packages.

> (I use the term Plumbing as this is quite common these days as an off
> shoot perhaps from the Linux Plumbers Conference where the various
> infrastructural bits of linux are discussed).
> 
> Thoughts?

No RPM group classification is perfect. There will always be a package
that does not fit the classification. So we should stick to the "best
guess" strategy for now.

The new RPM group policy is not completely fixed, but I propose that
everyone tries to stick with it until Beta 1, at which point we can
review it and amend the most obvious problems.

Cheers,
-- 
Malo


Re: [Mageia-dev] RPM groups policy

2012-09-27 Thread Colin Guthrie
'Twas brillig, and Pierre-Malo Deniélou at 25/09/12 23:43 did gyre and
gimble:
> Dear packagers,
> 
> Tonight, following the packagers meeting, we agreed on a new RPM group
> policy.
> 
> The current policy is described at:
> http://wiki.mageia.org/en/RPM_groups_policy
> 
> The new policy is presented at:
> http://wiki.mageia.org/en/Feature:RPMGroupRevamp
> 
> This change in policy means that I will take the following actions by
> the end of the week:
>   * update the wikipage http://wiki.mageia.org/en/RPM_groups_policy
>   * patch rpmlint to refuse new packages that do not follow the new
> policy (I will send another email to -dev just before submitting
> the new rpmlint).
>   * create a bug report tracking the packages that need to change group.
>   * mail -dev about the packages that are currently in wrong groups
> (even with respect to the current policy) so that their maintainers
> can take proper action within 2 weeks. After that, I will change
> the groups myself
>   * mail -dev about the packages that are correct with respect to
> current policy but need to be updated to respect the new policy.
> For these packages, the deadline will be beta1 (12/12) to complete
> the changes, which means that I will start doing the moves by
> myself by Alpha 3 (06/11).
> 
> I will mail -dev at each step on the way, so don't worry too much now.
> 
> I hope the new RPM groups will make it easier for everyone to find
> packages in rpmdrake and other tools. It will be a bit annoying for
> every packager, but it's a good opportunity to revisit many package
> specs before mga3 and make Mageia better.


Just ran into my first practical problem and would like your feedback.

PulseAudio packages used to just be in "Sound" group, but now I have to
sub-categorise them as Sound/*. This is fine and I put everything in the
Sound/Mixer category for now as this is one of the tasks PA does, mix
your audio, but I get the feeling this group was more designed to
represent graphical mixer UIs rather than infrastructure level stuff.


Should there be a group that represents this better? e.g.

Sound/Plumbing
System/Sound
Plumbing/Sound

Or perhaps PA should just go in System/Base?

(I use the term Plumbing as this is quite common these days as an off
shoot perhaps from the Linux Plumbers Conference where the various
infrastructural bits of linux are discussed).

Thoughts?

Col

-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/


Re: [Mageia-dev] RPM groups policy

2012-09-26 Thread Pierre-Malo Deniélou
Le 26/09/12 22:58,Charles A Edwards nous adresse ces quelques mots :
> On Thu, 27 Sep 2012 00:42:58 +0300
> Anssi Hannula wrote:
> 
>>> Yes, but you will now be creating entries that Are Not 
>>> registered categories   
>>
>> RPM groups are not related to menu categories in any way.
> 
> 
> I know the the rpm group is different.
> 
> Are you  saying that No packager will try to create or change 
> a menu entry to reflect the new rpm groups?

Exactly.

> Example:
> 'Alien arena' in Games/Shooter instead of Games/Other

The RPM group of Alien arena will change to Games/Shooter, but its
desktop file is not supposed to change.

I understand your point, but there will always be mismatches between the
two categories, since the two purposes are different.

-- 
Malo



Re: [Mageia-dev] RPM groups policy

2012-09-26 Thread Charles A Edwards
On Thu, 27 Sep 2012 00:42:58 +0300
Anssi Hannula wrote:

> > Yes, but you will now be creating entries that Are Not 
> > registered categories   
> 
> RPM groups are not related to menu categories in any way.


I know the the rpm group is different.

Are you  saying that No packager will try to create or change 
a menu entry to reflect the new rpm groups?

Example:
'Alien arena' in Games/Shooter instead of Games/Other


Charles


-- 
Gathering threads always break in the middle
-- Murphy's Laws of Sewing n°18
--
Mageia release 3 (Cauldron) for x86_64$
On SuperSizehttp://www.eslrahc.com
Registered Linux user #182463
3.5.4-tmb-server-1.mga3 x86_64
--


signature.asc
Description: PGP signature


Re: [Mageia-dev] RPM groups policy

2012-09-26 Thread Pierre-Malo Deniélou
Le 26/09/12 22:42,Anssi Hannula nous adresse ces quelques mots :
> 27.09.2012 00:27, Charles A Edwards kirjoitti:
>> On Wed, 26 Sep 2012 22:17:29 +0100
>> Pierre-Malo Deniélou wrote:
>>
> The current policy is described at:
> http://wiki.mageia.org/en/RPM_groups_policy
>
> The new policy is presented at:
> http://wiki.mageia.org/en/Feature:RPMGroupRevamp  


 What about xdg menu compliance?  
>>>
>>> There is already a policy in place, and automated checks that enforce
>>> it. Everyone seems happy with it, so it does not change :-).
>>
>> Yes, but you will now be creating entries that Are Not 
>> registered categories 
> 
> RPM groups are not related to menu categories in any way.

The RPM groups are seen only in rpmdrake (and smart and Mageia App Db),
as far as I understand. And they are package-based.

.desktop files (which are for menu entries) are for the desktop
applications. So one package can have several .desktop files (for each
application it contains) or none.

They are in effect unrelated. There was however a proposal to base the
new RPM groups on the freedektop standard for menu classification, but
it seems not to be a possibility (mainly because packages <> applications).

Cheers,
-- 
Malo


Re: [Mageia-dev] RPM groups policy

2012-09-26 Thread Johnny A. Solbu
On Wednesday 26 September 2012 23:27, Charles A Edwards wrote:
> Yes, but you will now be creating entries that Are Not 
> registered categories 
> 
> http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html#category-registry

Perhaps I'm slow, but I thought there was a difference between RPM groups and 
desktop menu groups.
So this shouldn't be an issiue.

-- 
Johnny A. Solbu
PGP key ID: 0xFA687324


signature.asc
Description: This is a digitally signed message part.


Re: [Mageia-dev] RPM groups policy

2012-09-26 Thread Anssi Hannula
27.09.2012 00:27, Charles A Edwards kirjoitti:
> On Wed, 26 Sep 2012 22:17:29 +0100
> Pierre-Malo Deniélou wrote:
> 
 The current policy is described at:
 http://wiki.mageia.org/en/RPM_groups_policy

 The new policy is presented at:
 http://wiki.mageia.org/en/Feature:RPMGroupRevamp  
>>>
>>>
>>> What about xdg menu compliance?  
>>
>> There is already a policy in place, and automated checks that enforce
>> it. Everyone seems happy with it, so it does not change :-).
> 
> Yes, but you will now be creating entries that Are Not 
> registered categories 

RPM groups are not related to menu categories in any way.

-- 
Anssi Hannula


Re: [Mageia-dev] RPM groups policy

2012-09-26 Thread Charles A Edwards
On Wed, 26 Sep 2012 22:17:29 +0100
Pierre-Malo Deniélou wrote:

> >> The current policy is described at:
> >> http://wiki.mageia.org/en/RPM_groups_policy
> >>
> >> The new policy is presented at:
> >> http://wiki.mageia.org/en/Feature:RPMGroupRevamp  
> > 
> > 
> > What about xdg menu compliance?  
> 
> There is already a policy in place, and automated checks that enforce
> it. Everyone seems happy with it, so it does not change :-).

Yes, but you will now be creating entries that Are Not 
registered categories 

http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html#category-registry



Charles

-- 
I have no doubt that it is a part of the destiny of the human race, 
in its gradual improvement, to leave off eating animals.
-- Thoreau
--
Mageia release 3 (Cauldron) for x86_64$
On SuperSizehttp://www.eslrahc.com
Registered Linux user #182463
3.5.4-tmb-server-1.mga3 x86_64
--


signature.asc
Description: PGP signature


Re: [Mageia-dev] RPM groups policy

2012-09-26 Thread Pierre-Malo Deniélou
Le 26/09/12 22:09,Charles A Edwards nous adresse ces quelques mots :
> On Tue, 25 Sep 2012 23:43:50 +0100
> Pierre-Malo Deniélou wrote:
> 
>> Tonight, following the packagers meeting, we agreed on a new RPM group
>> policy.
>>
>> The current policy is described at:
>> http://wiki.mageia.org/en/RPM_groups_policy
>>
>> The new policy is presented at:
>> http://wiki.mageia.org/en/Feature:RPMGroupRevamp
> 
> 
> What about xdg menu compliance?

There is already a policy in place, and automated checks that enforce
it. Everyone seems happy with it, so it does not change :-).

https://wiki.mageia.org/en/Packaging_guidelines#Desktop_files

However, if you feel that some packages are in the wrong menu category,
it's a bug that you should report.

Cheers,
-- 
Malo


Re: [Mageia-dev] RPM groups policy

2012-09-26 Thread Charles A Edwards
On Tue, 25 Sep 2012 23:43:50 +0100
Pierre-Malo Deniélou wrote:

> Tonight, following the packagers meeting, we agreed on a new RPM group
> policy.
> 
> The current policy is described at:
> http://wiki.mageia.org/en/RPM_groups_policy
> 
> The new policy is presented at:
> http://wiki.mageia.org/en/Feature:RPMGroupRevamp


What about xdg menu compliance?


Charles 

-- 
Yow!  I want to mail a bronzed artichoke to Nicaragua!
--
Mageia release 3 (Cauldron) for x86_64$
On SuperSizehttp://www.eslrahc.com
Registered Linux user #182463
3.5.4-tmb-server-1.mga3 x86_64
--


signature.asc
Description: PGP signature


Re: [Mageia-dev] RPM groups policy

2012-09-26 Thread nicolas vigier
On Tue, 25 Sep 2012, Pierre-Malo Deniélou wrote:

> Dear packagers,
> 
> Tonight, following the packagers meeting, we agreed on a new RPM group
> policy.
> 
> The current policy is described at:
> http://wiki.mageia.org/en/RPM_groups_policy
> 
> The new policy is presented at:
> http://wiki.mageia.org/en/Feature:RPMGroupRevamp
> 
> This change in policy means that I will take the following actions by
> the end of the week:
>   * update the wikipage http://wiki.mageia.org/en/RPM_groups_policy
>   * patch rpmlint to refuse new packages that do not follow the new
> policy (I will send another email to -dev just before submitting
> the new rpmlint).

On build system, we also need to update youri to use the old rpmlint
config for already released distributions.



[Mageia-dev] RPM groups policy

2012-09-25 Thread Pierre-Malo Deniélou
Dear packagers,

Tonight, following the packagers meeting, we agreed on a new RPM group
policy.

The current policy is described at:
http://wiki.mageia.org/en/RPM_groups_policy

The new policy is presented at:
http://wiki.mageia.org/en/Feature:RPMGroupRevamp

This change in policy means that I will take the following actions by
the end of the week:
  * update the wikipage http://wiki.mageia.org/en/RPM_groups_policy
  * patch rpmlint to refuse new packages that do not follow the new
policy (I will send another email to -dev just before submitting
the new rpmlint).
  * create a bug report tracking the packages that need to change group.
  * mail -dev about the packages that are currently in wrong groups
(even with respect to the current policy) so that their maintainers
can take proper action within 2 weeks. After that, I will change
the groups myself
  * mail -dev about the packages that are correct with respect to
current policy but need to be updated to respect the new policy.
For these packages, the deadline will be beta1 (12/12) to complete
the changes, which means that I will start doing the moves by
myself by Alpha 3 (06/11).

I will mail -dev at each step on the way, so don't worry too much now.

I hope the new RPM groups will make it easier for everyone to find
packages in rpmdrake and other tools. It will be a bit annoying for
every packager, but it's a good opportunity to revisit many package
specs before mga3 and make Mageia better.

Cheers,
-- 
Malo