On Tue, Mar 08, 2011 at 12:31:43PM -0500, Mathieu Bouchard wrote:
On Tue, 8 Mar 2011, Chris McCormick wrote:
This is not realistic. If you look at any large FLOSS project, patches
lie dormant, are ignored, are rejected for the wrong reasons all of the time. Submit a patch to the Linux kernel and see what happens. Most
likely it will be silently dropped.Do you mean we have to adopt and accept the same problems that are sure
signs of a project's overwhelming success ? Would that bring us
overwhelming success too ?
No, that is not my point. I'm sorry I was unclear. I meant to show a causal chain that does exist in most FLOSS projects, including Pd. I did not mean to advocate a particular style of software management, or the adoption and acceptance of any problems.
The causal chain works like this:
In my experience, the best way to get a patch accepted in most projects is to invest time in engaging socially. The reality is that often the
onus is on the submitter to advocate for their patch.Don't you think a lot more patches would go through if the users wanting the features weren't sitting around saying things like "the onus is on the submitter" or just being quiet, and instead promoted the patches ?
Yes, that is almost certainly true. At last I have found a new years resolution, thank you.
So now we have two ways to help patches go through:
In a large project, people have the luxury to say things like "the onus
is on the submitter", because if that scares away 1000 developers, there's another 1000 developers working on the project anyway.
I hope I have not scared away any developers. That is the opposite of my intention.
In this case a sensible place to do that would be pd-dev list.
I don't see the connection between babbling on pd-dev and getting a patch approved by someone who rarely writes on pd-dev.
Consider this mechanism:
Realistic? To me it seems more likely to get a patch applied than active hostility.
Demanding that your patch is more important than the other things a
volunteer-maintainer might need to do with their timeI thought you were trying to be realistic about the situation. We need not invent additional problems.
I was referring to this statement:
"PS: the [delwrite~] clear method is still assigned to 'nobody', because it's waiting for any of the five project admins to click on a button..."
http://en.wikipedia.org/wiki/Ellipsis http://en.wikipedia.org/wiki/Aposiopesis
It implies that the application of the [delwrite~] clear method patch has been too slow for your liking, which implies that the five project admins should have found the application of the [delwrite~] clear method more important than whatever it is they have been doing which isn't clicking that button.
"Demanding" is too strong a word. I'm sorry that I used that word. Probably I should have written "implying".
Likewise if you somehow imply that the maintainer owes you something
Likewise if you somehow imply that a patch-submitter is bound by some kind of onus, so that he does your promotion job for you, for inclusion in a branch he doesn't need, for a patch he doesn't need either...
I'm sorry, this was badly phrased. I meant to say that given the condition that the patch submitter wants their patch to be merged, then the onus is on the patch submitter to advocate for acceptance of the patch.
Because you submitted the patch to the patch tracker, and then complained that nobody had clicked the button, I assumed that you wanted the patch applied. Your statement "for a patch he doesn't need either..." indicates that you actually aren't interested in the patch being applied. If this is indeed the case, please feel free to resume your normal trend of thinly veiled insolence.
You are correct that anyone who wants the patch applied should also do the job of promoting the patch. I am convinced by that argument.
Seriously, I find it weird that I even have to write this.
You don't "have" to.
You are correct, that was badly phrased.
Cheers,
Chris.