[HS?]: On gnus developement

[HS?]: On gnus developement

[Xavier Maillard]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

Hello,

I just want to know how is organized the Gnus developement. I mean are
only patches the solution to make Gnus always more powefull ?

It seems to me that this project is not structured as I used to see in
other projects. Am I wrong ? Is there a \"strong\" kernel developer for
Gnus (apart Lars) or does it work as I always see here by sending
patches and signing obscur documents to be able to publish them ?

Last but (surely) not least, is there any URL you can recommend to
learn what need to be done (TODO list), and how to become a Gnus
developer (even if just occasional) ?

Regards,

zeDek
-- 
"Most people deserve each other."

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [HS?]: On gnus developement

[Jesper Harder]

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.

Re: [HS?]: On gnus developement

[Glenn Morris]

A vaguely related question on Gnus development - (when) will the
version of Gnus in the Emacs CVS get updated?

Re: [HS?]: On gnus developement

[Xavier Maillard]

[-- Attachment #1: Type: text/plain, Size: 4072 bytes --]

On 25 jui 2003, Jesper Harder wrote:

>  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.

Oh okay that's just the FSF copyright, right ? 
  
> >  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.

Erf ;) I have alrready red the TODO list but I really didn't see what
have been done ;) 
  
>  (which would be a useful thing to do, btw.)  

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

That's an idea. I will try to list all those entries form the source
and try to update the TODO list.
  
>  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.

As I am not good enough to help people on this "channel", I really
can't see how hard would it be to help people fighting bugs. But who
knows ? Maybe it is my destiny ;)
  
>  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.

Better for you (and for me) not to have to touch to the documentation
side ;) My english is still goofy (not native language) and I am not
fan of documentation writing. In fact this is one of my main problem at
work : documentation.
  
>  o Implement a nifty feature you'd like to have.  Steal cool ideas

Yep but AFAIC, Gnus is so powerfull, I don't see/need other things for
instance. In fact there is already so much done, I am not sure I can
find out a new killer-feature to implement ;)

>  from other software -- JWZ has some interesting ideas in:
>  
>  http://www.mozilla.org/blue-sky/misc/199805/intertwingle.html

Will have a look at it.
  
>  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.
>  

Interesting but I need to read more on those items :) Maybe one day ...

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

Yep. There is little to do.
  
>  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.

Nice :) Will try to do my best ;) The main idea behind this thread is I
really want to contribute to all project which I take advantage
daily. It has been right for many of them such as videolan, xfce4,
etc...

In fact it is one of my main mental problem :) I like to try to help
out guys on project I daily use even if my contributions are/could be
considerated as not important/useless/small. It is my way to
show/retribute people for doing so good piece of software.

zeDek

-- 
"My suggestion for an Official Usenet Motto: "If you have nothing to
 say,then come on in, this is the place for you, tell us all about it!" 
							Hevard Fosseng

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [HS?]: On gnus developement

[Xavier Maillard]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

On 25 jui 2003, Jesper Harder wrote:

>  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.

Oh I just forgot to ask for this: is it usefull to "pre" sign the FSF
copyright assignments ? I need just in prevision I do something, may it
be of interest to sign and say all my future works apply for it ??

Where can I read more about that ?
  
> >  Last but (surely) not least, is there any URL you can recommend to
> >  learn what need to be done (TODO list),

> > [...]

zeDek
-- 
"Es gibt nur ein paar Radaubrueder (und einen Teufel :) ), die sich
 fuer "die" Gruppe halten." 
		TUESCHEN.MEDIZIN_KUNSTFEHLER@t-online.de (Rolf Tueschen)

	

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [HS?]: On gnus developement

[Matthias Andree]

Jesper Harder <harder@myrealbox.com> writes:

> 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.

Excuse my interference, but all code should be acting in the safest
possible way, not just encryption-related code.

-- 
Matthias Andree

Re: [HS?]: On gnus developement

[Xavier Maillard]

[-- Attachment #1: Type: text/plain, Size: 571 bytes --]

Matthias Andree <ma@dt.e-technik.uni-dortmund.de> writes:

>  Jesper Harder <harder@myrealbox.com> writes:
>  
> >  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.
>  
>  Excuse my interference, but all code should be acting in the safest
>  possible way, not just encryption-related code.

Agree with that.

-- 
"You only pass the Gates of Hell one time -
        The Gates of Microsoft keeps popping up everywhere you look"

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [HS?]: On gnus developement

[Jesper Harder]

Matthias Andree <ma@dt.e-technik.uni-dortmund.de> writes:

> Jesper Harder <harder@myrealbox.com> writes:
>
>> 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.
>
> Excuse my interference, but all code should be acting in the safest
> possible way, not just encryption-related code.

Sure.  But for encryption there are some special issues that don't
apply to the rest of the code.

E.g. all string and buffers that have contained passwords or decrypted
information ought to be explicitly overwritten immediately after
they're not needed -- just waiting for them to be garbage collected
(as we'd normally do) isn't as secure.

Also, normally we don't care if some piece of information sticks
around in a temporary " *mm*" buffer for while -- for encrypted
messages we ought to care.

Re: [HS?]: On gnus developement

[Simon Josefsson]

Jesper Harder <harder@myrealbox.com> writes:

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

While I remember it: the netrc parser in netrc.el is buggy, it should
accept

machine foo
	 port 4711
	 login jas
	 password bazonk

but it currently require it to be on the same line, i.e.

machine foo port 4711 login jas password bazonk

Fixing it shouldn't be too difficult, and could be useful.

Re: [HS?]: On gnus developement

[Lars Magne Ingebrigtsen]

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

> Oh I just forgot to ask for this: is it usefull to "pre" sign the FSF
> copyright assignments ? I need just in prevision I do something, may it
> be of interest to sign and say all my future works apply for it ??

Yes, that would be useful.  Assigning future changes makes will make
applying those future changes much speedier.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen