[development] Confused: package value of info files

[Earnie Boyd]

Quoting Steven Peck <speck at blkmtn.org>:

>
> What?  This is set to help end user experience.  One end users needs are
> not another's.  Too many discrete groupings only serve to confuse and
> dilute the usefulness of the feature.  In any given install there are
> very very few groupings of modules that will work and play well together
> in such a grouping.
>

I agree with this.  I also think that unless the maintainer of a module 
package hasn't been given the value of the package string then the 
package string value should not be specified.  But the documentation 
doesn't support this.

> Dismissing the community experience and the very long discussions we've
> had planning this as 'merely dev type opinions' is not a correct thing
> to say.  We have had serious participation form coders, UI folks, end
> users non-coders, support types, etc.
>

I am not "Dismissing the community experience" I am a fresh newborn 
Drupal convert reading your documentation and discussions for the first 
time.  I am providing feedback so that the "community experience" can 
be improved.  I am bringing this matter to light (again for some) 
because in reviewing the provided documention and submitting .info 
files to maintainers I did it wrong.  As well, other more experienced 
to Drupal, have it wrong.  I am trying to get the confusion resolved 
and the documentation modified to reflect what the value truly should 
be.  I didn't say 'merely dev type opinions' I said 'the dev types that 
know what it is supposed to represent'.  Reading the documentation 
didn't enlighten me as to what its true purpose was.  Reading the 
documentation and looking at it functioning in the UI gave me my clues. 
  I am both an end user and a dev type.

>>
>> >
> http://lists.drupal.org/pipermail/development/2006-November/021080.html
>> >
>>
>> Yes, I have read your technical explanation before.  It is the end
> user
>> experience I am trying to benefit.  I agree that a module in a
> package,
>> package grouping, category or what ever it is needs to move to Other
> if
>> there is only one in the grouping installed in the users environment.
>> I disagree that if I have more than one Taxonomy module package
>> installed that the menu should display both of those in the Other
>> package grouping rather than the Taxonomy package grouping.
>>
>> Earnie
>
> There are a lot of levels of use here that were hammered out in the
> initial discussions.  This is a step.  We as a community need to see
> what develops out of the initial setup.  Now is not the time to leap off
> the bridge we just built.  Just because something leverages the taxonomy
> system does not mean it cooperates, plays well with or bears anything
> but a passing relationship to any other taxonomy based module.  It just
> means it needs taxonomy from core turned on.  Is this taxonomy module a
> menu?  A section module?  A breadcrumb module?  A theme module?  A forum
> access module?
>

<quote>If your module comes with other modules or is meant to be used 
exclusively with other modules, enter the name of the package 
here.</quote> Hmm... It uses Taxonomy ... Hmm... That must be the 
package string value I should use for my package.

> Each change in how things interoperate brings us knowledge and
> experience.  So far we have a consistent policy.

It may be an understood among those who have discussed it consistent 
policy but that policy hasn't been portrayed well in the documentation. 
  Perhaps because the documentation like the policy is a work in 
progress and only recently has the policy been cast as consistent.

> Let's see what we
> learn from this in the 5.0 release and apply that to the 6.0 release.  I
> suspect that we will learn that this was pretty close to what we do for
> 6.0 but we'll see as 5.0 will bring us a whole new realm of people,
> backgrounds and experiences.

I agree.  There are enough modules in CVS with info files that you can 
get a feel for the fact that people are confused about the package 
value.  The affect is rather ugly.  There is currently no control.  My 
opinion for 5.x, formulated as we have had this discussion, is that if 
the package value doesn't fit a known list it should always be listed 
in Other.

Earnie