From: <ja...@qv...> - 2006-01-13 10:33:51
|
>> ja...@qv... wrote: >>> Hi all, >>> >>> >>> please don't blame me, but I think we all should think once again about >>> how to deal with plugins. >> >> I have to agree... A year ago, when I stopped participating in the >> mailing lists, each plugin author had access to the plugins page, and could >> publish their plugins themselves. Now it seems there is a gatekeeper of >> sorts who must approve the plugins for publication. >> >> In the three days since I've been re-subscribed to the lists, I've >> already seen one person offer up a plugin that he wrote, only to get >> kicked in the teeth by this gatekeeper. There's almost a "hostile" >> atmosphere to the lists now, nothing like they used to be. I understand >> this is a pet project for alot of people, and there are alot of "dumb" >> questions asked, but being a jackass towards folks who are trying to >> contribute to the project is NOT a good way to promote that project. >> >> I was looking forward to participating again and working on my plugins, >> but honestly, I've been reconsidering even being active on the lists... > > If plugin is not coded according to coding guidelines, it won't be > accepted by SquirrelMail developers and should not be posted on > squirrelmail.org plugins list. We are trying to increase quality of > SquirrelMail plugins and can't accept broken contributions. > > Paul only asked to follow coding guidelines. > > Dspamprefs plugin causes PHP errors. Array keys are defined incorrectly > and create bunch of E_ALL errors, compatibility code is for old plugin > version, $_POST variables are accessed without prior checking, popen > errors are not handled and dspam_admin program is not supposed to be > stored in /bin directory, chdir() should not be used in squirrelmail > 1.4.x. Plugin states that minimal version is 1.4 and still uses legacy > code for 1.2.x > > Pear review and administrative approval reduces number of broken plugins. > You need approval only for the first plugin version. We assume that > developer will learn from fixed mistakes. This one way to do the job. I gaze how much efforts you and other developer are willing to spend for squirrelmail. Please explain (and put it into doc/plugin.txt) which is the formal approach? How to get approval? > > If you want some generic site to host your squirrelmail plugins, I > recommend sm-plugins project. > > Implementation of your updates depends on plugin developer's schedule. Try > contacting plugin developer or add patches to SquirrelMail bug tracker in > plugins section. Don't force version number updates in your patches. Try > getting last available plugin snapshot and write patches for it. If you > want to get patch implemented faster, make sure that it applies correctly > to latest plugin code and make sure that patch contains only needed > changes. No extra style or spelling modifications. > Thank you - this is an important information for me. I always though, the bug-tracking system is for squirrelmail itself only. I'll start the next days and add all the errors I found (if they're not already posted). Please include that important piece of information in the doc/plugin.txt. > If plugin's translations are maintained by i18n team - post translation > only to i18n list. 1. Add topic to bug tracking system (eg. internationalization not supported) 2. Watch list until bug is accepted and plugin is patched 3. Post translation to i18n Did I got it? > > -- > Tomas |