> -----Original Message----- > From: Philipp Janda [mailto:siffie...@gmx.net] > Sent: dinsdag 7 mei 2013 9:59 > To: luarocks-developers@lists.sourceforge.net > Subject: Re: [Luarocks-developers] Hostile rockspec takeover > > Am 07.05.2013 08:44 schröbte Thijs Schreijer: > >>> I do agree that some tighter security controls would be nice on > LuaRocks > >>> and its community, but the reality is that it is still a one-man- > >> operation. > >> > >> That's totally true, we can't expect Hisham to scale up indefinitely ;) > >> How to distribute the load? > >> (On the integration side, Andrew Starks has made a CI server available > to > >> LuaDist and LuaRocks) > > > > First question to answer is the security one raised by Jack. Casu is > that a broken spec remains broken until someone takes over. So how can we > make the 'taking over' part as solid as possible? > > > > A simple set of rules like; > > - create an issue on the issue tracker of the project (or other > > means listed by the original owner) > > - if no response in a month, then in 3 months 3 notices on the LR > > list for the creator/maintainer to respond to a request for a > > takeover. Each notice containing links to the previous efforts > > (to make sure it is public). Last one also on Lua list??? > > - if no response, fork project, and asap create a new rockspec > > pointing to the new locations > > > > It would be a public process, and would be shared on the list (not > depending on Hisham). Could something like this work? > > It still depends on Hisham, as he has to known all maintainers for 500+ > rocks, so that he can accept updates from the right people and reject > others.
Hmm. Yep you're right. The next thing I can think of would be a website where users can upload their own rocks (like with moonscript). With some annual confirmation that rock owners still are active, if they don't respond, the rock automatically goes up for adoption. > But in principle it could work, I think. I especially like the "notices > containing references to previous efforts" thing. But it will be slow, > because you have to wait until a person willing to take over a project > also has a reason to contact the developer/maintainer. Peter Billam > suggested a list of unmaintained projects, so anybody could start the > process of putting a project there if contact with the developers breaks > up. So if a person willing to adopt a project comes along, he/she can > immediately check if someone else already failed to reach the original > maintainers and take over when appropriate. It could also be good to > know if a project you are planning to use is unmaintained, even if you > don't have feedback/patches for the developers at the moment. > > For the dependency issue I hope that we can find something faster ... > I doubt it. People need to get a fair amount of time, returning from a long holiday a find all your code gone, that’s a bad thing. ------------------------------------------------------------------------------ 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
