[development] RFC: Candidate 'premium' modules
merlin at logrus.com
Tue May 16 05:24:53 UTC 2006
> Premium modules are those that are:
> a) release-critical - A new version of Drupal cannot be released
> unless these are up-to-date.
> b) quality controlled - these will be 'core modules' in all but name.
> c) well maintained - HEAD, current release and previous release should
> all be maintained preferably by a number of maintainers.
I actually talked this over with chx in the IRC, and said I'd send my thoughts
on it to the list, and then didn't do that part. Mea culpa.
Here's my theory:
Scratch a). Can't call them release critical, because you can't have someone
falling asleep at the wheel hold up things for everyone else. That said, b and c
are important. But it's more than just b and c.
So here's my version of the proposal.
Drupal High Profile Modules
1) People close to Drupal, which is a rapidly evolving group of people that will
likely have members leave and join but will generally be readily identifiable
will take responsibility for code reviewing these modules, particularly in terms
of security and ensuring that they are safe to run with Drupal.
2) These modules will be readily identifiable on drupal.org as these modules,
and users can download them with an extra level of comfort knowing that a
central part of the community has tested these modules.
3) These modules will serve as examples for other contrib modules to emulate.
4) The security team will treat security reports against these modules
seriously, and will be willing to patch these modules and write security
announcements when these modules are found to have security defects.
This doesn't require much code, really; it does require a process wherein people
who are trusted do code reviews against the candidate modules, and that the
results of those reviews are taken seriously. It requires that commits against
these modules are followed by Drupal developers, looking for mistakes. And it
requires that the Drupal project module have a better release process so that
these modules can have real versioned releases, like Drupal itself has.
Modules will be chosen to be in this category based upon quality of code and a
general sense of widespread use. A good indicator of whether a module should be
considered for this role is the number of downloads / searches on the module.
This indicates a level of interest. But it is only one factor; bad code won't
fix itself, and this proposal doesn't require any of the Drupal developers to go
fix other people's modules, except for security issues. And even then, the
security team's role may be to remove the module from the list and say "This
module is dangerous, we can no longer recommend its use."
More information about the development