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 ?
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 ?
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.
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.
Demanding that your patch is more important than the other things a volunteer-maintainer might need to do with their time
I thought you were trying to be realistic about the situation. We need not invent additional problems.
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...
Seriously, I find it weird that I even have to write this.
You don't "have" to.
I speak only for myself and my own observations.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC