 | 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: | Grzegorz Nosek (grze...@public.gmane.org) | |
| Date: | Dec 31, 2007 12:32:21 am | |
| List: | ru.sysoev.nginx | |
Hi,
On Sun, Dec 30, 2007 at 03:48:12PM -0800, Cliff Wells wrote:
This actually brings up another thought: perhaps we should start an RCS tree for Nginx. We don't actually need Igor to use it (I'm sure he has his own tools and methods and I don't want to interrupt that): diffs can be generated automatically from the tarball Igor provides. Of course, we lose revision comments (assuming there are any), but we would at least have a public history and a place to provide downstream patches against (i.e. adding the ability to automatically pull 3rd party modules into the build process).
<plug mode="shameless">
Will http://git.localdomain.pl/ do? It has a few disadvantages: - unofficial (I just put it online without asking anybody) - a bit messy (though the vanilla branches are clean, the commits there have wrong dates and the older ones have wrong authors too), but nothing that couldn't be cleaned up
As for its advantages: - it's already there - can sign tags with pgp keys - distributed
</plug>
Adding a RCS system can be too hard to handle, altough a distribuited revision system can help (and some of them permits to sign each revision).
Not sure why this would be hard. Have current module developers vote on a preferred RCS and use it. And I agree that a distributed system (such as git) would be a good choice.
My vote goes to git :) OTOH, Keeping trees from two OSS systems in sync should be doable. I can host mercurial or bazaar or whatever too, if needed.
BTW, how do you suggest to keep the official repo up to date with contrib modules? Igor's releases I can keep track of, but this won't scale to contrib modules. I can either give the developers push access (which I'd rather not do), or set up a mailing list for sending lkml-style "please pull" requests. Periodic updates maybe?
Sure, but it doesn't solve the problem of creating a trusted code repository. Remember, the problem isn't how people are storing their code: it's how others *get* to that code. If they follow a link from a wiki, then there's the potential that they are not going to a legitimate site.
Does the current nginx wiki offer different access levels, i.e. only "foo" can edit the "Downloads" page? We could then split the downloads into official+contrib (editable by the select few) and the unofficial modules (IMO editable by anyone registered).
3) Perhaps adding some feature to the Nginx build process that allowed 3rd party modules to be easily downloaded and installed (from site listed in item 1) via configure/make flags (or is this just wishful thinking?).
Or perhaps simply distribute the contrib modules together with the main nginx archive (or as e.g. nginx-contrib-$VERSION.tar.gz). The modules tend to have negligible download sizes, so why bother writing a script to save a few KB?
I don't think this is a priority.
Well, nothing is a priority until it's a problem =) We've gone from having zero 3rd party modules to nearly a dozen in just a few months. It would be nice to get something in place while it's still a manageable task.
I think that an official repository (with vanilla and all the contrib modules in one tree), with some nice bug tracker (trac indeed would be fine) would help. This could also become a place for collecting development documentation (i.e. internal APIs, ways to do things nginx-style, common coding pitfalls, FAQs etc.) which is too technical to put it on the main wiki.
The "Guide to Nginx Module Development" is a great document but I think that the community could extend it even further, e.g. I'm currently up to date with nginx's shared memory support (which needs getting used to) and load balancer interface, Manlio with his mod_wsgi could probably write a lot of interesting stuff etc.
Best regards, Grzegorz Nosek