Re: [platform-dev] Github workflow

[Hannes Wellmann]

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 " (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" 
An: platform-dev@eclipse.org
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" 
>> An: platform-dev@eclipse.org
>> Betreff: Re: [platform-dev] Github workflow
>>
>> Sorry for 

[platform-dev] eclipse.platform.runtime & eclipse.platform.resources moved to GitHub

[Mickael Istria]

Those Git repository are now moved to GitHub:
https://github.com/eclipse-platform/eclipse.platform.runtime and
https://github.com/eclipse-platform/eclipse.platform.resources . Please
immediately set you `upstream` repo url to use GitHub instead of Gerrit
$ cd /path/to/eclipse.platform.runtime
$ git remote set-url upstream g...@github.com:
eclipse-platform/eclipse.platform.runtime.git
$ cd /path/to/eclipse.platform.resources
$ git remote set-url upstream g...@github.com:
eclipse-platform/eclipse.platform.resources.git

Also update your development files (Oomph profiles, *.psf files...) to
adjust your workflow.

-- 
Mickael Istria
Eclipse IDE  developer, for Red Hat
Developers 
___
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] Github workflow

[Jonah Graham]

Andrey,

I am pretty sure all of this can be done with github, but requires writing
bots to handle it.

For example, we could make it so only bot has write access under normal
circumstances and instead of pressing "merge" in github ui a committer adds
an /approve comment. That bot can do things like squash and merge, and add
extra headers to the commit message like Gerrit does today. (a bot like
this often can be configured to wait for tests to complete and then do the
merge automatically)

There may be such bot already that can be reused. Kubernates has a really
nice and complex bot that fixes many of the issues with github's default
flow for their use.

The k8s PR document is quite complete for their flow
https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md


Here is the commands to the bot https://prow.k8s.io/command-help

While I believe it is true that committers/contributors can "just do it"
with github, many large and successful projects on github add significantly
to the default github experience.

Try searching for "github merge bot" to see how many other people have
attacked this problem.

I am glad to see such a discussion happening here. There is indeed no one
"correct" way to use Github and having a contributor guide that addresses
these and other questions is good for the community.

Jonah

On Thu., Mar. 24, 2022, 12:35 Christoph Läubrich, 
wrote:

> 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" 
> >> An: platform-dev@eclipse.org
> >> 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 " 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@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
>
___
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] Github workflow

[Christoph Läubrich]

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" 
An: platform-dev@eclipse.org
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 " 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@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] Github workflow

[Christoph Läubrich]

Sorry for confusion then I probably don't get it. What has Egit/Eclipse 
Ui to do with gerrit?


If I check with with my eclipse SDK things like "Bug " 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?

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

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


Am 24.03.22 um 16:43 schrieb Andrey Loskutov:



Am 24. März 2022 16:37:20 MEZ schrieb "Christoph Läubrich" 
:

This describes all automatically discovered references by Github:

https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/autolinked-references-and-urls#issues-and-pull-requests

You can automatically link issues with cour commit/pr:

https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue

Whenever you use

#ISSUE-NUMBER

-or-

OWNER/REPOSITORY#ISSUE-NUMBER

in your commit message it will generate automatically a link in the
github UI.


Christoph,

You didn't get my point.
I don't want to use github UI, I use Egit from Eclipse because I browse the 
code there and want know what was the context of a commit. A number #15 in 
commit message in Egit is not linked to github, so I would need to manually 
copy/paste that and manually search for the right repo url to get the context. 
With full url of a pr/issue in the header I could do this with a single click, 
like I can do this today with gerrit based commits.

So again, is there anything that is available in github that would do this 
linking *in git commit header* like gerrit it does?
--
Kind regards,
Andrey Loskutov

https://www.eclipse.org/user/aloskutov
Спасение утопающих - дело рук самих утопающих
___
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] Github workflow

[Andrey Loskutov]

Am 24. März 2022 16:37:20 MEZ schrieb "Christoph Läubrich" 
:
>This describes all automatically discovered references by Github:
>
>https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/autolinked-references-and-urls#issues-and-pull-requests
>
>You can automatically link issues with cour commit/pr:
>
>https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
>
>Whenever you use
>
>#ISSUE-NUMBER
>
>-or-
>
>OWNER/REPOSITORY#ISSUE-NUMBER
>
>in your commit message it will generate automatically a link in the 
>github UI.

Christoph,

