Using gerrit or github for review?

[Karsten Merker]

On Mon, Jul 13, 2020 at 06:05:42PM -0400, Corey Clayton wrote:
> On Mon, Jul 13, 2020 at 12:25:42PM -0600, Simon Glass wrote:
> 
> > At present U-Boot uses the mailing list for patch review. What do
> > people think about trying out geritt or github for this? I'd be
> > willing to do a trial with the -dm mailing list.
> 
> This is both my first message to the mailing list and my first
> email sent using mutt.  I'm hoping to eventually participate
> with patches and reviews but the mailing-list-driven
> developement model has been a barrier for myself an probably
> many others.  I'm slowly trying to climb over it now but some
> will never find the time.  Perhaps a good question is: How long
> does it take to learn the mailing-list workflow vs the github
> workflow?
> 
> If u-boot was using github, I would have contributed long ago
> and I suspect there are others in the same bucket.  Thats my
> perspective at least :)

Hello,

to provide a different perspective: if U-Boot would have done
everything inside github instead of using its traditional
mailinglist-based workflow, I would never have contributed to
U-Boot, and moving everything from the mailinglist to github
would make any future contributions infeasible for me.

The github workflow makes it impossible to open an issue or to
comment on an existing issue or to provide feedback about a patch
without being a github customer, and becoming a github customer
is not an option for me (and quite a number of other open-source
developers) as the github TOS contain clauses that I (and other
people) consider completely unacceptable.

Besides the aforementioned points I am generally concerned about
the closed nature of the github issue- and pull-request system. 
While it is of course easily possible to move a git repo from
github to somewhere else, it is as far as I know (please correct
me if I should me misinformed here) not possible to export the
comments and discussions in issues and pull requests in any
meaningful way to some other hosting platform, which creates a
strong vendor-lock-in once a project starts using the github
issue and pull-request facilities.  With the traditional
mailinglist-based workflow on the other hand, moving everything
to another hosting platform is trivial, so vendor-lock-in
is not a problem there.

Another problem that I see in the github workflow is that it
requires being online all the time while the mailinglist-based
workflow makes it easy to read and comment on patches while being
offline.  I am sure that many people will now think "everybody is
online all day nowadays", but that's not true everywhere.  I for
example travel a lot by train and use the time on the train for
catching up with current developments and for reviewing things. 
Where I live, for most practical purposes being on the train
effectively means being offline as far as modern web applications
are concerned.  Availability of mobile internet access is spotty
at best, and if one has internet connectivity inside the train at
all, it is often so slow that using it for interactive work on a
web interface is not feasible.  Receiving, writing and sending
emails on the other hand works without problems even with spotty
and slow internet connectivity.

Regards,
Karsten
-- 
Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe
meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt-
oder Meinungsforschung.