Mailinglist Archive: opensuse-packaging (155 mails)

< Previous Next >
Re: [opensuse-packaging] Re: Proper version scheme for packages from git, hg, svn, ...
  • From: Adam Spiers <aspiers@xxxxxxxx>
  • Date: Tue, 14 Jan 2014 15:36:06 +0000
  • Message-id: <20140114153606.GJ16058@pacific.linksys.moosehall>
Jan Engelhardt (jengelh@xxxxxxx) 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-to-software-projects/
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups