Re: [platform-dev] Github workflow
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"
Re: [platform-dev] Github workflow
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
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
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
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
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
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
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
>> 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
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
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
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 <https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/DeveloperGuide.md> 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
Re: [platform-dev] Github workflow
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 : >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
Re: [platform-dev] Github workflow
Am 22. März 2022 14:11:21 MEZ schrieb Aleksandar Kurtakov : >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
Re: [platform-dev] Github workflow
On Tue, Mar 22, 2022 at 2:52 PM Christoph Läubrich wrote: > > Given the plethora of repositories that comprise > > the Eclipse SDK > > Even though it was considered "not important" I always has suggested to > actually merge related stuff into one repository, this splitting across > different repos is just a pain, and we should not blame the tools for > not supporting it well enough but think that obviously things belong > together. > This has always been a pain. We used to have even more repositories. There are plans/hopes to merge a few of them but there are some limiting factors like speed of execution of tests that make verification builds too slow if we merge too much and etc. This shouldn't sound like an excuse - it's just the current state of affairs. Not many people find it interesting to work on these things thus progress on them is even slower. Either way, Thomas wants to merge equinox.framework and equinox.bundles repositories once Github migration is done, but it hasn't been done at the same time as we didn't want to prolong the migration for even longer with such changes. PDE definitely should become a single repo. Platform is up for consideration too. 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. > > Anyways, if one like he can reference other repositories or issues as > well, github will detect links or shortcode like > eclipse/#1234 > > Am 22.03.22 um 13:15 schrieb Ed Merks: > > Wim, > > > > Note though my comment about a commit related to an issue from a > > different repository. Given the plethora of repositories that comprise > > the Eclipse SDK, that seems not at all unlikely to happen, is it? Or > > should that be forbidden? Or should we not have rules at all? We do > > seem to have several proposed workflows but not really general agreement > > on what should or shouldn't be done nor how it should be done... > > > > Regards, > > Ed > > > > On 22.03.2022 13:00, Wim Jongman wrote: > >> Ed, in time EGit will probably learn how to interpret GitHub-related > >> content as it can now do for Bugzilla. For issues spanning > >> repositories, it would indeed be needed to include a link. > >> > >> Cheers, Wim > >> > >> On Tue, 22 Mar 2022 at 11:05, Ed Merks wrote: > >> > >> Wim, > >> > >> Comments below. > >> > >> On 22.03.2022 10:46, Wim Jongman wrote: > >>> In BIRT, Windowbuilder, and Nebula we successfully use the > >>> following workflow: > >>> > >>> 1. Fork the main repo > >>> 2. Create an issue in the main repo e.g. "My Issue" #1 (#1 being > >>> the next ID) > >>> 3. Make changes in a branch in your fork (not in master/main)!!! > >>> 4. Commit with "My Issue #1"(include #1) > >>> > >> A few "concerns" here. This approach does look good in the github > >> views, but the issue URI is implicit. That works well (on the > >> github site) when the issue is open in the same repo as the > >> commit, but I expect in the long term, there may well be commits > >> for a single issue across multiple repos. Also, EGit knows > >> nothing about such implicit links so will not show such links in > >> the UI. > >> > >> It's also possible to include the full issue link like this such > >> that even in EGit, you can see an issue link that you can follow > >> to the github site: > >> > >> This looks like this in the github pages: > >> > >> Note how the long issue link is displayed as #2 here. Also note > >> that the #3 is a link to the PR while #2 is a link to the issue. > >> So here the implicit URI is different depending on the location of > >> the #. I'm not sure how EGit might create/display such > >> links in the future... > >> > >> So perhaps it's worth considering including the full link to the > >> issue in the body of the commit message? > >> > >> Just a thought... > >> > >>> 1. Go to GitHub in the main repo. GH offers to create a PR > >>> 2. Use "My Issue #1" as the topic. The PR will be called "My > >>> Issue #1" #2 > >>> 3. Start Review > >>> 4. Keep committing on your fork branch > >>> 5. PR is accepted > >>> 6. Go to your fork and "Fetch upstream" [1] > >>> > >>> > >> Yes, this is a PITA. :-(It's hard to keep something like the > >> following up-to-date if you *also *have to go off into github and > >> manually fetch each fork (if you have one) before Select All and > >> to a Pull. > >> > >> I wondered if there were some way to make this easier with > >> multiple configured remotes, but I don't understand that approach > >> well enough > >> > >>> [1] Fetching upstream is currently a pain. I have started a > >>> discussion here. Please also comment
Re: [platform-dev] Github workflow
> I don't have the same experience here in general: You are right. After the force, there is a backdoor to previous comments. [image: image.png] On Tue, 22 Mar 2022 at 13:45, Mickael Istria wrote: > > > On Tue, Mar 22, 2022 at 1:39 PM Wim Jongman wrote: > >> >> >>> What particularly do you think does not work well with it? >>> >> >> File reviews or bound to the commit id and when you force push, the >> review is gone. See the screenshot below. This makes it very hard for the >> reviewer to see if their suggestions have been followed. >> > > I don't have the same experience here in general: using force push shows a > line that allows to diff the previous and current version. On the review > page, the former review comments are still shown, and marked as "Outdated" > if the code changed in a way that the review is not easy to transfer to > newer patch. > ___ > 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
> Given the plethora of repositories that comprise > the Eclipse SDK Even though it was considered "not important" I always has suggested to actually merge related stuff into one repository, this splitting across different repos is just a pain, and we should not blame the tools for not supporting it well enough but think that obviously things belong together. Anyways, if one like he can reference other repositories or issues as well, github will detect links or shortcode like eclipse/#1234 Am 22.03.22 um 13:15 schrieb Ed Merks: Wim, Note though my comment about a commit related to an issue from a different repository. Given the plethora of repositories that comprise the Eclipse SDK, that seems not at all unlikely to happen, is it? Or should that be forbidden? Or should we not have rules at all? We do seem to have several proposed workflows but not really general agreement on what should or shouldn't be done nor how it should be done... Regards, Ed On 22.03.2022 13:00, Wim Jongman wrote: Ed, in time EGit will probably learn how to interpret GitHub-related content as it can now do for Bugzilla. For issues spanning repositories, it would indeed be needed to include a link. Cheers, Wim On Tue, 22 Mar 2022 at 11:05, Ed Merks wrote: Wim, Comments below. On 22.03.2022 10:46, Wim Jongman wrote: In BIRT, Windowbuilder, and Nebula we successfully use the following workflow: 1. Fork the main repo 2. Create an issue in the main repo e.g. "My Issue" #1 (#1 being the next ID) 3. Make changes in a branch in your fork (not in master/main)!!! 4. Commit with "My Issue #1"(include #1) A few "concerns" here. This approach does look good in the github views, but the issue URI is implicit. That works well (on the github site) when the issue is open in the same repo as the commit, but I expect in the long term, there may well be commits for a single issue across multiple repos. Also, EGit knows nothing about such implicit links so will not show such links in the UI. It's also possible to include the full issue link like this such that even in EGit, you can see an issue link that you can follow to the github site: This looks like this in the github pages: Note how the long issue link is displayed as #2 here. Also note that the #3 is a link to the PR while #2 is a link to the issue. So here the implicit URI is different depending on the location of the #. I'm not sure how EGit might create/display such links in the future... So perhaps it's worth considering including the full link to the issue in the body of the commit message? Just a thought... 1. Go to GitHub in the main repo. GH offers to create a PR 2. Use "My Issue #1" as the topic. The PR will be called "My Issue #1" #2 3. Start Review 4. Keep committing on your fork branch 5. PR is accepted 6. Go to your fork and "Fetch upstream" [1] Yes, this is a PITA. :-( It's hard to keep something like the following up-to-date if you *also *have to go off into github and manually fetch each fork (if you have one) before Select All and to a Pull. I wondered if there were some way to make this easier with multiple configured remotes, but I don't understand that approach well enough [1] Fetching upstream is currently a pain. I have started a discussion here. Please also comment or upvote: https://github.com/github/feedback/discussions/13221 Cheers, Wim ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visithttps://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, visithttps://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
On Tue, Mar 22, 2022 at 1:39 PM Wim Jongman wrote: > > >> What particularly do you think does not work well with it? >> > > File reviews or bound to the commit id and when you force push, the review > is gone. See the screenshot below. This makes it very hard for the reviewer > to see if their suggestions have been followed. > I don't have the same experience here in general: using force push shows a line that allows to diff the previous and current version. On the review page, the former review comments are still shown, and marked as "Outdated" if the code changed in a way that the review is not easy to transfer to newer patch. ___ 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
> What particularly do you think does not work well with it? > File reviews or bound to the commit id and when you force push, the review is gone. See the screenshot below. This makes it very hard for the reviewer to see if their suggestions have been followed. > > >> I propose to just keep committing on the branch (a bit like Gerrit change >> sets) and then always(!) Squash and Merge >> > As reviewers, we shouldn't have to care about it; and feel free to use > Squash and Merge if it seems better, or even ask contributors to reorganize > their commits before merging if it seems necessary. What's important is > that what we merge is in good quality of code and also of history, so we > keep the history sane. But this is not really a contributor's duty to > achieve that, more a reviewer's one. > Of course, we should avoid --force on the "upstream" eclipse repo. > Yes, sure. I just wanted to lay down my experiences. I agree that this should be on a case by case basis but as a rule of thumb, I recommend * No --force just keep committing as we did with Gerrit * Squash and merge to keep the commit history clean Take a look at this PR with a review after force push: https://github.com/eclipse/birt/pull/886 [image: image.png] After clicking on that file review comment: [image: image.png] > ___ > 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
On Tue, Mar 22, 2022 at 12:23 PM Wim Jongman wrote: > Also, we need to discuss the --force parameter. It will not work well with > the Github review system. > What particularly do you think does not work well with it? > I propose to just keep committing on the branch (a bit like Gerrit change > sets) and then always(!) Squash and Merge > What's in the branch and how it's organized is the choice of the contributor. They may want to append commits or push --force. As reviewers, we shouldn't have to care about it; and feel free to use Squash and Merge if it seems better, or even ask contributors to reorganize their commits before merging if it seems necessary. What's important is that what we merge is in good quality of code and also of history, so we keep the history sane. But this is not really a contributor's duty to achieve that, more a reviewer's one. Of course, we should avoid --force on the "upstream" eclipse repo. ___ 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
I agree. These local branches tend to stay: https://git.eclipse.org/c/platform/eclipse.platform.ui.git/refs/heads On Tue, 22 Mar 2022 at 12:38, Aleksandar Kurtakov wrote: > > > On Tue, Mar 22, 2022 at 1:25 PM Lars Vogel wrote: > >> Sorry, if that was said before (I did not read all discussions in >> detail) but committers can create PR for the same repository without >> the additional fork. >> >> So a possible workflow is: >> 1.) Clone repo >> 2.) Create new local branch >> 3.) Push local branch to new branch in origin >> 4.) Create PR from new branch to master / main in the same repo >> >> This removes the need to sync your server fork. >> > > Lars, this workflow is good for small and/or private projects. But for > bigger communities it's better to stick to official github recommendations > ( > https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models) > Shared repository model - "This model is more prevalent with small teams > and organizations collaborating on private projects." and I would not call > Eclipse being small team nor private project.) > Benefits from using a fork and branch in your fork has at least these > multiple benefits: > * your changes are independent and not create churn in the main project > * committers and contributors follow same procedures so better understand > each other > * put less burden on CI - every branch in main repo is scanned and checked > for compilability and test status > > > >> >> Best regards, Lars >> >> On Tue, Mar 22, 2022 at 11:22 AM Rolf Theunissen >> wrote: >> > >> > Hi, >> > >> > What comes to mind is 'origin' and 'upstream' repositories. Where >> 'origin' is your fork and the 'upstream' the forked repo. >> > Your workflow seems to fetch from 'upstream' (aka eclipse) and push to >> origin (aka me), after which a PR is made from 'orgin' back to 'upstream'. >> > With the right settings this might be able to set the default fetch and >> default push locations in EGit too. >> > >> > >> https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/configuring-a-remote-for-a-fork >> > >> https://stackoverflow.com/questions/9257533/what-is-the-difference-between-origin-and-upstream-on-github >> > >> > >> > Op di 22 mrt. 2022 om 11:13 schreef Mickael Istria > >: >> >> >> >> Hi, >> >> >> >> On Tue, Mar 22, 2022 at 10:46 AM Wim Jongman >> wrote: >> >>> >> >>> Go to your fork and "Fetch upstream" [1] >> >> >> >> Why do you need to do that? Particularly if you never use master/main? >> >> FWIW, may workflow is >> >> $ git fetch eclipse master >> >> $ git checkout FETCH_HEAD >> >> [... do changes ...] >> >> $ git commit -m "My super fix (#123)" >> >> $ git push me HEAD:refs/heads/issue-123 >> >> Create PR >> >> If needed, improve, rebase, `git push me --force HEAD:issue-123` >> >> Upon PR merge, just remove my issue-123 branch. >> >> >> >> This allows to not care about the master/main branch in my fork. I can >> even happily delete it, and it gives me more guarantee to keep in sync! >> >> ___ >> >> 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 >> >> >> >> -- >> Eclipse Platform project co-lead >> CEO vogella GmbH >> >> Haindaalwisch 17a, 22395 Hamburg >> Amtsgericht Hamburg: HRB 127058 >> Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel >> USt-IdNr.: DE284122352 >> Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web: >> http://www.vogella.com >> ___ >> 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 > ___ 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
On Tue, Mar 22, 2022 at 1:25 PM Lars Vogel wrote: > Sorry, if that was said before (I did not read all discussions in > detail) but committers can create PR for the same repository without > the additional fork. > > So a possible workflow is: > 1.) Clone repo > 2.) Create new local branch > 3.) Push local branch to new branch in origin > 4.) Create PR from new branch to master / main in the same repo > > This removes the need to sync your server fork. > Lars, this workflow is good for small and/or private projects. But for bigger communities it's better to stick to official github recommendations ( https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models) Shared repository model - "This model is more prevalent with small teams and organizations collaborating on private projects." and I would not call Eclipse being small team nor private project.) Benefits from using a fork and branch in your fork has at least these multiple benefits: * your changes are independent and not create churn in the main project * committers and contributors follow same procedures so better understand each other * put less burden on CI - every branch in main repo is scanned and checked for compilability and test status > > Best regards, Lars > > On Tue, Mar 22, 2022 at 11:22 AM Rolf Theunissen > wrote: > > > > Hi, > > > > What comes to mind is 'origin' and 'upstream' repositories. Where > 'origin' is your fork and the 'upstream' the forked repo. > > Your workflow seems to fetch from 'upstream' (aka eclipse) and push to > origin (aka me), after which a PR is made from 'orgin' back to 'upstream'. > > With the right settings this might be able to set the default fetch and > default push locations in EGit too. > > > > > https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/configuring-a-remote-for-a-fork > > > https://stackoverflow.com/questions/9257533/what-is-the-difference-between-origin-and-upstream-on-github > > > > > > Op di 22 mrt. 2022 om 11:13 schreef Mickael Istria : > >> > >> Hi, > >> > >> On Tue, Mar 22, 2022 at 10:46 AM Wim Jongman > wrote: > >>> > >>> Go to your fork and "Fetch upstream" [1] > >> > >> Why do you need to do that? Particularly if you never use master/main? > >> FWIW, may workflow is > >> $ git fetch eclipse master > >> $ git checkout FETCH_HEAD > >> [... do changes ...] > >> $ git commit -m "My super fix (#123)" > >> $ git push me HEAD:refs/heads/issue-123 > >> Create PR > >> If needed, improve, rebase, `git push me --force HEAD:issue-123` > >> Upon PR merge, just remove my issue-123 branch. > >> > >> This allows to not care about the master/main branch in my fork. I can > even happily delete it, and it gives me more guarantee to keep in sync! > >> ___ > >> 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 > > > > -- > Eclipse Platform project co-lead > CEO vogella GmbH > > Haindaalwisch 17a, 22395 Hamburg > Amtsgericht Hamburg: HRB 127058 > Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel > USt-IdNr.: DE284122352 > Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web: > http://www.vogella.com > ___ > 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
Sorry, if that was said before (I did not read all discussions in detail) but committers can create PR for the same repository without the additional fork. So a possible workflow is: 1.) Clone repo 2.) Create new local branch 3.) Push local branch to new branch in origin 4.) Create PR from new branch to master / main in the same repo This removes the need to sync your server fork. Best regards, Lars On Tue, Mar 22, 2022 at 11:22 AM Rolf Theunissen wrote: > > Hi, > > What comes to mind is 'origin' and 'upstream' repositories. Where 'origin' is > your fork and the 'upstream' the forked repo. > Your workflow seems to fetch from 'upstream' (aka eclipse) and push to origin > (aka me), after which a PR is made from 'orgin' back to 'upstream'. > With the right settings this might be able to set the default fetch and > default push locations in EGit too. > > https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/configuring-a-remote-for-a-fork > https://stackoverflow.com/questions/9257533/what-is-the-difference-between-origin-and-upstream-on-github > > > Op di 22 mrt. 2022 om 11:13 schreef Mickael Istria : >> >> Hi, >> >> On Tue, Mar 22, 2022 at 10:46 AM Wim Jongman wrote: >>> >>> Go to your fork and "Fetch upstream" [1] >> >> Why do you need to do that? Particularly if you never use master/main? >> FWIW, may workflow is >> $ git fetch eclipse master >> $ git checkout FETCH_HEAD >> [... do changes ...] >> $ git commit -m "My super fix (#123)" >> $ git push me HEAD:refs/heads/issue-123 >> Create PR >> If needed, improve, rebase, `git push me --force HEAD:issue-123` >> Upon PR merge, just remove my issue-123 branch. >> >> This allows to not care about the master/main branch in my fork. I can even >> happily delete it, and it gives me more guarantee to keep in sync! >> ___ >> 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 -- Eclipse Platform project co-lead CEO vogella GmbH Haindaalwisch 17a, 22395 Hamburg Amtsgericht Hamburg: HRB 127058 Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel USt-IdNr.: DE284122352 Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web: http://www.vogella.com ___ 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, yes your WF is very cunning, I will try that. I think the two methods can happily co-exist. My proposed WF is arguably a bit easier for people that aren't that Git savvy. In my experience, it works very well to get people started. Also, we need to discuss the --force parameter. It will not work well with the Github review system. I propose to just keep committing on the branch (a bit like Gerrit change sets) and then always(!) Squash and Merge Cheers, Wim On Tue, 22 Mar 2022 at 11:13, Mickael Istria wrote: > Hi, > > On Tue, Mar 22, 2022 at 10:46 AM Wim Jongman > wrote: > >> >>1. Go to your fork and "Fetch upstream" [1] >> >> Why do you need to do that? Particularly if you never use master/main? > FWIW, may workflow is > $ git fetch eclipse master > $ git checkout FETCH_HEAD > [... do changes ...] > $ git commit -m "My super fix (#123)" > $ git push me HEAD:refs/heads/issue-123 > Create PR > If needed, improve, rebase, `git push me --force HEAD:issue-123` > Upon PR merge, just remove my issue-123 branch. > > This allows to not care about the master/main branch in my fork. I can > even happily delete it, and it gives me more guarantee to keep in sync! > ___ > 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
Hi, What comes to mind is 'origin' and 'upstream' repositories. Where 'origin' is your fork and the 'upstream' the forked repo. Your workflow seems to fetch from 'upstream' (aka eclipse) and push to origin (aka me), after which a PR is made from 'orgin' back to 'upstream'. With the right settings this might be able to set the default fetch and default push locations in EGit too. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/configuring-a-remote-for-a-fork https://stackoverflow.com/questions/9257533/what-is-the-difference-between-origin-and-upstream-on-github Op di 22 mrt. 2022 om 11:13 schreef Mickael Istria : > Hi, > > On Tue, Mar 22, 2022 at 10:46 AM Wim Jongman > wrote: > >> >>1. Go to your fork and "Fetch upstream" [1] >> >> Why do you need to do that? Particularly if you never use master/main? > FWIW, may workflow is > $ git fetch eclipse master > $ git checkout FETCH_HEAD > [... do changes ...] > $ git commit -m "My super fix (#123)" > $ git push me HEAD:refs/heads/issue-123 > Create PR > If needed, improve, rebase, `git push me --force HEAD:issue-123` > Upon PR merge, just remove my issue-123 branch. > > This allows to not care about the master/main branch in my fork. I can > even happily delete it, and it gives me more guarantee to keep in sync! > ___ > 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
Hi, On Tue, Mar 22, 2022 at 10:46 AM Wim Jongman wrote: > >1. Go to your fork and "Fetch upstream" [1] > > Why do you need to do that? Particularly if you never use master/main? FWIW, may workflow is $ git fetch eclipse master $ git checkout FETCH_HEAD [... do changes ...] $ git commit -m "My super fix (#123)" $ git push me HEAD:refs/heads/issue-123 Create PR If needed, improve, rebase, `git push me --force HEAD:issue-123` Upon PR merge, just remove my issue-123 branch. This allows to not care about the master/main branch in my fork. I can even happily delete it, and it gives me more guarantee to keep in sync! ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
[platform-dev] Github workflow
In BIRT, Windowbuilder, and Nebula we successfully use the following workflow: 1. Fork the main repo 2. Create an issue in the main repo e.g. "My Issue" #1 (#1 being the next ID) 3. Make changes in a branch in your fork (not in master/main)!!! 4. Commit with "My Issue #1"(include #1) 5. Go to GitHub in the main repo. GH offers to create a PR 6. Use "My Issue #1" as the topic. The PR will be called "My Issue #1" #2 7. Start Review 8. Keep committing on your fork branch 9. PR is accepted 10. Go to your fork and "Fetch upstream" [1] [1] Fetching upstream is currently a pain. I have started a discussion here. Please also comment or upvote: https://github.com/github/feedback/discussions/13221 Cheers, Wim ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
