Hey Simon, thanks for the feedback w/ the project so far,
On 08/04/2011 10:24 AM, Simon Harris wrote:
The whole patches sent to the list for review and approval process seems, how shall I put it, arcane. I certainly respect that there is an element of tradition to the current process, yet at the same time feel compelled to call 'Legless Turkey'. In my experience, a system that involves pull requests is easier to monitor, easier to review, easier to merge, etc.
Not sure whats so 'arcane' about sending / reviewing patches, this is why git includes the 'send-email' and 'am' subcommands and I know many many communities that use this development methodology, such as the linux kernel itself [1] and puppet [2].
I guess I grew up so to speak believing that if we share responsibility for the success of the project, we ought all be able to commit. If not, we probably have the wrong people on the project. Now in my case, you don't know me from a bar of soap so I respect that you won't just hand over commit rights. That said, it is called a version control system for a reason -- no matter what I did, it could always be undone. As a senior developer, I'd much rather monitor ALL commits and review them once committed.>
Yes but could potentially lead to reverting alot of commits. Since we'd want to review the code anyways (either before or after) it seems simpler to verify things as they go into the codebase.
In any event, may I humbly propose that we consider giving commit rights to a wider range of people, or at least moving to a model that provides the ability to perform pull requests. I don't even know if the hosting we have even supports them but if it doesn't, then perhaps it's time to find something that does?
Commit rights isn't denied to anyone. The entire process is very open, and as soon as someone has shown their commitment (haha pardon the pun) they get commit rights.
Might I also humbly request that the onus of responsibility for getting patches reviewed shift from the patcher to the reviewer. I would, and do, certainly see that as my responsibility when I am in this position. As it stands, I see a bottlenecks where there really need not be.
There are also tooling being developed aiming to help out with this, see Traapas [3] and a redmine plugin that some of us in the Syracuse Ruby community have been starting to hack on [4]
Of course nothing should ever be set in stone, if there are better ways to refine / run the process, would love to adopt them.
-Mo
[1] http://lkml.indiana.edu/hypermail/linux/kernel/
[2] http://projects.puppetlabs.com/projects/puppet/wiki/Development_Lifecycle#Ma...