Jan Engelhardt (jengelh@inai.de) wrote:
The intent was to say: Requestion a github submission would seem to require registering at Github, which _poses_ an entry barrier.
Correct. And as I already pointed out, sometimes entry barriers are good, because they help maintain a high quality of work within the project.
A non-git solution would also pose an entry barrier.
What kind of barrier are you thinking of, and how is that relevant here?
In both cases significant enough to just walk away.
I really cannot understand this. I have already given two very clear benefits of adhering to a github-oriented workflow, namely transparent peer code review, and automated testing via Travis. Despite this you have stated, without any explanation why, that you are not prepared to spend the 60 seconds required to create a github account, and yet you are quite happy to dedicate significantly more time arguing that there is some kind of barrier to entry. I really don't want to believe that you are deliberately being awkward, but I'm struggling to see any other explanation right now. Please help me understand why using github is such a deal-breaker for you!
http://blog.adamspiers.org/2012/11/10/7-principles-for-contributing-patches-... says
"Submit patches in the way upstream wants to receive them"
Yes, but tread lightly.
A good maintainer should be prepared to accept nonperfect submissions massage the code to his needs, doctrines or development environment.
That's sometimes true, although it's an over-generalization. Having said that, I wouldn't be advocating a workflow which involves code review, or wouldn't have already reviewed your contribution, unless I believed that initial submissions are sometimes nonperfect and that a constructive two-way dialogue between maintainer and contributor are sometimes necessary. The success of this feedback loop depends on the willingness of both parties to iterate until there is consensus. It will *not* succeed if the contributor simply throws a bunch of patches over the wall and then walks off expecting the maintainer to do the rest of the work.
Rejecting a patch that fails to apply with TortoiseSVN even though it is totally compliant to the unified diff specification is something not within my maintainer ideals.
Please can you explain how that is relevant here? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org