Re: Proposal to deploy GitLab on

On Wed, 2017-05-17 at 17:44 +0200, Jehan Pagès wrote:
On Wed, May 17, 2017 at 5:01 PM, Mathieu Bridon <bochecha daitauha fr
On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote:
IMO this is a completely broken and over-complicated workflow.
long term contributors, having their own remote can be
But for one-time contribs?

One-time contributions can be done entirely in the web UI, for

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

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]