Hi Paolo, On Thu, 10 Aug 2017, Paolo Ciarrocchi wrote: > Il 10 ago 2017 11:39 AM, "Johannes Schindelin" <Johannes.Schindelin@xxxxxx> > ha scritto: > > > > Footnote *1*: It is no secret that I find our patch submission less than > inviting. Granted, *I* use it. *I* did not have problems entering the > mailing list. But then, my mails were not swallowed silently, because my > mail program does not send HTML by default. And prepared by the German > school system (I learned the term "sugar coating" only when exposed to > some US culture), I had little emotional problems with being criticized > and not thanked for my contribution, I persisted nevertheless. The opinion > that the Git contribution process is a lot less inviting than it could be > is not only my view, by the way. I hear this a lot. I give you that we are > not quite as textbook "keep out from here unless you look like us, smell > like us, talk like us, have the same genital setup like us" as the Linux > kernel mailing list, but we are in a different universe compared to, say, > the Drupal community. And their universe is a lot nicer to live in. > > > Isn't SumbitGit a possible answer to your doubts (I strongly agree with > you) about the current development process? No. I hate to say that SubmitGit neither integrates well with GitHub Pull Requests (code comments on GitHub are approximately 1,523x easier to write, read, associate with the actual code, and see the current state of, compared to the mailing list, and SubmitGit does not even hint at integrating with that user experience). Also, the barrier to start using SubmitGit is rather high. If you open a Pull Request on github.com/git/git, you get *no* indication that SubmitGit is an option to *actually* get the code into Git. There are also concerns about required permissions that Junio Hamano himself would not accept. Now, let's assume that you submitted the code via SubmitGit. The challenges of the patch submission process do not end there, yet SubmitGit goes home and has a beer. But the hard part, the discussions on the mailing list, the status updates in the completely separate What's cooking mails, the missing links back to the original source code (let alone the information in which worktree on your computer under which branch name that topic was developed again?), the diverging mail threads, the "rerolls" that should not forget to Cc: all reviewers of previous rounds, all that jazz is still all very, very manual. And even if there was an easier path from having a local branch that works to finally getting it onto the list in the required form, your mail is an eloquent example of one of the most preposterous hurdles along the way: we pride ourselves with the openness we demonstrate by communicating via a mailing list, everybody has a mail address, amirite? But of course, HTML mails, like, about 130% of all mails on the internet (or so it feels), including yours, are dropped. Silently. Not so open anymore, are we. It is all so frustrating, really. I work in a team (Visual Studio Team Services, you can think of it as kind of a Microsoft take on Git hosting plus a lot of other tooling) where we get really, really positive feedback regarding our user experience, in particular the frequent enhancements to PRs. It is really powerful to open, review and merge PRs, interact with other developers, see the state of PRs and their respective discussions, open and resolve issues, automate workflows and build tasks [*1*]. And then I try to convince people here on this mailing list that it really makes a difference if you start using tools to lighten the load of everybody, and... little changes. At least thanks to Lars Schneider's incredible efforts we have Continuous Testing (I know how much time he spent on this, it is another thing deserving the label "preposterous", and I know how much time I spent on top to add the Windows part which mostly works). If only we could push it further to true Continuous Integration. Or at least to accepting PRs from professionals who simply have no time to fight with our patch contribution process and whose expertise we lose as a consequence. Ciao, Johannes Footnote *1*: The funniest part about this is that I do get mails about all of this all the time. When I am pulled in as a reviewer. When a build failed. When a previously failing task was fixed by a new build. When somebody responded to my comments. The difference to the mailing list-centric approach is of course that those mails are only notifications, and link back to the tool appropriately supporting what I, the user, want to get done.
