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. > As for the round robin mirrors idea, it's definitely an interesting idea > but potentially frustrating because the rocks available on any given mirror > might not be the same as the other mirrors due to delays. This would cause > unexpected confusion. Additionally you lose the ability for your module to > be available immediately upon uploading unless we can ensure mirrors update > immediately. You can solve that by doing what Linux distros do: always fetch the manifest from the master if available, and if you cannot find a rock on a mirror, try the next one in the list. ------------------------------------------------------------------------------ "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
