Access key module

[Grzegorz Nosek]

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