 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
22 messages in ru.sysoev.nginxRe: Access key module| From | Sent On | Attachments |
|---|---|---|
| Evan Miller | Dec 29, 2007 7:19 pm | |
| Cliff Wells | Dec 30, 2007 12:53 am | |
| Manlio Perillo | Dec 30, 2007 7:41 am | |
| Cliff Wells | Dec 30, 2007 3:47 pm | |
| Grzegorz Nosek | Dec 31, 2007 12:32 am | |
| Manlio Perillo | Dec 31, 2007 3:43 am | |
| Manlio Perillo | Dec 31, 2007 3:55 am | |
| Grzegorz Nosek | Dec 31, 2007 5:31 am | |
| Manlio Perillo | Dec 31, 2007 6:46 am | |
| Evan Miller | Dec 31, 2007 8:00 am | |
| Grzegorz Nosek | Dec 31, 2007 8:07 am | |
| Manlio Perillo | Dec 31, 2007 8:32 am | |
| Manlio Perillo | Dec 31, 2007 8:49 am | |
| Grzegorz Nosek | Dec 31, 2007 9:06 am | |
| Adrian Perez | Dec 31, 2007 9:52 am | |
| Evan Miller | Dec 31, 2007 12:12 pm | |
| Evan Miller | Dec 31, 2007 12:41 pm | |
| Grzegorz Nosek | Dec 31, 2007 1:06 pm | |
| Cliff Wells | Dec 31, 2007 3:34 pm | |
| Manlio Perillo | Jan 1, 2008 9:03 am | |
| Manlio Perillo | Jan 1, 2008 9:07 am | |
| Adrian Perez | Jan 4, 2008 8:13 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: Access key module | Actions... |
|---|---|---|
| From: | Evan Miller (emmi...@public.gmane.org) | |
| Date: | Dec 31, 2007 12:12:49 pm | |
| List: | ru.sysoev.nginx | |
Grzegorz Nosek wrote:
On Mon, Dec 31, 2007 at 11:00:33AM -0500, Evan Miller wrote:
I too would prefer that the modules sit in a single tree. Perhaps a good model is the Linux kernel: they have hundreds of modules written and maintained by different people, but each one is approved by a number of people before shipping. I personally think that most non-Igor modules should sit in the main tree (src/http/modules), and the --add-module mechanism should be used only for one-off or proprietary modules that are privately maintained.
I don't think we (as the community) have enough resources to ensure quality review of each other's code, so the modules will probably remain more or less individual creations. As for putting external modules in the main tree, this will make them look rather like a part of nginx itself, which has both advantages and disadvantages, IMO. If we want to distribute a pack of nginx modules, maybe we should keep them in a structure parallel to original source, e.g. contrib-src/http/modules. Or maybe not, just brainstorming :)
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.
We can achieve #1 with a community edition of some sort. I hesitate to do it because modules often require patches to the nginx core (modifying data structures, etc.), and this may cause some confusion among end-users especially when bugs arise, then it might need its own mailing list, and things get hairy. There's also the question of what goes in the community edition and who decides (the malicious code problem).
#2, marking modules as "stable," does require some work; either Igor needs to review them and accept them into the official nginx download, or we need some sort of peer-review process so that outsiders can trust the community edition. I do think it's essential that modules be able to graduate to "first-class" status, but we will need Igor's cooperation. I am curious to hear about Igor's willingness to integrate third-party modules.
For #3, distributing modules and patches among developers, I again like the Linux kernel model: everyone keeps their own copy of the source, and posts the changes they make to a mailing list. To get updates, you just pull from developers you trust.
#1 and #2 are not trivial problems. My inclination is to solve #3 first and build a proper developer community; then the solutions to #1 and #2 might become more obvious. It might be that one developer's branch becomes the de-facto "community edition (testing)", and another developer's branch becomes the de-facto "community edition (stable)". In any event, we'll get a clearer idea of how many people are interested in testing and integrating.
BTW, I vote for git. :)
We should talk to Igor about his attitude toward third-party modules. I imagine he just doesn't have time to inspect, test, and integrate them. If it makes things easier, I'd be willing to consolidate our modules into a "community edition" and work with Igor to get changes accepted upstream.
I'm not really sure about it. Nginx is still mostly a one-man project and by integrating the modules into nginx core Igor would implicitly gain responsibility for them. Although I'm all for integrating more modules into core nginx, this should be (IMO) purely Igor's decision. OTOH, I see the community edition as a wrapper adding stuff, which Igor does not neccessarily want to see upstream, but which the community finds valuable.
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.
Yes, it's time we had something more flexible than the Guide. I would like both a low-level API reference and a high-level document more like the Guide. For the low-level stuff, I think something like javadoc parsed from the code would work best. (Another task for the "community edition"?) For the high-level stuff, I rather like how the Django book does it:
Well, the code is clean and rather self-documenting but comments are pretty scarce, so an automated tool will probably extract just the function prototypes. I think that a hand-written document with links to the source (lxr for example) will do just fine.
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.
IMO, the nginx source is pretty easy to follow at the low level (what does this function do), but the big picture is way harder (where is X handled), especially given the event-driven model and abundance of callbacks. Thus (again, IMO) we should concentrate at the high level description.
http://www.djangobook.com/en/1.0/
Each chapter has an individual author, but then anyone can leave comments in the margins. I'd prefer this model to a wiki because high-level guides are difficult to write, and their authors deserve credit for their work.
<aol>I fully agree.</aol>
(What's aol?)
Evan
Best regards, Grzegorz Nosek