[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: RungeKutta, WalshTransform and Evol
- From: Chris Babcock <cbabcock@...>
- Date: Mon, 30 Aug 2010 14:14:18 -0700
On Monday, August 30, 2010, steve donovan <steve.j.donovan@gmail.com> wrote:
> On Mon, Aug 30, 2010 at 1:51 AM, <pj@pjb.com.au> wrote:
>> Fair enough, I guess it's my CPAN background... Every new module,
>> you submit the name and a description to the newsgroup
>> and people dispute what it should be called
>> until a consensus emerges.
Consensus is a group of monkeys deciding who's going to eat the red
berries first. :)
I'm hoping that I didn't sound snarky. I'm very interested in social
design, which mostly means getting technology out of the way of human
interactions (except for those interactions that impede other human
interactions). Examples of this would be automating moderator tasks in
a game system so that you can maintain a smaller staff and don't have
to pull good people out of the player pool to serve as admins or
automating web administration tasks so that you don't have to pull
good devs out of projects...
> LuaRocks is (currently) just a delivery system. Each new module is
> posted to the luarocks-dev list and Hisham adds them to the server.
> It's hard to see how the process can be automated, you really do need
> a human in the loop for basic testing and approval. The way forward is
> probably a gang of approved package maintainers, as with Debian.
I was thinking that the committee approach didn't seem like a good fit
with my initial impression of the Lua community. If I'm wrong, and
there's every chance I am, then someone will make a top-down solution
a community priority when it suits their need.
For technology, though, I was thinking along the lines of developers
managing their own uploads and module descriptions. Add threaded
comments so that other users can provide information and warnings to
other prospective users... The trust model would assert repeatable
identity, but would not make any direct claims about code review. Over
time, implement tags instead of folders to manage findability and
Markovian filters so that the system isn't high-jacked to distribute
spam, warez and porn. You know, “provide mechanisms..." I'm a good
year or two from eating the berries on that particular bush, though,
so another monkey is welcome to eat them if they're ripe before then.
> The amusing/sad thing is that in the Lua universe 'dispute what it
> should be called' rarely leads to 'consensus emerges' ;) We tried to
> standardize basic functions like 'map' and couldn't even agree as to
> what the arguments should be.
There are inefficiencies involved with consensus as a social
mechanism, but that comes from people behaving like monkeys and is not
specific to the Lua community. The best thing to do is write code and
put it out there early. Even if it needs to be refactored to
accommodate suggestions or another codebase emerges that's better,
it's still a better use of time to build consensus by doing than by
talking.
>> I think there's a lot of modules running feral outside luarocks.org,
>> and the aim should be to be able to consolidate them at some stage,
>
> I dig the use of the word 'feral' because it makes me think of herding
> wild cats. Mostly it's people solving their own needs and sharing the
> result, for which we are grateful. But it can be suprisingly hard to
> find out what's there. LuaForge works, in a steam-powered kind of way,
> but it doesn't have a long-term future. I agree that a lot more can
> be done with Sputnik, especially with user-editable content (like the
> LuaSnippets site) but the LuaRocks developers would say that is not
> their job.
There's no reason that creating the LuaRocks tool would obligate the
devs to maintain a central rock server, but the LuaRocks.org site is
the closest thing currently in use.
I also strongly suspect that a centralized repository isn't what
LuaRocks or LuaRocks.org was intended to be. I'd love to be advocating
a more distributed approach myself. Maybe using redirects so that
"luarocks install package" can consistently construct a URL, but the
the actual bandwidth of the downloads comes from hosting elsewhere -
either the developers' sites or donated space.
Chris