You didn't get my point. 
I don't want to use github UI, I use Egit from Eclipse because I browse the 
code there and want know what was the context of a commit. A number #15 in 
commit message in Egit is not linked to github, so I would need to manually 
copy/paste that and manually search for the right repo url to get the context. 
With full url of a pr/issue in the header I could do this with a single click, 
like I can do this today with gerrit based commits.

So again, is there anything that is available in github that would do this 
linking *in git commit header* like gerrit it does?
--
Kind regards,
Andrey Loskutov

https://www.eclipse.org/user/aloskutov
Спасение утопающих - дело рук самих утопающих
___
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] Github workflow

[Christoph Läubrich]

This describes all automatically discovered references by Github:

https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/autolinked-references-and-urls#issues-and-pull-requests

You can automatically link issues with cour commit/pr:

https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue

Whenever you use

#ISSUE-NUMBER

-or-

OWNER/REPOSITORY#ISSUE-NUMBER

in your commit message it will generate automatically a link in the 
github UI.


By the way, all of this is nothing specific to *platform* you can simply 
type in your favorite search engine:


github 

and you will get hundred of blogpost, stack overflows telling you if and 
how it works, for example this was answered 12 years ago:


https://stackoverflow.com/questions/1687262/link-to-the-issue-number-on-github-within-a-commit-message


Am 24.03.22 um 16:09 schrieb Andrey Loskutov:



Am 24. März 2022 14:07:12 MEZ schrieb Aleksandar Kurtakov :

1. All the commits should have an issue, created in the same
repository, number associated with them
   1.  #

I don't think it is necessary to have issues for each commit(more of an PR

as it may be multiple commits). With Github PR and issue are practically
the same in terms of references (even share the same number sequence). If
the concern is that PR is not reopenable it's better to open an issue later
if there is an actual issue with the PR rather than create really empty
issues that just hold reference to PR.


That would work for trivial commits.
For all non trivial ones the problem not to have issue in commits is that there 
is no other reference to it in git history, so we will miss the context.
Ideally some action could automatically add the full issue/PR url to git commit 
headers, like gerrit it does.
Is there anything like this for github?
--
Kind regards,
Andrey Loskutov

https://www.eclipse.org/user/aloskutov
Спасение утопающих - дело рук самих утопающих
___
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] Github workflow

[Andrey Loskutov]

Am 24. März 2022 14:07:12 MEZ schrieb Aleksandar Kurtakov :
>>1. All the commits should have an issue, created in the same
>>repository, number associated with them
>>   1.  #
>>
>> I don't think it is necessary to have issues for each commit(more of an PR
>as it may be multiple commits). With Github PR and issue are practically
>the same in terms of references (even share the same number sequence). If
>the concern is that PR is not reopenable it's better to open an issue later
>if there is an actual issue with the PR rather than create really empty
>issues that just hold reference to PR.

That would work for trivial commits. 
For all non trivial ones the problem not to have issue in commits is that there 
is no other reference to it in git history, so we will miss the context.
Ideally some action could automatically add the full issue/PR url to git commit 
headers, like gerrit it does.
Is there anything like this for github?
--
Kind regards,
Andrey Loskutov

https://www.eclipse.org/user/aloskutov
Спасение утопающих - дело рук самих утопающих
___
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] Github workflow

[Aleksandar Kurtakov]

On Thu, Mar 24, 2022 at 3:01 PM Sravan K Lakkimsetti <
sravankum...@in.ibm.com> wrote:

> >> It is unclear / undocumented how to *properly* refer to bugs in commits
> (full url? repo-name/id? just id?).
> >> It is unclear if we should now use dedicated github bug trackers *per
> repository* to report bugs, or will be there some higher level bug tracker
> for entire platform organization?
>
>
>
> Here are my suggestions on this.
>
>1. All the commits should have an issue, created in the same
>repository, number associated with them
>   1.  #
>
> I don't think it is necessary to have issues for each commit(more of an PR
as it may be multiple commits). With Github PR and issue are practically
the same in terms of references (even share the same number sequence). If
the concern is that PR is not reopenable it's better to open an issue later
if there is an actual issue with the PR rather than create really empty
issues that just hold reference to PR.


>
>1.
>1. For root level issues like work spanning across multiple
>repositories, I would prefer root bugs to be created in
>   1. Platform in https://github.com/eclipse-platform/eclipse.platform
>   2. Equinox in https://github.com/eclipse-equinox/equinox.framework
>   3. Pde in eclipse.pde.ui
>   4. Jdt in https://github.com/eclipse-jdt/eclipse.jdt
>2. If issues span across multiple projects(organizations), my
>preference would be
>https://github.com/eclipse-platform/eclipse.platform
>
>
>
> Thanks
>
> Sravan
>
> *From:* platform-dev  *On Behalf Of *Mickael
> Istria
> *Sent:* 24 March 2022 17:40
> *To:* Eclipse platform general developers list. 
> *Subject:* [EXTERNAL] Re: [platform-dev] Github workflow
>
>
>
> Hi, I'm putting a few answers here, but those could go to the document
> pointed out by Sravan (which by the way could be renamed to
> CONTRIBUTING.md)   I don't like forks and used to have branches on main
> repo - not recommended. ‍ ‍ ‍ ‍ ‍ ZjQcmQRYFpfptBannerStart
>
> This Message Is From an External Sender
>
> This message came from outside your organization.
>
> ZjQcmQRYFpfptBannerEnd
>
> Hi,
>
>
>
> I'm putting a few answers here, but those could go to the document pointed
> out by Sravan (which by the way could be renamed to CONTRIBUTING.md)
>
>
>
> I don't like forks and used to have branches on main repo - not
> recommended.
>
>
>
> Indeed. The "upstream" repo shouldn't be used as a workspace for ongoing
> work. Your workspace is your fork.
>
>
>
> I don't like multiple commits in one PR and always use amend/force push -
> not recommended.
>
>
>
> That's *not* not recommended. It's just something that is up to the
> submitter, we shouldn't recommend anything here and let contributors build
> the workflow they prefer.
>
> What needs to be recommended is how we merge and keep a meaningful
> granularity for commits, not how contributors submit their PRs.
>
>
>
> I never use command line git and do everything from Eclipse - but some
> recommended to use git CLI.
>
>
>
> What typical commands do you have in mind? GitHub really is standard Git
> when it comes to push/fetch, the only thing to know is that reference to
> fetch/merge a PR is `pulls/123/head`, so there is no Git fanciness needed
> and EGit can be used for most operations. The only operation needed is the
> creation of a pull request and its review, that usually happens via an
> external tool (eg GitHub website).
>
>
>
> Egit support missing or not - not clear. What exactly is missing, why CLI
> is needed?
>
>
>
> There is decent support for GitHub in EGit. If anything is missing, it
> should be reported to EGit.
>
>
>
> It is unclear / undocumented how to *properly* refer to bugs in commits
> (full url? repo-name/id? just id?).
> It is unclear if we should now use dedicated github bug trackers *per
> repository* to report bugs, or will be there some higher level bug tracker
> for entire platform organization?
>
>
>
> I believe that is still to be determined, as we're growing collective
> experience here.
>
>
>
> Once the PR is created, I see that builds somehow triggered in equinox,
> but I neither get mails that they are stared nor they are finished.
>
>
>
> That's an interesting thought. I don't know whether there is some option
> to allow email notifications for votes.
>
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
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] Github workflow

[Sravan K Lakkimsetti]

>> It is unclear / undocumented how to *properly* refer to bugs in commits 
>> (full url? repo-name/id? just id?).
>> It is unclear if we should now use dedicated github bug trackers *per 
>> repository* to report bugs, or will be there some higher level bug tracker 
>> for entire platform organization?

Here are my suggestions on this.

  1.  All the commits should have an issue, created in the same repository, 
number associated with them
 *#
  2.  For root level issues like work spanning across multiple repositories, I 
would prefer root bugs to be created in
 *   Platform in https://github.com/eclipse-platform/eclipse.platform
 *   Equinox in https://github.com/eclipse-equinox/equinox.framework
 *   Pde in eclipse.pde.ui
 *   Jdt in https://github.com/eclipse-jdt/eclipse.jdt
  3.  If issues span across multiple projects(organizations), my preference 
would be https://github.com/eclipse-platform/eclipse.platform

Thanks
Sravan
From: platform-dev  On Behalf Of Mickael 
Istria
Sent: 24 March 2022 17:40
To: Eclipse platform general developers list. 
Subject: [EXTERNAL] Re: [platform-dev] Github workflow

Hi, I'm putting a few answers here, but those could go to the document pointed 
out by Sravan (which by the way could be renamed to CONTRIBUTING.md)   I don't 
like forks and used to have branches on main repo - not recommended. ‍ ‍ ‍ ‍ ‍ 
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd

Hi,

I'm putting a few answers here, but those could go to the document pointed out 
by Sravan (which by the way could be renamed to CONTRIBUTING.md)

I don't like forks and used to have branches on main repo - not recommended.

