[pacman-dev] Submitting Patches

[Dan McGee]

On 10/24/07, Aaron Griffin <aaronmgriffin at 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 at 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