Keep in mind I tried to extract the most important points, to have an effective list of actions to take.
-------- Original Message --------
Subject: Re: Proposal to deploy GitLab on gnome.org
Local Time: May 17, 2017 9:02 PM
UTC Time: May 17, 2017 7:02 PM
From: jehan marmottard gmail com
To: Mathieu Bridon <bochecha daitauha fr>
Carlos Soriano <csoriano protonmail com>, desktop-devel-list gnome org <desktop-devel-list gnome org>, Bastien Nocera <hadess hadess net>
Hi,
On Wed, May 17, 2017 at 5:59 PM, Mathieu Bridon <bochecha daitauha fr> wrote:
> 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
>> > 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?
GNOME is a lot of projects. I have been a one-time contributor to
several GNOME projects and will likely continue to do so for the same
or other projects. Even though I have a GNOME git account, I
(obviously) don't push to random projects which never heard of me. I
am still going through the normal bugzilla procedure and will continue
to go through the normal gitlab procedure if the migration is done.
> 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.
Since I kind of started the discussion on this topic, it's good to
assume I know what it is about. I never discussed about trivial
contributions, and I don't think to remember anyone else discussing on
this topic as an answer to my emails.
So no, the discussion was on the contribution workflow (for people who
don't push directly, but will make bug reports/merge
requests/patches/etc. Most of them being one-time contributors).
>> 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.
Yes you can do tests for a lot of things. Anything is scriptable. It
doesn't mean that everything is scripted in tests. Otherwise software
who succeed all the tests would have no bugs by definition.
So we still need to test many things manually.
>> 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.
Yes, which is why I say that I still test the patches locally before
pushing and don't rely only on CI.
> 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.
Once again, I was not speaking about trivial changes. Quite the
opposite since we were discussing about the issue of rebuilding a
tree, what happens on timestamps when you checkout a branch based on
older code, etc.
Also yes, sometimes the discussions evolve anyway. That's how
discussions work. Someone says something, that makes someone else say
something related but different, and so on. Fortunately. That would be
very boring if we were to discuss on the exact same point of detail
for 10 emails.
> Seriously, you started complaining […] complaining how […]
Please, let's keep it civil. I am not complaining. The whole point of
this email thread was to hear members' comments and inputs. So I gave
mine. I also explained that I still think it is a good change in many
ways, and I listed a few features that I really appreciate in systems
like gitlab. But then I also list some of my worries. One of these
worries (for me) is about the workflow which is encouraged by gitlab
and which I really dislike. And I explained why. I also explained that
I already have workarounds for the problems of this workflow, and what
I would probably do (so it's not a blocker, just annoying). Yet I
still explain the worries; that's how things may get improved in the
future, hopefully (if you keep on just working around issues on your
side, things never get better upstream).
With some emails, I even discovered some interesting feature of gitlab
(possibility to fetch merge requests without adding remotes, which is
a very interesting feature). I believe this was also one of the goal
of this thread: discussing about our worries and with responses of
those who know better, maybe discovering this tool that many of us
don't know that well. And who knows, maybe appreciate it more then! Or
at least ease our main worries.
Until now, the discussion was very friendly and I was appreciating the
discussion with the other people and the proposition.
Could we please stay that way? I don't get on mailing lists to be insulted.
Jehan
>
> --
> 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
