Gnus development mailing list
 help / color / mirror / Atom feed
From: Jesper Harder <harder@myrealbox.com>
Subject: Re: [HS?]: On gnus developement
Date: Fri, 25 Jul 2003 01:25:23 +0200	[thread overview]
Message-ID: <m3n0f3zevw.fsf@defun.localdomain> (raw)
In-Reply-To: <plop878yqprck3.fsf@gnu-rox.org>

Xavier Maillard <zedek@gnu-rox.org> writes:

> or does it work as I always see here by sending patches and signing
> obscur documents to be able to publish them ?

Yes (more or less).  Ad copyright assignments: remember SCO.

> Last but (surely) not least, is there any URL you can recommend to
> learn what need to be done (TODO list),

There's the file "todo" in the top-level Gnus directory.  But it's
not terribly up to date -- one of the items is

  * Go through the todo list and remove items already done.

(which would be a useful thing to do, btw.)  

You can also grep the sources for the string "Fixme" (or "FIXME") for
some problems that would be nice to have fixed.

Some other random suggestions:

o Fix bugs.  Fix bugs.  Fix bugs.  Read <news:gnus.bugs> (and the
  other Gnus groups) and try fix bugs that people report.

o Improve the documentation.  Document currently undocumented options
  and commands.  Write tool-tips for menu items that don't have them.
  Improve docstrings, make them conform to
  <info://elisp/Documentation+Tips> where it makes sense.

o Implement a nifty feature you'd like to have.  Steal cool ideas
  from other software -- JWZ has some interesting ideas in:

  http://www.mozilla.org/blue-sky/misc/199805/intertwingle.html

  Zoë sounds interesting, too (haven't tried it, though):

      http://guest.evectors.it/zoe/

o Verify standards compliance.  Read through some of the standards to
  which Gnus purports to conform, and verify that we satisfy all
  SHOULDs and MUSTs, implement missing parts.  Maybe write tests for
  some evil corner cases which could be useful for regression testing.

  Two examples: 1) we need a real RC2822 address parser, 2) mailcap
  parsing (RFC1524) is slightly wrong.

o Profile time and memory use, and try reduce it.

o If you have the right paranoid mindset and understanding of security
  issues: Audit the code related to encryption to make sure it's done
  in the safest possible way.

> and how to become a Gnus developer (even if just occasional) ?

Send patches/code.  If you contribute enough stuff, people will
probably eventually think it's more convenient if you have commit
access.



  reply	other threads:[~2003-07-24 23:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-23  6:18 Xavier Maillard
2003-07-24 23:25 ` Jesper Harder [this message]
2003-07-25  2:04   ` Glenn Morris
2003-07-25  6:07   ` Xavier Maillard
2003-07-25  6:11   ` Xavier Maillard
2003-10-17 21:39     ` Lars Magne Ingebrigtsen
2003-07-25 19:54   ` Matthias Andree
2003-07-25 20:51     ` Xavier Maillard
2003-07-25 21:51     ` Jesper Harder
2003-07-31  1:11   ` Simon Josefsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3n0f3zevw.fsf@defun.localdomain \
    --to=harder@myrealbox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).