Access key module

Grzegorz Nosek grzegorz.nosek at gmail.com
Tue Jan 1 00:07:09 MSK 2008


On Mon, Dec 31, 2007 at 03:13:12PM -0500, Evan Miller wrote:
> I think we're talking about three separate problems:
> 
> 1. Distributing community modules to end-users.
> 
> 2. Marking community modules as "stable."
> 
> 3. Distributing community modules/patches to developers.
> 

(snip interesting analysis)

I agree completely, the Linux model works on a huge scale and it should
work on a smaller one, too.

So in the short term, we'd just have to set up Trac somewhere (I can put
one up if needed).

> Well, Igor could delegate responsibility for individual modules to their 
> original authors. When questions or bugs come up, then that person is 
> responsible for dealing with them. If a module is causing problems and 
> that person is delinquent in addressing issues, Igor can just rip the 
> module out until a new owner is found. But it again depends on whether 
> he's willing to move beyond a one-man project.

True. IMO Igor should simply state his opinion (when he comes back from
vacation), no point in speculating.

> I don't entirely agree. Some functions do a lot of work and I would have 
> appreciated a sentence or two in summary. However, in these cases 
> perhaps refactoring the code would be more useful than commenting it. I 
> do agree that we should start with an organized list of function 
> prototypes and constants, and spend most of our energies on high-level 
> descriptions.

My statement was quite general and there certainly are functions which
might use better comments (ngx_init_cycle() comes to mind), but on the
whole, the low-level code is mostly self explanatory. As for documenting
the API, at this stage a reference documentation could consist of the
headers themselves (Igor mentioned that the API will be stable by 1.0
but some things are bound to change by then).

> (What's aol?)

http://en.wikipedia.org/wiki/Me_too :)

Best regards,
 Grzegorz Nosek






More information about the nginx mailing list