Hi, On Wed, May 17, 2017 at 5:01 PM, Mathieu Bridon <boche...@daitauha.fr> wrote: > On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote: >> IMO this is a completely broken and over-complicated workflow. For >> long term contributors, having their own remote can be >> understandable. >> But for one-time contribs? > > One-time contributions can be done entirely in the web UI, for example:
Ok. Sorry but no. I code in my text editor, not in my browser. And I am not going to change that. The web GUI has some great stuff that we can't do at this time on a text editor. Like I cannot review and comment line by line a patch. So I do it in the browser, out of luck. But that doesn't mean that I am going to push my workflow and start coding in a browser. It's nice that it's possible for others, but it should only be used in very rare cases. > 1. find the file in the source code you want to modify > 2. click the "edit" button > 3. "You don't have permission to edit this file. Try forking this > project to edit the file." -> click the "fork" button > 4. you get presented with a web-based editor for the file you wanted to > edit, in your fork, do your changes, write a commit message, click > "commit changes" > 5. this **automatically** opens a form to create a merge request, you > can just submit it > > For one-time contributions, this is a **much** simpler workflow than > cloning the repository, making the changes, committing the change, > making a patch, then sending the patch by email/bugzilla. It even > enables non-technical people to contribute! Well much simpler for developers who like to push buttons. We are many who don't like this. Let's not generalize! Also such patches are acceptable for very simple stuff. For instance typo fixes, or string fixes, or similar. But other than this, even one-liners of actual code, I don't want to encourage people who do things without actually testing (and expecting us to test for them). When I do a fix to a code, even if it's my code, even if it's a very simple code and I'm like 100% sure that it's good, I compile (when on compiled code) and run the code to test if that does what I expected and did not bring undesirable side effects that I failed to foresee. This is also the minimum I expect from contributors to a code I maintain. So in the end, this feature of editing and pushing everything on the web GUI should be used very rarely. > And if I send you a patch, you might find it easier to test it locally. > But that completely bypasses your pre-merge CI. CI test basic stuff like "it builds", and "the tests don't fail". But there is much more in a patch than this. There is code logics. Yes I test contributed patches locally after the first visual check of the diff. I assume/hope others do the same. Of course, you could say that the tests should include every case. But the fact is that if there is a bug that was not seen before, that probably means there is no tests for it (otherwise we'd have seen it!). Even if we add a test, then we have to check first that the test is fine by building locally. Back to square 1. Also in reality, everyone knows that tests cannot possibly test each and every piece of a code, especially in a project as big as GIMP. So it's not that I find it "easier", it's that I find it totally complementary and non-optional. Jehan > With a pull-request, your CI can run **before** merging any change, > which means you can try and keep master always building and with > passing tests. > > > -- > Mathieu -- ZeMarmot open animation film http://film.zemarmot.net Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list