On Wed, 2017-05-17 at 17:44 +0200, Jehan Pagès wrote: > 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.
That's fine, me too. But you're not a one-time contributor to GNOME, are you? Remember that I'm responding to your thread about how the fork+merge- request workflow is too complex for trivial one-time contributions. > > 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. Well yes, that's exactly what this thread was about: simple one-time contribution that are so trivial that they make the fork+merge-request workflow prohibitive. > 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). That's why you have a CI that runs before merging. > > 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. A CI can do pretty much anything you want it to, it's not limited to "basic stuff" at all. > 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. And the person doing that is not the one-time contributor, but you, the maintainer. Seriously, you started complaining that the fork+clone is too complex for trivial one-time contributions, and now you've completely changed the goal-posts, complaining how the wokflow that was specifically designed for trivial one-time contributions doesn't allow bigger changes. -- Mathieu _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
