Re: [platform-dev] Deprecating Bugzilla and Gerrrit?

[Torkild U. Resheim]

> 18. des. 2020 kl. 11:08 skrev Thomas Wolf :
> 
> On 18.12.20 10:34 , Ed Merks wrote:
>> I've already sent a note to the board raising the topic of "Disruptive 
>> Infrastructure Changes".
> 
> BTW, I just noticed that MediaWiki is apparently also scheduled to go
> away.
> 
> EGit generates its doc bundle from the wiki pages. Obviously that won't
> work anymore then. Even if the content is automatically migrated 100%
> correctly to Gitlab, EGit will have to change its maven build to
> generate from the Gitlab wiki, which uses different syntax. Does Mylyn
> Docs have a parser/generator that fully understands the Gitlab flavor of
> Markdown?

No, but there is a CommonMark parser so you have the basic bits in GitLab 
Markdown covered. GitLab has added quite a few extras, such as LaTeX equation 
support, table of contents and diagrams.

Best regards,
Torkild



signature.asc
Description: Message signed with OpenPGP
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Deprecating Bugzilla and Gerrrit?

[Mickael Istria]

EGit generates its doc bundle from the wiki pages. Obviously that won't
> work anymore then. Even if the content is automatically migrated 100%
> correctly to Gitlab, EGit will have to change its maven build to
> generate from the Gitlab wiki, which uses different syntax. Does Mylyn
> Docs have a parser/generator that fully understands the Gitlab flavor of
> Markdown?
>

Can you please bring these concerns to EGit mailing-list?
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Deprecating Bugzilla and Gerrrit?

[Ed Merks]

Yes, I did not mean to suggest that you/we should not have or continue 
to have the discussion here about the impact on the platform.


But of course the impact is much broader than the platform, so I'm 
highly likely to rapidly degrade into a very long, tangential, and 
poisonous rant about the four projects, the three builds, and the dozens 
of build jobs that I manage for free, as a one-man traveling show, 
purely for the entertainment and gratification of others.  As such, I am 
just beside myself with eagerness to revisit it all in order save 
someone else some time and to live a world based purely on the latest 
greatness of consolidation.



On 18.12.2020 10:42, Mickael Istria wrote:



On Fri, Dec 18, 2020 at 10:34 AM Ed Merks > wrote:


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.


Thanks Ed for voicing concerns to the EF in committers' name.
I think we can and should keep chatting here about the suggested 
change for Eclipse project specifically, identify the technical needs 
other infrastructures wouldn't meet and the induced change cost, 
operational cost, risk vs the things that seem affordable or 
profitable in the infra change. I think this discussion in beneficial 
for the Eclipse project itself, but will also help EF in identifying 
what specific parts of the infra change are actually more challenging 
for committers so the plans can adapt accordingly.


___
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

Re: [platform-dev] Deprecating Bugzilla and Gerrrit?

[Thomas Wolf]

On 18.12.20 10:34 , Ed Merks wrote:
I've already sent a note to the board raising the topic of "Disruptive 
Infrastructure Changes".


BTW, I just noticed that MediaWiki is apparently also scheduled to go
away.

EGit generates its doc bundle from the wiki pages. Obviously that won't
work anymore then. Even if the content is automatically migrated 100%
correctly to Gitlab, EGit will have to change its maven build to
generate from the Gitlab wiki, which uses different syntax. Does Mylyn
Docs have a parser/generator that fully understands the Gitlab flavor of
Markdown?

Cheers,

  Thomas

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

Re: [platform-dev] Deprecating Bugzilla and Gerrrit?

[Christoph Läubrich]

> And of course: EGit currently has fairly good integration with Gerrit,
> but none for creating PRs directly from within Eclipse.

I can only tell from my point of view that I never had any need for 
toolsupport to create a PR on github while even with Egit Gerrit support 
its not always that easy...


Fork Repo > create branch > push changes > click on the create PR link

works with any tool (egit, command line, whatever..) without any 
additional setup.



Am 18.12.20 um 10:01 schrieb Thomas Wolf:

On 18.12.20 09:07 , Mickael Istria wrote:
[...]
[On Gitlab vs. Gerrit:]

I think we can just learn new ways here.


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.


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


[...]
I found that one can easily implement with GitHub similar workflows as 
the ones mandated by Gerrit; it's mostly a matter of asking 
contributors to put a single commit on their topic branch and to use 
`git commit --amend` and `git push --force`, or to squash commits to 
modify the branch. 


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.


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).


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.


And of course: EGit currently has fairly good integration with Gerrit, 
but none for creating PRs directly from within Eclipse. There's open 
Bugzilla entries for that, but doing that right is quite a bit of work.

So be prepared to find that pushing changes from Eclipse to Gitlab will
be slightly less convenient that just "Push to Gerrit..." for quite a 
while.


Cheers,

   Thomas
___
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

Re: [platform-dev] Deprecating Bugzilla and Gerrrit?

[Mickael Istria]

