Re: Proposal to deploy GitLab on gnome.org

[Jehan Pagès <jehan marmottard gmail com>]

Hi,

On Wed, May 17, 2017 at 5:01 PM, Mathieu Bridon <bochecha 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