4 ms·

This should have been solved ages ago but it isn't. What is the problem with allowing repositories with specific licenses or label to be transferered to contrib

This should have been solved ages ago but it isn't. What is the problem with allowing repositories with specific licenses or label to be transferered to contributors after certain length of inactivity? The one contributing the most gets notified to accept or deny the request.

fiddlerwoaroof 7y ago
Security is the main issue: you can’t just give away control of a widely used tool without vetting the new maintainer because that would open all your users to malicious code.
- thrwaway69 7y ago
  You aren't giving control to unknown people here. You are giving it to good contributors who you have added personally. We can still have a system where core contributors can vote on someone accepting the request or author can disable this feature. How many people vet the author before installing something from npm? If you trust someone because they have some code that looks good, then shouldn't you trust contributors who have good code in there too. How many points of cracks are there in the dependencies of dependency? If it's a widely used tool then author wouldn't go inactive for a year without doing something unless they are not getting paid or even acknowledged for their efforts. If people like security, then pin and mirror your dependencies. Don't update without checking them.
  - fiddlerwoaroof 7y ago
    My point was that the maintainer shouldn’t give up maintenance unless they trust the new maintainer, so we agree. (I did misread your original post, but I think it can’t be just any contributor)
dodobirdlord 7y ago
> What is the problem with allowing repositories with specific licenses or label to be transferered to contributors after certain length of inactivity? This is unworkable for a large number of reasons. But it's also largely beside the point. If the code is available under a permissive license and is not being maintained, fork it.

fiddlerwoaroof 7y ago

Security is the main issue: you can’t just give away control of a widely used tool without vetting the new maintainer because that would open all your users to malicious code.

thrwaway69 7y ago
You aren't giving control to unknown people here. You are giving it to good contributors who you have added personally. We can still have a system where core contributors can vote on someone accepting the request or author can disable this feature. How many people vet the author before installing something from npm? If you trust someone because they have some code that looks good, then shouldn't you trust contributors who have good code in there too. How many points of cracks are there in the dependencies of dependency? If it's a widely used tool then author wouldn't go inactive for a year without doing something unless they are not getting paid or even acknowledged for their efforts. If people like security, then pin and mirror your dependencies. Don't update without checking them.
- fiddlerwoaroof 7y ago
  My point was that the maintainer shouldn’t give up maintenance unless they trust the new maintainer, so we agree. (I did misread your original post, but I think it can’t be just any contributor)

dodobirdlord 7y ago

> What is the problem with allowing repositories with specific licenses or label to be transferered to contributors after certain length of inactivity? This is unworkable for a large number of reasons. But it's also largely beside the point. If the code is available under a permissive license and is not being maintained, fork it.