[development] Confused: package value of info files

[Dries Buytaert]

On 21 Dec 2006, at 15:49, Gary Feldman wrote:
>> If you have been assigned a package string for your module it will  
>> be listed with other modules containing the same string value on  
>> the admin/build/modules page.  If you have not been assigned a  
>> package string for your module then this value must remain  
>> unspecified it will be listed in the Other grouping on the admin/ 
>> build/modules page.

> How about something even stronger, at least for the short term:
>
>    package = "Your package name, if any"
>
>    A package is a group of modules designed to work together.  Two big
>    examples are E-commerce and Organic Groups.  If you use this, the
>    maintainers of the group must agree to use the same string.  They
>    should agree to document all dependencies and incompatibilities
>    within the group.  The overwhelming majority of modules will not  
> use
>    this field.

(I agree with Earnie's points and was also the reason why I didn't  
wanted to commit the package patch in first place.  Peer pressure  
driven by release candidate frenzy/frustration, make me commit it  
anyway.)

This kind of documentation is a bit of a "hack".  I'm a firm believer  
of 'fixing the root of the confusion', rather than 'documenting the  
confusion'.  Most people, including myself, don't care to read the  
small print before setting a silly field.  We just copy-paste the  
field from another .info file and follow our intuition.  We're  
cowboys like that.  ;-)

So the question becomes: can we make this more intuitive?  Can we  
improve the default behavior?  Can we make this work for copy-pasters  
like me?  Can we optimize the UI to deal with a multitude of package  
names?  (Make the package names less prominent, but still sort  
modules by package name.)  Can we ignore unique package names in the  
UI?  (Only group modules by package if there are more than two  
modules in a given package.)

If we can fix this in the code, I'd prefer to fix it in the code  
regardless of the RC status.  If we can't fix it in the code, we need  
a policy.  Personally, I'm not a fan of rules (especially not of  
rules that state you need agreement first) because slowly but  
certainly, they turn things into a bureaucracy.

So, I'm OK with the proposed documentation but I'd remove the "you  
need agreement" clause.  Oh, and if someone comes up with a good  
patch, chances are I'll commit that.

--
Dries Buytaert  ::  http://www.buytaert.net/