5 ms·
This seems like a great idea, there's just one thing I don't understand - the project owners are not onboard (as far as I can tell), so whoever decides to fulfi
by pytrin 14y ago
This seems like a great idea, there's just one thing I don't understand - the project owners are not onboard (as far as I can tell), so whoever decides to fulfill a bounty is not necessarily connected to the projects and might not have commit privileges. How does that work?
- roma1n 14y agoWith distributed SCMs, 'commit privilege' is a thing of the past. The ability to push to the 'blessed' repository might be a competitive advantage though :)
- pytrin 14y agoI'm not sure what you mean - you would like the patches to be a part of the project trunk, otherwise you'd need to keep applying patches after every update.
- pm215 14y agoIt looks like the sponsor can choose (via a 'no forking' option) whether they are happy with patches to fix the issue or if they require them to be committed upstream. It's an important distinction because there can be a lot of extra effort in going from "patches good enough to fix the case I care about" and "sufficiently general and well-engineered solution to get through code review and be committed upstream". Presumably you wouldn't take on trying to fulfil a bounty with the 'no forking' option set unless you were sufficiently familiar with the upstream community for the project to know that you had a reasonably good chance of getting your change committed. (That doesn't require that you have commit privileges, of course. Conversely, even if you do have direct commit access that doesn't necessarily mean you'll be able to get any old rubbish upstream without going through the same code review process as a non-committer.)