On 7 May 2013 13:32, Philipp Janda <siffie...@gmx.net> wrote: > Am 07.05.2013 18:05 schröbte Jack Lawson: >> Or you could just fork the code and upload a new version of the rock and >> use and promote that, > > New name or old name? If new name, you basically get *more* unmaintained > rocks in the repository (see lposix vs. luaposix). You would also have > to change/fix/fork all rocks having this one as a dependency ... > >> instead of changing someone else's code, and then you > > I proposed changing (fixing) someone else's rockspec, not their code ... > >> can avoid this whole mess. If the owner isn't updating an older rock, by >> virtue of entropy (and perhaps statistics on how popular a rock has been >> the last month) the new one will take over. > > Like with luasocket, for example?! Fortunately, luasocket specifies > correct Lua dependencies ...
[Ouch, it's hard to pick a particular message to reply to in a long thread when using GMail.] This is a great discussion, many good points were raised. As it was mentioned above, being the upstream maintainer and submitting a rockspec are not necessarily the same thing, so i don't think we should think in terms of "hostile takeover". I always thought that anyone is welcome to submit a rockspec of any project, whether they wrote it or not (you never see Roberto submitting rockspecs for lpeg, do you? :) ). On security: it's usually not a concern because the source.url tends to point to evidently upstream URLs. It's especially not a concern in the case of a rockspec revision fixing dependencies, since those don't even change the source.url. It's even less a concern when the only change is in the "lua" dependency. It's plain to see there's no malicious possibilities in that (the worst this could do is to temporarily break a rockspec). On scaling: I'd really like to see the main rockspec eventually going to MoonRocks or similiar. I reported some issues in MoonRocks to Leaf Corcoran but haven't heard back from him, so I took it to mean that he doesn't have the time to focus on MoonRocks lately, which made me assume that it is not ready for taking over as the main rocks repository. But I'm not closed to the idea. Then there's an issue about accounts and abandoned rocks, but to a good extent I think this could be handled by a group of mods on a case-by-case basis without too much red tape. On forbidding rocks with "lua >= 5.1": I've been seeing less of those, since I fixed the documentation to recommend "lua ~> 5.1" and users/devs are more aware of the issue. I think things will eventually get sorted out, without having to ban any rocks. We all want the repository to have the best possible quality, but I think we should strive to get things towards a more open/wiki-like approach, and not the other way around. So, in short, feel free to send new revisions of rockspecs which you know are broken on Lua 5.2 fixing the 'dependencies' table and I'll upload them! -- Hisham http://hisham.hm/ ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ Luarocks-developers mailing list Luarocks-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/luarocks-developers
