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