Please Help : Developers' Guide Update

[Jouni Heikniemi]

On Sat, 13 Dec 2003, MattyT wrote:

> The developers' guide is getting somewhat outdated now.  It quite
> incomplete, and even incorrect in places now.  I've caught up somewhat
> so I'll be taking a look at updating it, before I look at getting my
> other Bugzilla commitments under control.

Excellent :-) This is really needed.

> Win32 Programming - What needs to be avoided?  What is pipe open
> syntax?  Path issues?  Non-existent binaries?  Examples?

Some simple points:

1) Avoid stuff that's only meaningful on *x. Trivial examples include:
   - chown, chmod
   - getgrnam, $< et al.
   - stty
   - sendmail :-) (84876)
   - signal handling
   (see bugs 143490, 224476, 154601 for some ideas)
   Most of the time, it suffices when you think these things through
   and, if necessary, add OS checks to bypass Unix-only code. I'll
   assist in coming up with Win32 alternatives when necessary.

2) Avoid features that are not supported by ActiveState Perl O:-)
   - fork() is definitely out of bounds; this isn't directly used,
     but bug 183753 has an example on a very tricky issue w/ this.
   - "open (DOT, '-|') or exec (stuff);" is the pipe open beast.
     (I'm still looking for a good alternative for this, so don't
     have a recommendation yet)
   - Any execs are subject to limitations mentioned in 129401; it's
     probably worth the effort to go through the cases one-by-one,
     since we have so few cases of external execution.

3) Taint mode stuff
   - IIS forces all files to run under taint mode.
   - This is mostly irrelevant in the dg, though; admin files
     are getting taint-checked while we templatize, and after that
     we're fine.

Nothing beats testing! IIS in particular is a good test platform, as it
prints CGI warnings to stdout instead of an error log :-)

I'll add details, should I remember some more.


> Do we have a CSS style policy yet?

No. Kiko has been writing up a draft, he promised he'll post it really
soon now. (it'll probably take a few patches of practice before it
develops into a decent policy, though)

> Brief description about the mailing lists ... etiquette?

Shouldn't this be on the discussion page instead of dev guide?


A couple of other points worth mentioning, although I'm not the resident
guru on these:

- Template naming (see discussion a few weeks ago on reviewers@). The
  current text on this is fairly close to the consensus reached, though.

- Using filterexceptions.pl (see bug 225703 comments 19-21)

- Maintaining customizable terms: We now have "[% terms.Bug %] instead of
  "Bug" and so on. Discuss the reasons and best practices.



Jouni