On Fri, Dec 18, 2020 at 10:34 AM Ed Merks  wrote:

> 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.
>

Thanks Ed for voicing concerns to the EF in committers' name.
I think we can and should keep chatting here about the suggested change for
Eclipse project specifically, identify the technical needs other
infrastructures wouldn't meet and the induced change cost, operational
cost, risk vs the things that seem affordable or profitable in the infra
change. I think this discussion in beneficial for the Eclipse project
itself, but will also help EF in identifying what specific parts of the
infra change are actually more challenging for committers so the plans can
adapt accordingly.
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Deprecating Bugzilla and Gerrrit?

[Thomas Wolf]

On 18.12.20 10:14 , Mickael Istria wrote:
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.


That's exactly what I meant: you have to explain and get people to use a 
special workflow. It's neither more nor less difficult than the Gerrit 
way, but again it needs explaining, and the idea that "people just know 
what to do; onboarding is simpler" just goes out of the window.


Cheers,

  Thomas


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

Re: [platform-dev] Deprecating Bugzilla and Gerrrit?

[Ed Merks]

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 > 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

Re: [platform-dev] Deprecating Bugzilla and Gerrrit?

[Mickael Istria]

On Fri, Dec 18, 2020 at 10:01 AM Thomas Wolf  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

Re: [platform-dev] Deprecating Bugzilla and Gerrrit?

[Thomas Wolf]

On 18.12.20 09:07 , Mickael Istria wrote:
[...]
[On Gitlab vs. Gerrit:]

I think we can just learn new ways here.


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.


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


[...]
I found that one can easily implement with GitHub similar 
workflows as the ones mandated by Gerrit; it's mostly a matter of asking 
contributors to put a single commit on their topic branch and to use 
`git commit --amend` and `git push --force`, or to squash commits to 
modify the branch. 


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.


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).


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.


And of course: EGit currently has fairly good integration with Gerrit, 
but none for creating PRs directly from within Eclipse. There's open 
Bugzilla entries for that, but doing that right is quite a bit of work.

So be prepared to find that pushing changes from Eclipse to Gitlab will
be slightly less convenient that just "Push to Gerrit..." for quite a while.

Cheers,

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

Re: [platform-dev] Deprecating Bugzilla and Gerrrit?

[Mickael Istria]

On a similar thread in tycho-dev mailing-list, Christoph did point out "a
new hope": GitLab has semantic about issue dependencies:
https://docs.gitlab.com/ee/user/project/issues/related_issues.html .
However, I don't know if this allows to link to issues across several
GitHub repositories (eg can Platform link to Tycho or the other way round)?
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Deprecating Bugzilla and Gerrrit?

[Mickael Istria]

Hi,

On Fri, Dec 18, 2020 at 12:45 AM Alex Blewitt 
wrote:

> A mail sent out by Denis suggests that Bugzilla and Gerrit are not long
> for this (eclipse) world, and that we will all be able to use GitHub or
> GitLab:
> https://www.eclipse.org/lists/eclipse.org-committers/msg01247.html
>

I've sent an answer to Denis, CC'd the committer representatives about some
of my personal concerns with moving existing projects such as Platform away
from Bugzilla, as I believe Bugzilla has enabled workflows (queries,
dependency relationship...) that would be almost impossible to implement
with the other suggested trackers. I'm afraid forcing a move to Bugzilla
and losing such workflows would be extremely bad for the Eclipse project,
but the concerns are voiced. Ideally, the EF can provide a very safe
migration path of all data and of *all workflows*, and we just adapt a bit
and everyone is happy; but I'm not convinced such a safe migration path
exists at the moment and I'm not sure those can even be implemented without
evolution on GitLab or GitHub.

I think this means we lose access to the last couple of decades of bug
> references
>

I don't know the details, but I somehow trust that EF will provide some
proper ways to migrate all data, or at least to still reference it (ie
keeping bugzilla read-only). EF has a decent track record of such
migrations IMO, I'm not too worried about the data -although we definitely
need to keep an eye on it-, I'm more worried about the workflows as
mentioned above. GitLab and GitHub trackers are nice, but they seem
semantically very weak compared to Bugzilla and the Eclipse project cannot
really deal efficiently with such weak trackers efficiently.


> and won’t be able to do per commit review and testing any more.
>

I think we can just learn new ways here. I love Gerrit, a lot, and I think
it is the best review tool and I think that the hype around GitLab and
GitHub is only about the "social" part and CSS but that their underlying
model is not half as good as Gerrrit; but as I've used GitHub, I found that
one can easily implement with GitHub similar workflows as the ones mandated
by Gerrit; it's mostly a matter of asking contributors to put a single
commit on their topic branch and to use `git commit --amend` and `git push
--force`, or to squash commits to modify the branch. Then the Jenkinsfile
integration will react properly to such updates, similarly to what Gerrit
provides.
m2e, tm4e, Wild Web Developer and Corrosion use that approach, and the
feedback (review, CI) approach is comparable to what's provided with Gerrit.
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev