Taking care of infrastructure: code review

[yangoon (Mathias Behrle)]

@nicoe

The tool used to manage the source has never been what stopped me from contributing because in the end they all look the same to me.

That is a great advocation to do the evaluation of the infrastructure independent from the VCS. Exactly what I wanted to propose.

@nicoe

in case it happens we already have some backups.

Backups of what and what problem should they solve when mercurial disappears one way or the other?

[coogor]

@nicoe

@yangoon

Other community members should make their voice heard as well.

If you don’t contribute because it’s using mercurial instead of git (or subversion or fossil or whatever your preferred VCS is) quite frankly you’re the one to blame.

Please, lets keep a friendly approach in that discussion.
For you as power user, Nicoe, its probably a don’t-care which VCS you use.
For non-developers like me a pull request in git*whatever is way easier than the current workflow in Tryton. So a change in the platform can attract more users to contribute - next to the future-proof environment

[nicoe (Nicolas Évrard)]

@yangoon

That is a great advocation to do the evaluation of the infrastructure independent from the VCS. Exactly what I wanted to propose.

Yes but on the other hand I still have some preferences (just like you do BTW ). So if we have to put some priorities, the taste of the people that are actually contributing have obviously more weight than from people that might contribute.

Moreover switching to something else comes with a cost that we have to minimize.

@yangoon

Backups of what

What I meant is that if mercurial were to disappear from the surface of the earth, we still have the github clone. So yes it would be a PITA but the development could go on.

@coogor

Please, lets keep a friendly approach in that discussion.

I was not targeting Matthias by this message because I know what he does for debian.
I should have made clearer that “you” meant any contributor that finds a bug, fix it and then refuse to submit a patch because he has to type “hg clone” instead of “git clone”.

@coogor

For you as power user, Nicoe, its probably a don’t-care which VCS you use.
For non-developers like me a pull request in git*whatever is way easier than the current workflow in Tryton.

I disagree with this.

It depends on the kind of contribution. If we’re talking about documentation I agree that having a friendlier environment might help (although IIRC @pokoli has already offered to do all the tedious work provided that you send him an email with your document … nobody helped that way).

For code, I don’t see the difference between uploading a patch to the bugtracker, using a CLI to submit to rietveld or pushing on your clone and then pushing on a button in a web interface to create a PR.

If people really want to contribute they won’t be stopped by this.

[udono]

@albert

@udono

@albert

And also does not work when using as many repositories as Tryton does.

What is the problem?

Pull requests only work for a single git repository, but currently Tryton uses Rietveld with patches that affect several repositories.

For me this is the most important argument in the discussion of the actual self maintained infrastructure vs. git/github/gitlab. Because the code quality of Tryton comes IMHO in a great part from our code review abilities. in Tryton it doesn’t hurt more than nessessary to change conceptions over many modules or to maintain similarities in two client apps. Please note, that all needed changes can be reviewed with our actual tool set in one and only one code review, all in one place.

With a pull request centric workflow like git/github/gitlab we would have many separated and code reviews independent spread all around without any connection.

Finally, I follow @ced in his initiative and we should invest the two weeks development time to replace Rietveld by a similar functionality.
All other arguments speaking for the change to git/github/gitlab workflow are IMHO minor to the main argument, having code reviews over many repositories in one and only one place.