I've already sent a note to the board raising the topic of "Disruptive Infrastructure Changes".

There's just so much wrong about this and about the way this was announced that it's hard to remain completely professional.  So I'll refrain from ranting and saying things I'll no doubt regret later.


On 18.12.2020 10:14, Mickael Istria wrote:


On Fri, Dec 18, 2020 at 10:01 AM Thomas Wolf <thomas.w...@paranor.ch <mailto:thomas.w...@paranor.ch>> wrote:

    Yes, we can. However: triggering CI builds will be different; and
    I fear
    changes in the builds will be required to get them triggered properly.
    Reporting build results may also work differently. In any case the
    GerritTrigger won't work.


Indeed, projects would have to add some Jenkinsfile and recreate jobs in CI as "multi-branch pipeline". It's an effort, but if you ask me, the result is better, more "configuration-as-code" which makes maintenance easier and more easily distributed.

    I'm not keen on having to donate more of my volunteer time to
    revamp CI
    builds and their integration with a git server.


Yes, that's something I think our Committer Representative need to mention. The amount of effort it's asking the community to do seem significantly higher to the amount of effort leaving some Gerrit server alive.

    One crucial shortcoming of the PR model of Gitlab/Github is that
    there
    is no support for PRs depending on other PRs. On Gerrit, I very often
    have whole sequences of changes that depend on each other. This,
    and the
    ability to group changes by topic, are two crucial features of Gerrit.


Ack.

    Apart from that, Gitlab has a "squash on merge" feature for
    merging PRs
    (or merge requests, as they call it), which makes it easier to
    deal with
    clean-up commits in a PR (no need for amending and force pushing).


GitHub too, has "Squash and Merge" and "Rebase and Merge" actions, and repo admin can set one of them as default.

    Asking contributors to amend and force push means the main benefit of
    using a PR model falls away, namely that contributors just know
    how to
    contribute since "everybody" knows the PR model from Github.


That was my first fear when I started working on GitHub projects, but actually contributors we got on those projects are OK squashing or amending their contributions. It hasn't been a concrete problem so far. We just need to explain, just like we often need to explain to push to "refs/for/master", keep Change-Id and so on with Gerrit.

_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Reply via email to