I'm glad this topic is discussed because I also questioned myself which workflow should be followed exactly.
I agree with Alexander that not every commit/PR needs an issue.
It always felt a bit cumbersome to me that each Gerrit needed (or at least should had) an Bugzilla entry, because for changes like simple clean-ups the gain of having a Bug is IMHO very little because they usually are not rejected so it felt only like ceremony. And, at least for me, it is often simpler to discuss things with some code instead of describing everything in the text and having the intended change right at hand is often the simplest way (I think this is one reason why many discussions moved from Bugzilla to Gerrit). Opening an issue only seems useful to me if I either only want to report something without the intend to resolve it by myself (at all or at least not in the near future, so basically a reminder) or if I plan to make greater changes and want to discuss them with others to prevent myself (and others) from doing unnecessary work that is either completely rejected or only accepted after major rework.
I understand that the one-bug-per-change rule was also necessary because Bug-Tracker and Code-Review was split, but since in GitHub issue-management and code-review is at one place I don't thing is not an issue anymore.
And even if one encounters regressions from a change one can still comment on the PR even after it was merged/closed.
However I also think it would be good to add a reference to the PR from which the commit was submitted.
This is IMHO even more important than having an issue referenced, because as mentioned above I expect issues to become less important (unless we still enforce one issue per PR). Furthermore one PR is directly associated with exactly one repo and cannot span multiple repos and if there is an issue associated with the change it can be linked in the PR (IMHO linking issues and PR by mentioning one in the other gives more context than just mentioning issues in the commits).
Using "Squash-And-Merge" GitHub already suggest to add the PR number by default, which is why this is my preferred way of submitting issues. But it only adds the PR number and also sets the committer to "GitHub <noreply@xxxxxxxxxx>" (but IIRC only if there are really multiple commits that have to be squashed).
Nevertheless I also think that full URLs would IMHO be better, because it would require no magic in EGit/Eclipse to find them quickly and would also work if one inspects a commit from somewhere else.
But instead of asking (and waiting for) GitHub to adjust the web-interface to our needs (and probably they won't do that at all), we could use GH action-workflows/bots to adjust the submission to our needs and guidelines.
For example in the open-jdk/jdk repo PRs seem not to be submitted via the web-interface but via command comments (like "/integrate") as you can see for example in [1].
We could create our own commands, for example "/integrate-squash" and "/integrate-rebase".
They could add the full PR-URL at the bottom of each submitted commit (similar to what Gerrit is doing now) and also set the person that commanded the integration as the committer (instead of the GH-bot). But this could be a bit tricky because AFAIK the github-context only knows the user name of the person that triggered an event. And we could add more if we need more.
Such workflow could for example be added as "reusable-workflow" [2] to eclipse-platform/eclipse.platform.releng.aggregator and then be referenced by other eclipse projects.
The latter command could be used if the commit sequence should be retained.
Which brings me to another question:
How should we handle changes that span multiple commits? Gerrit automatically detected and displayed the relation-chain between subsequent related commits.
As far as I know, in GH I cannot easly create related PRs, can I? So I assume in this case a PR would have to consist of multiple commits that are force-pushed in case of amendments?
And regarding the E-Mail notifications, please make them optional or at least only send one mail at the end.
For example for PDE I get four e-mails at the moment for each patch-set in gerrit (and at least the FAQ told me that there is no way to disable them). I like the silence of GitHub in this regard.
[1] - https://github.com/openjdk/jdk/pull/7927
[2] - https://docs.github.com/en/actions/using-workflows/reusing-workflows
Gesendet: Donnerstag, 24. März 2022 um 17:35 Uhr
Von: "Christoph Läubrich" <laeubi@xxxxxxxxxxxxxx>
An: platform-dev@xxxxxxxxxxx
Betreff: Re: [platform-dev] Github workflow
If you don't like to suggest to Egit to add some magic, you can suggest
to Github to add a similar header:
https://github.community/
Am 24.03.22 um 17:30 schrieb Andrey Loskutov:
>> Gesendet: Donnerstag, 24. März 2022 um 17:03 Uhr
>> Von: "Christoph Läubrich" <laeubi@xxxxxxxxxxxxxx>
>> An: platform-dev@xxxxxxxxxxx
>> Betreff: Re: [platform-dev] Github workflow
>>
>> Sorry for confusion then I probably don't get it. What has Egit/Eclipse
>> Ui to do with gerrit?
>
> Nothing.
> I use Egit to read the history.
> Because I work with my code from within my IDE, not with github.
> Gerrit writes url of the PR to the commit header.
> I can see this url in egit on every commit.
> I can click it and go directly to the PR in the browser.
>
>> If I check with with my eclipse SDK things like "Bug xxxx" are not
>> linked even though they are on git-eclipse or do you mean
>>
>> Reviewed-on:?
>>
>> in the commit message if it was merged through gerrit?
>
> Exact, see
https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=43187fa1ce25eb04c7fe417ffd3e1f7bb025577f for example
>
>> Github provides similar and as EGit already knows how to handle Github
>> PRs it should be possible to show such a link, the git magics is
>> described here:
>>
>>
https://stackoverflow.com/a/17819027/9503281
>
> No, that's completely different story.
> It is not in the commit, it adds a lot of "dead" remote branches to your history, making it unusable.
> See the config I've used and result I've got.
> So in short, there is no way to get same user experience with github right now.
> And I for sure don't want this dead pull branches to show up in my history view.
>
>> So your best bet would be to ask Egit to add support for this (probably
>> there is already support for this but I have never used/found that).
>
> There is nothing, I'm using latest nightly.
>
> Kind regards,
> Andrey Loskutov
>
> Спасение утопающих - дело рук самих утопающих
>
>
https://www.eclipse.org/user/aloskutov
>
>
> _______________________________________________
> platform-dev mailing list
> platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
