On 22 May 2014 09:51, Pierre Chapuis <catw...@archlinux.us> wrote:
> On Wed, 21 May 2014 18:36:05 -0300
> Hisham <h...@hisham.hm> wrote:
>
> > As mentioned before in this list, we have a plan of making MoonRocks
> > the default rocks repository, effectively moving LuaRocks to a
> > non-curated repository model (like the vast majority of programming
> > language repositories out there).
>
> Great.
>
> > We still need to figure out how to make the existing mirror sites of
> > the repository fetch from the MoonRocks repository (they currently
> > rsync from luarocks.org). Current mirrors and their contact persons
> > (all cc'd here) are:
> >
> > * http://luarocks.giga.puc-rio.br/ - GIGA Lab at PUC-Rio
> > * http://luafr.org/luarocks/rocks - Pierre Chapuis
> > * http://liblua.so/luarocks/repositories/rocks - Rob Kendrick
> > * http://luarocks.logiceditor.com/rocks - Alexander Gladysh
> >
> > I'll try to figure out how to make the current main server address —
> > http://luarocks.org/repositories/rocks/ — redirect to MoonRocks or
> > also become a mirror of its repo.
>
> Actually I already mirror MoonRocks as well as LuaRocks for the
> purpose of feeding the Lua Toolbox monster. It is just not publicly
> exposed but it should be easy to switch. I just git pull the
> repository to mirror.
>
> I would be in favor of introducing stricter automated checks before
> accepting a rockspec on MoonRocks, and maybe removing old rockspecs
> that do not comply from the repository. From what I can remember some
> rockspecs in there cannot even be parsed by LuaRocks, and several
> have no description at all for instance.
>
> Also, I think if MoonRocks and LuaRocks merge, the usefulness of
> Lua Toolbox will decrease a lot. Its defining features
> (endorsements and tags) should probably be fed back into MoonRocks instead.
>
> My only issue with the MoonRocks website is that it is written entirely
> in MoonScript, which makes it harder for me (and probably most Lua users)
> to contribute. But if Leaf is OK and I can find some time, I will look
> at how feasible it is.
>
> On Wed, 21 May 2014 22:38:19 -0700
> leaf corcoran <lea...@gmail.com> wrote:
>
> > In response to the worries about malicious modules, if you have any idea
> > for mitigating problems like this I'd love to hear them. I think
> minimally
> > it would be good to have some community moderation features. Nothing like
> > that exists yet but if there are people interested in being moderators
> then
> > I can add that functionality.
>
> You could add a feature to flag a rock as dangerous in the MoonRocks
> website.
>
> Only usable by registered users (to prevent abuse), it would flag the
> rock as potentially dangerous in the UI and send an email to moderators.
> (I would gladly be a moderator by the way) who could then decide to
> take down a rock.
>
>
Yes, I was just thinking about something like this -- or rather, an
appstore-like ratings system with a flag button for malicious rocks.
It'll never be possible to automatically detect "bad" rocks, but it wasn't
really possible with a curated rocks repository either. By adding a ratings
system and/or at least a flagging feature, there'll be an element of
self-regulation in the system.
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Luarocks-developers mailing list
Luarocks-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/luarocks-developers
