Okay, folks, I am now on a campaign. According to "Writing .info files (Drupal 6.x)" [http://drupal.org/node/231036], regarding the use of "package" in your .info files: "In general, this field should only be used by large multi-module packages, or by modules meant to extend these packages, such as CCK, Views, E-Commerce, Organic Groups and the like. All other modules should leave this blank. As a guideline, four or more modules that depend on each other (or all on a single module) make a good candidate for a package. Fewer probably do not." I am actively working on a very large site and adding (occasionally deleting) modules several times a week. Sometimes they are very hard to find because of all those misused "package" designations. Please, please, please, if your module does not meet the guidelines, remove that line from your .info files so that the module ends up in "Other," where it belongs. And please don't tell me about the various module page organization modules that the site owner doesn't want added. Nancy
I didn't write the guidelines. I just seem to be the only one who has read them. If you want to argue about them, then it should be with the powers-that-be who own those guidelines. ________________________________ From: Brian VuykI tend to think that two related modules probably make a good 'package', so they can be found together even with alphabetically distant names.
nan wich wrote:
I didn't write the guidelines. I just seem to be the only one who has read them. If you want to argue about them, then it should be with the powers-that-be who own those guidelines.
------------------------------------------------------------------------ *From:* Brian Vuyk I tend to think that two related modules probably make a good 'package', so they can be found together even with alphabetically distant names.
The point of my earlier email is that we are the enforcers of the guidelines. The guidelines state 4 to 5 or more modules with the same purpose could be group by a package. The guidelines state that a package with 4 to 5 or more sub-module could create its own package. But there is no guideline for what to make the package name. It only lists a few that were valid at the time the guidelines were written. Maybe it is time for the guidelines to be revisited. -- Earnie -- http://progw.com -- http://www.for-my-kids.com
I see this issue as being trivial compared to keeping third party code like JQuery plugins out of modules and CVS. That is a policy that's blatantly ignored. I have been trying/failing to get module developers to adhere to like this issue in the views_rotator module... http://drupal.org/node/701926 http://drupalcode.org/viewvc/drupal/contributions/modules/views_rotator/view... There are 4,000+ sites using that module with an old version of jQuery Cycle Plugin that makes it difficult for other modules to leverage features of the jQuery Cycle Plugin without going in and hacking the .js file in that module. I know there are improvements in the javascript handling in D7 that allow one module to override another module's javascript, but that doesn't change the fact that developers will ignore any "policy" if there is no enforcement. - Kevin On Thu, May 13, 2010 at 1:08 PM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
nan wich wrote:
I didn't write the guidelines. I just seem to be the only one who has read them. If you want to argue about them, then it should be with the powers-that-be who own those guidelines.
------------------------------------------------------------------------ *From:* Brian Vuyk I tend to think that two related modules probably make a good 'package', so they can be found together even with alphabetically distant names.
The point of my earlier email is that we are the enforcers of the guidelines. The guidelines state 4 to 5 or more modules with the same purpose could be group by a package. The guidelines state that a package with 4 to 5 or more sub-module could create its own package. But there is no guideline for what to make the package name. It only lists a few that were valid at the time the guidelines were written. Maybe it is time for the guidelines to be revisited.
-- Earnie -- http://progw.com -- http://www.for-my-kids.com
Kevin Reynen wrote:
I see this issue as being trivial compared to keeping third party code like JQuery plugins out of modules and CVS. That is a policy that's blatantly ignored. I have been trying/failing to get module developers to adhere to like this issue in the views_rotator module...
http://drupal.org/node/701926 http://drupalcode.org/viewvc/drupal/contributions/modules/views_rotator/view...
There are 4,000+ sites using that module with an old version of jQuery Cycle Plugin that makes it difficult for other modules to leverage features of the jQuery Cycle Plugin without going in and hacking the .js file in that module.
Yes, that is a bad one too and in my opinion, this one should be brought the attention of the webmasters [1] so that it can be handled.
I know there are improvements in the javascript handling in D7 that allow one module to override another module's javascript, but that doesn't change the fact that developers will ignore any "policy" if there is no enforcement.
Again, we, the users are the enforcers. So if we find something out of line then we need to bring it to the attention of the administrators. [1] http://drupal.org/project/issues/webmasters -- Earnie -- http://progw.com -- http://www.for-my-kids.com
Earnie, I'm sure you remember this thread... http://lists.drupal.org/pipermail/development/2007-May/024136.html "But I think when people talk about *not* allowing at-one-time-external GPLed code into the Drupal repository, they're simply on crack." -Jeff (Robbins) The CVS policy (http://drupal.org/node/422996) never changed and is very clear about exceptions... "3. Exceptions can be made if the 3rd party library: a. had to be modified to work with Drupal and the modifications were not accepted by the original author. b. is generally difficult to find in the needed version. c. is no longer maintained by the original author." Obviously a specific version jquery.js doesn't meet any of these criteria, yet 3 years later here it is in CVS... http://drupalcode.org/viewvc/drupal/contributions/modules/jquery_update/repl... Do you really think someone will enforce the policy on a module used by 40,000 sites on a developer with as high profile as Jeff? It's not much of a "policy" if some developers just ignore it. Why would you expect any other developers to follow it? The policy actually states... "Maintainers who violate this policy or refuse to correct violations brought to their attention may have their project unpublished or CVS access revoked." Sure they will. I'll believe the community can enforce policies like this on developers when I see it. - Kevin On Thu, May 13, 2010 at 3:30 PM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Kevin Reynen wrote:
I see this issue as being trivial compared to keeping third party code like JQuery plugins out of modules and CVS. That is a policy that's blatantly ignored. I have been trying/failing to get module developers to adhere to like this issue in the views_rotator module...
http://drupalcode.org/viewvc/drupal/contributions/modules/views_rotator/view...
There are 4,000+ sites using that module with an old version of jQuery Cycle Plugin that makes it difficult for other modules to leverage features of the jQuery Cycle Plugin without going in and hacking the .js file in that module.
Yes, that is a bad one too and in my opinion, this one should be brought the attention of the webmasters [1] so that it can be handled.
I know there are improvements in the javascript handling in D7 that allow one module to override another module's javascript, but that doesn't change the fact that developers will ignore any "policy" if there is no enforcement.
Again, we, the users are the enforcers. So if we find something out of line then we need to bring it to the attention of the administrators.
[1] http://drupal.org/project/issues/webmasters
-- Earnie -- http://progw.com -- http://www.for-my-kids.com
nan wich wrote:
Okay, folks, I am now on a campaign. According to "Writing .info files (Drupal 6.x)" [http://drupal.org/node/231036], regarding the use of "package" in your .info files:
"In general, this field should only be used by large multi-module packages, or by modules meant to extend these packages, such as CCK, Views, E-Commerce, Organic Groups and the like. All other modules should leave this blank. As a guideline, four or more modules that depend on each other (or all on a single module) make a good candidate for a package. Fewer probably do not."
I am actively working on a very large site and adding (occasionally deleting) modules several times a week. Sometimes they are very hard to find because of all those misused "package" designations. Please, please, please, if your module does not meet the guidelines, remove that line from your .info files so that the module ends up in "Other," where it belongs. And please don't tell me about the various module page organization modules that the site owner doesn't want added.
Wow, I can't believe it has taken this long for this issue to arise again in this list. The advise I received when bringing up this scenario when it was added in Drupal 5 was, open an issue ticket with a patch for the offending module. I've been thinking about a module to list the modules in alphabetic order by module file name giving the 'package' as a column. It is really a headache to try to find that new module you just added to the file system in the module list. -- Earnie -- http://progw.com -- http://www.for-my-kids.com
We use 'package' with modules related to the Open Media project. We also prefix our modules with om_. Another module we maintain in MERCI. MERCI is used by most Open Media sites, but not only Open Media sites so I put it in its own package. MERCI started as a single module. Now there are 4 submodules included with the MERCI project as well as additional functionality added by the Agreservations project and its modules. Who would to determine when several modules should be grouped into a package if not the developers? In my installs I have dozens of packages, many of which only have a single module... when the site starts. Then the module matures, is broken up into submodules, other developers extend the functionality with additional modules. Flags (flag), Licenses (creativecommons), Statistics (google_analytics), Metadata (pbcore) all start this way and I can see how this would be annoying if you only install one module in that package... but the reverse issue ends up being true as people install more modules in the package. The same discussion could be had about when to break modules up into includes, submodules, multiple projects/modules... This just HAS to be left up to the developer's discretion and no single approach is going to make everyone happy. --- Kevin Reynen - Senior Developer Open Media Foundation - Putting the power of the media and technology in the hands of the people. www.openmediafoundation.org On Thu, May 13, 2010 at 10:57 AM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
nan wich wrote:
Okay, folks, I am now on a campaign. According to "Writing .info files (Drupal 6.x)" [http://drupal.org/node/231036], regarding the use of "package" in your .info files:
"In general, this field should only be used by large multi-module packages, or by modules meant to extend these packages, such as CCK, Views, E-Commerce, Organic Groups and the like. All other modules should leave this blank. As a guideline, four or more modules that depend on each other (or all on a single module) make a good candidate for a package. Fewer probably do not."
I am actively working on a very large site and adding (occasionally deleting) modules several times a week. Sometimes they are very hard to find because of all those misused "package" designations. Please, please, please, if your module does not meet the guidelines, remove that line from your .info files so that the module ends up in "Other," where it belongs. And please don't tell me about the various module page organization modules that the site owner doesn't want added.
Wow, I can't believe it has taken this long for this issue to arise again in this list. The advise I received when bringing up this scenario when it was added in Drupal 5 was, open an issue ticket with a patch for the offending module.
I've been thinking about a module to list the modules in alphabetic order by module file name giving the 'package' as a column. It is really a headache to try to find that new module you just added to the file system in the module list.
-- Earnie -- http://progw.com -- http://www.for-my-kids.com
Surely at the point where you start to split your module into separate submodules you could then introduce a package for them to go in? Regards Steven Jones ComputerMinds ltd - Perfect Drupal Websites Phone : 024 7666 7277 Mobile : 07702 131 576 Twitter : darthsteven http://www.computerminds.co.uk On 13 May 2010, at 18:24, Kevin Reynen <kreynen@gmail.com> wrote:
We use 'package' with modules related to the Open Media project. We also prefix our modules with om_.
Another module we maintain in MERCI. MERCI is used by most Open Media sites, but not only Open Media sites so I put it in its own package. MERCI started as a single module. Now there are 4 submodules included with the MERCI project as well as additional functionality added by the Agreservations project and its modules.
Who would to determine when several modules should be grouped into a package if not the developers?
In my installs I have dozens of packages, many of which only have a single module... when the site starts. Then the module matures, is broken up into submodules, other developers extend the functionality with additional modules.
Flags (flag), Licenses (creativecommons), Statistics (google_analytics), Metadata (pbcore) all start this way and I can see how this would be annoying if you only install one module in that package... but the reverse issue ends up being true as people install more modules in the package.
The same discussion could be had about when to break modules up into includes, submodules, multiple projects/modules...
This just HAS to be left up to the developer's discretion and no single approach is going to make everyone happy.
---
Kevin Reynen - Senior Developer Open Media Foundation - Putting the power of the media and technology in the hands of the people. www.openmediafoundation.org
On Thu, May 13, 2010 at 10:57 AM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
nan wich wrote:
Okay, folks, I am now on a campaign. According to "Writing .info files (Drupal 6.x)" [http://drupal.org/node/231036], regarding the use of "package" in your .info files:
"In general, this field should only be used by large multi-module packages, or by modules meant to extend these packages, such as CCK, Views, E-Commerce, Organic Groups and the like. All other modules should leave this blank. As a guideline, four or more modules that depend on each other (or all on a single module) make a good candidate for a package. Fewer probably do not."
I am actively working on a very large site and adding (occasionally deleting) modules several times a week. Sometimes they are very hard to find because of all those misused "package" designations. Please, please, please, if your module does not meet the guidelines, remove that line from your .info files so that the module ends up in "Other," where it belongs. And please don't tell me about the various module page organization modules that the site owner doesn't want added.
Wow, I can't believe it has taken this long for this issue to arise again in this list. The advise I received when bringing up this scenario when it was added in Drupal 5 was, open an issue ticket with a patch for the offending module.
I've been thinking about a module to list the modules in alphabetic order by module file name giving the 'package' as a column. It is really a headache to try to find that new module you just added to the file system in the module list.
-- Earnie -- http://progw.com -- http://www.for-my-kids.com
The reason this came up again is because I have already opened several issues. And, Earnie, just install the Util module (package). That's already in there, as well as collapsed fieldsets for each package. Unfortunately, the site owner here doesn't want me to use that module or any of the others that organize the page better. ________________________________ From: Earnie Boyd Wow, I can't believe it has taken this long for this issue to arise again in this list. The advise I received when bringing up this scenario when it was added in Drupal 5 was, open an issue ticket with a patch for the offending module. I've been thinking about a module to list the modules in alphabetic order by module file name giving the 'package' as a column. It is really a headache to try to find that new module you just added to the file system in the module list.
nan wich wrote:
The reason this came up again is because I have already opened several issues.
I gave up on doing that months ago.
And, Earnie, just install the Util module (package). That's already in there, as well as collapsed fieldsets for each package. Unfortunately, the site owner here doesn't want me to use that module or any of the others that organize the page better.
Thanks for the tip. But, why would they want to make such a blanket decision? Don't answer that, just my sarcastic nature showing. -- Earnie -- http://progw.com -- http://www.for-my-kids.com
participants (5)
-
Brian Vuyk -
Earnie Boyd -
Kevin Reynen -
nan wich -
Steven Jones