Re: Triumvirates

[Ralph Eastwood <tcmreastwood@...>]

I have to agree with what Dirk has said,

"What the community needs (maybe) is a sort of overall design and quaiity control
of module libraries" and "many others are pet projects

that die within a year", I think highlights this particular problem;

who maintains all those old libraries with new lua versions across each platform in this theoretical

centralised(e.g. luarocks) module repository?

There's lots of flavours of linux, and each flavour has their own set of maintainers, varying from less than 10 to more than a hundred.  However, it goes to show that there's a lot of folk out there, and I suspect if the framework was in place, lua could be maintained similarly.

For ensuring cross-platform-ness, should automatic build systems be considered? I know the distribution of binaries would not be useful, but to ensure things can build, and give the option for pre-built libraries (on certain platforms - probably useless on linux, but fine on win+mac).

The role of the maintainer would probably be to just make sure things always compile. Should the module writer be encouraged to be the module's maintainer?

Ralph

On 26 October 2011 17:01, Dirk Laurie <dirk.laurie@gmail.com> wrote:

Postings involving the following circle of ideas often appear on the list.

- Lua has no officially blessed library with hundreds of add-ons like
Python does.
- The initial exposure to Lua includes no WOW! graphics and/or sound
applications.
- The Lua interactive shell is very primitive compared to {ipython,…} — no GUI
 for program development.

There are at least three big projects in the direction of standard
module libraries:
Kepler, stdlib and Penlight.  There is at least one project in the direction of
synchronized module management: Luarocks.  There is the LfW collection for
Windows.  But none of them is 'official'.

What the community needs (maybe) is a sort of overall design and quaiity control
of module libraries.  Near-universal acknowledgment that a particular set of
modules, as painless to install on all platforms as is Lua itself, is canonical.

It is quite clear that we must not expect the Lua team to deal with
these issues.
Luiz and Roberto have both put substantial Lua add-ons on their sites with no
attempt to make them part of the 'official' Lua distribution.  Their task is to
keep the Lua core lean and healthy, and very well they do it too.

There have been suggestions of appointing a BDFL for overseeing a Lua module
library, all candidates however turning down the honour.

Now we have seen a development management model that works well: the one
in action for Lua itself.  A triumvirate of individuals with different
but compatible
talents.  A conservative policy of requiring unanimity before a
feature is added.

By contrast, most [ANN] items on lua-l are one-man efforts.  Sometimes, as in
the case of LuaJIT, that one man is a superman, but many others are pet projects
that die within a year.

Suppose there were similar triumvirates for module libraries, with a similar
conservative policy.  Maybe the reluctant BDFL's would be willing to shoulder
this shared responsibilty.  Then we might, we just might, see some consensus
emerging on which libraries are the one every Lua programmer should turn
to first.

Dirk
(who had a spare half-hour between knocking off work and supper)

--
Tai Chi Minh Ralph Eastwood

tcmreastwood@gmail.com