Modules Bug Reporting rules

DEVELOPMENT SYSTEM
Modules development is currently done only under Redhat 7.2 on i686 systems. I've no way to test how my modules behave under other distributions like SuSe(c), Debian(c) and so on.
If you're using an other distribution than Redhat, please report me if:

  • All works correctly
  • Needed to change some module configuration parameters (eg. paths) than those shipped with module
  • Needed to change some module code


    • BUG REPORTS POLICY
    No software, including my Webmin modules can anytime be claimed really bug free. Think: "you can write a one-line program and write it wrong"...
    In order to correct modules' bugs I need some information from users. Telling me simply "doesn't work" is useless! I really cannot test and debug the module such way.

    You must supply the following data at least:

  • Module Name
    		• e.g. "Maillog"
  • Module Version
    		•  e.g. "v1.00.6"
  • Webmin system Version
    		•  e.g. "Webmin 0.90"
  • Operating System Type and Version
    		•  e.g. "Redhat 6.2 on i386"
  • Error description
    		•  e.g. "Column "Message Size" show always 0"
  • The steps to follow to make the error happen again
    		• e.g. "Display any compressed mail log"
  • Data files on your system the module eventually works on
    		• e.g. "I've attached on this email the bad maillog file"

    Bug reports lacking this data may be silently discarded.

    Sorry, but I don't want to waste time understanding really cryptic bug reports. I'd like to spend time coding. If you need some help for giving me a correct bug report, don't wait and ask me.

    BUG FIXES POLICY
    Usually I start working on bug fixes on existing modules just a few days (or hours! ;-) after the user bug report.
    Please note that I may postpone the fix for many reasons: time, priority, etc.

    When a bug fix is ready, I'm used to contact by email the bug reporter user to tell him/her that a new module version is available for download.
    I'd like to receive some feedback from that user: if the new module solves the error or doesn't. If the user doesn't give me this feedback I'm sorry
    but the next time I may don't do an asked bug fix.

    Note that Silence is not a substitute for "Yes! It works great!".

    NEW FEATURES AND SUBMITTED CODE
    New features
    I'm happy to hear from you about new wanted functions for existing modules or new ones.
    Note that for some new feature - which get approved by me - I could need some direct help from you, as:
  • data files
  • active alpha and beta testing

    • For example:
    adding Qmail support on Maillog View implies running my module on a system equipped with Qmail. I'm running only Sendmail here so
    since you're running Qmail instead, you must supply to me some the logs generated by Qmail and be willing to try the resulting module
    on your system and report failures.

    Submitted code
    You can contribute to module debugging and development by submitting code written by you as new functions or bug fixes.

    Please follow the following guidelines as strictly as possible: you 'll make me able to quickly insert your code in the module distribution:
  • Send me diff patches or edited source files. Doesn't matter if in plain or compressed format. (gzip, bzip2, zip)
  • Use comments on your code. At least one comment line for each code section or macro-operation. I don't like adding code I cannot easily understand.
  • Declare variables inside subroutines using my() or local() statements
  • Submitted code can be only GPL licensed. No proprietary code allowed.
  • No MS Windows (c) related code. I hate Windows.

    • Oct 24th 2004 (c) Angelo 'Archie' Amoruso


    Yes! Archie's PC joined Seti Logo