Indeed. The "upstream" repo shouldn't be used as a workspace for ongoing work. 
Your workspace is your fork.

I don't like multiple commits in one PR and always use amend/force push - not 
recommended.

That's *not* not recommended. It's just something that is up to the submitter, 
we shouldn't recommend anything here and let contributors build the workflow 
they prefer.
What needs to be recommended is how we merge and keep a meaningful granularity 
for commits, not how contributors submit their PRs.

I never use command line git and do everything from Eclipse - but some 
recommended to use git CLI.

What typical commands do you have in mind? GitHub really is standard Git when 
it comes to push/fetch, the only thing to know is that reference to fetch/merge 
a PR is `pulls/123/head`, so there is no Git fanciness needed and EGit can be 
used for most operations. The only operation needed is the creation of a pull 
request and its review, that usually happens via an external tool (eg GitHub 
website).

Egit support missing or not - not clear. What exactly is missing, why CLI is 
needed?

There is decent support for GitHub in EGit. If anything is missing, it should 
be reported to EGit.

It is unclear / undocumented how to *properly* refer to bugs in commits (full 
url? repo-name/id? just id?).
It is unclear if we should now use dedicated github bug trackers *per 
repository* to report bugs, or will be there some higher level bug tracker for 
entire platform organization?

I believe that is still to be determined, as we're growing collective 
experience here.

Once the PR is created, I see that builds somehow triggered in equinox, but I 
neither get mails that they are stared nor they are finished.

That's an interesting thought. I don't know whether there is some option to 
allow email notifications for votes.

___
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] Github workflow

[Wim Jongman]

I like all this.

I don't like forks and used to have branches on main repo - not recommended.
>

> Indeed. The "upstream" repo shouldn't be used as a workspace for ongoing
work. Your workspace is your fork.

Also, this is free to choose from. If one wants to work with a fork (e.g.
to stash WIP), then this is perfectly valid.

IMO working with forks is easier to grasp for the casual
contributor/committer since creating PR's can be done from the Github UI
and creating branches is not allowed for contributors.

> Indeed. The "upstream" repo shouldn't be used as a workspace for ongoing
work. Your workspace is your fork.

Are local branches (i.e. branches in the main repo) needed in your
workspace-only workflow?



On Thu, 24 Mar 2022 at 13:10, Mickael Istria  wrote:

> Hi,
>
> I'm putting a few answers here, but those could go to the document pointed
> out by Sravan (which by the way could be renamed to CONTRIBUTING.md)
>
>
>> I don't like forks and used to have branches on main repo - not
>> recommended.
>>
>
> Indeed. The "upstream" repo shouldn't be used as a workspace for ongoing
> work. Your workspace is your fork.
>
> I don't like multiple commits in one PR and always use amend/force push -
>> not recommended.
>>
>
> That's *not* not recommended. It's just something that is up to the
> submitter, we shouldn't recommend anything here and let contributors build
> the workflow they prefer.
> What needs to be recommended is how we merge and keep a meaningful
> granularity for commits, not how contributors submit their PRs.
>
>
>> I never use command line git and do everything from Eclipse - but some
>> recommended to use git CLI.
>>
>
> What typical commands do you have in mind? GitHub really is standard Git
> when it comes to push/fetch, the only thing to know is that reference to
> fetch/merge a PR is `pulls/123/head`, so there is no Git fanciness needed
> and EGit can be used for most operations. The only operation needed is the
> creation of a pull request and its review, that usually happens via an
> external tool (eg GitHub website).
>
>
>> Egit support missing or not - not clear. What exactly is missing, why CLI
>> is needed?
>>
>
> There is decent support for GitHub in EGit. If anything is missing, it
> should be reported to EGit.
>
>
>> It is unclear / undocumented how to *properly* refer to bugs in commits
>> (full url? repo-name/id? just id?).
>> It is unclear if we should now use dedicated github bug trackers *per
>> repository* to report bugs, or will be there some higher level bug tracker
>> for entire platform organization?
>>
>
> I believe that is still to be determined, as we're growing collective
> experience here.
>
>
>> Once the PR is created, I see that builds somehow triggered in equinox,
>> but I neither get mails that they are stared nor they are finished.
>
>
> That's an interesting thought. I don't know whether there is some option
> to allow email notifications for votes.
>
> ___
> 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] Github workflow

[Mickael Istria]

Hi,

I'm putting a few answers here, but those could go to the document pointed
out by Sravan (which by the way could be renamed to CONTRIBUTING.md)


> I don't like forks and used to have branches on main repo - not
> recommended.
>

Indeed. The "upstream" repo shouldn't be used as a workspace for ongoing
work. Your workspace is your fork.

I don't like multiple commits in one PR and always use amend/force push -
> not recommended.
>

That's *not* not recommended. It's just something that is up to the
submitter, we shouldn't recommend anything here and let contributors build
the workflow they prefer.
What needs to be recommended is how we merge and keep a meaningful
granularity for commits, not how contributors submit their PRs.


> I never use command line git and do everything from Eclipse - but some
> recommended to use git CLI.
>

What typical commands do you have in mind? GitHub really is standard Git
when it comes to push/fetch, the only thing to know is that reference to
fetch/merge a PR is `pulls/123/head`, so there is no Git fanciness needed
and EGit can be used for most operations. The only operation needed is the
creation of a pull request and its review, that usually happens via an
external tool (eg GitHub website).


> Egit support missing or not - not clear. What exactly is missing, why CLI
> is needed?
>

There is decent support for GitHub in EGit. If anything is missing, it
should be reported to EGit.


> It is unclear / undocumented how to *properly* refer to bugs in commits
> (full url? repo-name/id? just id?).
> It is unclear if we should now use dedicated github bug trackers *per
> repository* to report bugs, or will be there some higher level bug tracker
> for entire platform organization?
>

I believe that is still to be determined, as we're growing collective
experience here.


> Once the PR is created, I see that builds somehow triggered in equinox,
> but I neither get mails that they are stared nor they are finished.


That's an interesting thought. I don't know whether there is some option to
allow email notifications for votes.
___
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] Github workflow

[Wim Jongman]

Yes, a great starting point Sravan. This workflow matches my preferred way
of working. In this way, contributors and committers follow the same
workflow.

Cheers, Wim

Eclipse Github Workflow


On Thu, 24 Mar 2022 at 03:43, Sravan K Lakkimsetti 
wrote:

> Hi,
>
> I did create this
> https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/DeveloperGuide.md
> may be this could be a starting point and we can improve this document
> further with recommended approach
>
> Thanks
> Sravan
>
> -Original Message-
> From: platform-dev  On Behalf Of Andrey
> Loskutov
> Sent: 24 March 2022 03:57
> To: Eclipse platform general developers list. 
> Subject: [EXTERNAL] Re: [platform-dev] Github workflow
>
>
>
> Am 22. März 2022 14:11:21 MEZ schrieb Aleksandar Kurtakov <
> akurt...@redhat.com>:
> >Please bear with us while we try to improve the contributor workflow
> >with the limited time we have. And keep asking each step and
> >requirement as only that way we will figure what is really needed and
> >brings benefit and what is done just because we are used to it without
> any real gain.
>
> The discussion here shows that despite the claims that "we are standing on
> the shoulders of the giants" and "just follow github workflow" we need a
> dedicated wiki / readme for committers and contributors with the
> recommendations how to contribute. Mailing list discussion is fine, but
> that is not a document I can give to someone who wants to contribute.
>
> With more platform projects moving to github the problem affects more
> people now.
> I would really appreciate of people that know the "right" github workflow
> would provide such documentation for the platform.
>
> I personally can commit & merge in github but I've learned that
> *everything* I did in github before in my other (non platform)
> contributions is *not* the "recommended" way, so I'm really interested to
> follow some "preferred" guidelines. I also hope to have only one and not
> different guidelines, even if there could be lot of different ways to
> commit something to the master.
>
> Below just few items where I see need for clear documentation or process
> improvements based on my personal experience so far.
>
> I don't like forks and used to have branches on main repo - not
> recommended.
> I don't like multiple commits in one PR and always use amend/force push -
> not recommended.
> I never use command line git and do everything from Eclipse - but some
> recommended to use git CLI.
> Egit support missing or not - not clear. What exactly is missing, why CLI
> is needed?
> It is unclear / undocumented how to *properly* refer to bugs in commits
> (full url? repo-name/id? just id?).
> It is unclear if we should now use dedicated github bug trackers *per
> repository* to report bugs, or will be there some higher level bug tracker
> for entire platform organization?
> Once the PR is created, I see that builds somehow triggered in equinox,
> but I neither get mails that they are stared nor they are finished.
> TBC...
>
> --
> Kind regards,
> Andrey Loskutov
>
> https://www.eclipse.org/user/aloskutov
> Спасение утопающих - дело рук самих утопающих
> ___
> 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
>
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev