perfsonar development work

[Gijs Molenaar <>]

Roman Lapacz wrote:
> Nicolas Simar wrote:
>> In Zagreb, Loukik reached an agreement for naming the services
>> ps-mdm-.... Then as you know he left with the reasoning.
>>   
>
> Could you point me to the minutes of the session when this agreement
> was reached (who was involved in the discussion on this). I don't
> remember such agreement.
>
>> It came back few months later, but at this time, there was no valid
>> points in favor of it or not. Thus the current situation.
>>
>> But having seen how the installer work,
>> - search for packages
>> - consistency, you have the same naming convention, so you don't have to
>> remember if it is a geant2 or ps-mdm or a development from a NREN.
If, in the case of packaging, the description of the package is good
(for example 'perfsonar' is in it) you can search for all perfsonar
packages with 'yum search perfsonar' or 'apt-cache search perfsonar'.
>>   
>
> I believe the current naming convention
> (PROJECT/INSTITUTION_NAME-IMPL_LENG-SERVICE_TYPE) is more open,
> descriptive and flexible. Service developers/maintainers, please,
> provide your opinions.

This name is overly complex, since the user of the software doesn't care
about these details during installation. Other software doesn't have the
implementation language in it name or institution in it also. I think a
short unique name for every service prefixed by a common (short) name is
the best. Any special notes should be in the description of the package,
in a README or/and in the manual. A Copyright file or a big fat logo on
the website is the common place for getting credits for the effort.

But the ps-mdm-  is also too cryptic in my opinion. As an end user
ps-mdm wouldn't say me anything.  The perfsonar- prefix just is perfect,
but Loukik had some problems with that since then there can be name
collisions. So if you want to change it to ps-mdm I would say please
wait untill people come up with an better idea for a naming schema.

But anyhow, I think for the next perfsonar release there should be one
(or more) person responsible for the packaging and not bother the
developers with this kind of details. This way this kind of descisions
can be speed up and the packager man is responsible for the
integrity/consistency of the packages. Letting everyone descide, vote
and rebuild their packages this way takes _ages_ and can be a couple of
days work if centralized.

 - gijs

Attachment: signature.asc
Description: OpenPGP digital signature