On 26/09/13 14:26, David Kastrup wrote:
So Graham organized the infrastructure where this would not easily
happen again in the same manner, and the Contributor's Guide reflects
it.
But we haven't exactly seen a flurry of patches from newcomers appearing
on the lists. Of course, part of the reason is that any good mailing
list citizen will, before contributing, study some of the mailing list
archives to figure out how things are usually done.
There may be another side to this. Post-GitHub there has been a pretty
substantial increase in the user-friendliness of DVCS. What's currently
advocated in the Contributors' Guide stands in stark contrast to the ease of
contribution (and contribution management) that many people experience as the
norm now.
I'll give one example, because it's not clear to me that people have understood
my past objections to git-cl etc.
Here's a currently-open pull request of mine in another project that I
contribute to:
https://github.com/D-Programming-Language/phobos/pull/1533
You'll see that below the summary there is a report from the project
auto-testing facility, with a link to a more detailed overview of the test results.
What that means is that -- as a contributor -- I just submit a pull request via
GitHub's UI. Testing is taken care of for me, and the feedback is there and
integrated into my pull request for me to read and (if necessary) respond to.
Or, if I were a reviewer, I again wouldn't need to worry about the testing,
except as information useful for my review.
In other words testing is a completely automated process that requires no manual
intervention from anyone and no changes to the standard GitHub workflow.
Contrast that with git-cl, and also bear in mind how user-friendly GitHub makes
pull request submission and review.
Unfortunately in this case the tool is a custom-written one for the project,
because they had some very specific requirements and at the time no one tool
supported all of them. It's possible of course that now the existing tools
would satisfy what they needed. So, it's not likely to be directly useful for
Lilypond, but it _is_ a very good model of how testing can be integrated into
code review in a non-intrusive way.
Similarly, the project's bugzilla listens in on pull requests and can be
automatically updated when an appropriate pull request lands (the requirement is
that the pull request title contain the issue number, so in this case it's not
100% automatic, but then, how could it be?).
All of this is orders of magnitude more user-friendly than what Lilypond
currently operates and I don't think I'm wrong in saying that this kind of easy
DVCS experience is now the expected norm for many developers.
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel