On 10/24/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
I want to bring this up a little bit.
There's lots of ideas thrown around on this list, but more often than not, no code, or cryptic patches.
This does nothing. All it does is waste both mine and Dan's time.
On 10/24/07, Xavier <shiningxc@gmail.com> wrote:
But if your patch is rejected, then you should probably also provide one separate patch with only the small bug fixes.
This should ALWAYS be the case. Submitting a patch with 5 different changes is NOT acceptable. "One feature per patch" is the way this works. This is not just pacman either. Most other open source projects do it this way.
Think of it this way: if you submit a patch with 5 changes, and one change is rejected, then you need to resubmit the whole thing. If you submit 5 patches, and 4 get merged, you only need to resubmit one small patch AND you get listed in the SCM history 4 times. Yay.
Secondly, if a patch is submitted, and it's broken, resubmit the patch. Don't say "oh change this".
If you'd like a shining example of how this process works, take a look at Nathan's recent patches. He submitted them, in git format, they were commented on, he changed them, resubmitted, and they were merged. It's really that simple.
Dan and I do not need all this extra work. What Nathan did is EXACTLY how this process should work (PS Thanks a lot Nathan)
Going forward, I think we're going to have to do the following: If you want a change made, a patch MUST be sent in git format. Otherwise it will simply be rejected, not for lack of effort but for the simple fact that it's a waste of our time to have to deal with.
OK, Aaron dropped the ball so I'm going to say whats on my mind as well, hopefully keeping it short. I was going to write an email exactly like this, we both discussed this last night. My new stance- I'm going to make one more pass through my email inbox and see if there are (not-)patches and things that I can easily apply. If so, I'll try to get them at least on a testing branch on my tree. If not, then they are getting deleted. Sorry, but if you can't put it in a form I can easily digest, then I no longer care. Starting NOW, I will no longer even look at an email that is not in GIT patch format if it is supposed to be a "patch". It will go straight to the trash. The rest of you on the list are welcome to take these suggestions and turn them into a GIT patch that I will read, but I'm not going to waste any more time saying "I need to spend 30 minutes looking this over". Nathan's set of 5 patches were an _excellent_ example of what to do. He broke what would have been a large, hard to digest change into 5 discrete patches with the code still compiliing and working after each stage. This is perfect. I don't care if it is a one line change or not- put it in GIT format. This means I want three things- a commit message, your signoff, and the code change itself. That is what has been lacking in a lot of submissions. Signing off makes sure people are actually testing and willing to support their patch. The commit message will end up in the history, so I can reasonably expect it to be a concise definition of the changes. Finally, the code change in patch format is just what I want to be able to see what changed. The *only* other method of patch submission I will accept is having a public GIT tree set up and a 'topull' branch or something similar. However, submissions that should be peer reviewed should still be sent to the mailing list. Why am I being such a hard ass on this? Because I am beginning to lose motivation to merge other peoples changes when it take me more time to figure out how to review them then it did to make the change itself. And I'd like to enjoy working on pacman again. Right now I feel like there is a weight on my shoulders with all these shoddy patches lying around. I want that weight to be gone, and I want others to be able to review patches just as easily as I should. In short- from here on out, only GIT patches accepted. End of story. Happy pacman-ing! -Dan