Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...

[Gayan Perera <gayanper@xxxxxxxxx>]

Hi All,

From my experience as a reviewer and a long time git user, I normally recommend not to perform force push unless the branch is only for your self. Which means the work in that branch is not used by anyone else or not looked at by anyone else for like reviewing. But then again when rebasing against master one must perform a force push unless you decide to do a merge.

But from the reviewers point of view it would be really good if the contributor could keep each delta (since after the PR is made) so that reviewer can see how to contributor has addressed the requested changes.

I do also sometimes amend and force push changes. I think personally I should stop being an example for others.

About documentation I think we should have it in once place. A good place would be in the .github repository since most of the instructions will be common for all JDT repositories. And each CONTRIBUTION.md in module repositories can link to that. I think we can learn from jdt.ls and other vscode related java extension how they maintain as well. 

The build issue was there in gerrit as well until we implemented the "please rebuild" comment into gerrit. I remember when I didn't had commit access I couldn't trigger builds from jenkins, So i have to ask for help from a committer.

When looking at contributors I can see few types:

- Who use eclipse daily and who want to improve or fix a issue they found

- Who are paid as part of their employment to provide fixes to 

- Who builds products on top of Eclipse which they want to contribute to improve things.

I think the issues we discuss here might not that much effect the 2nd category, But for 1st it will. Because the steps to contribute some work is hard, they might not do that. And if the issues are not fixed, they might switch to a different IDE, like IJ which happens to the high probable case here. The 3rd category depends, If the product is rooted in Eclipse they might still hang-on, but otherwise the same could happen like in category 2.

So I think proper upto date documentation close to source code and providing good practices (Git Best practices) might help to solve the issues and also keep a healthy contribution.

Best regards,

Gayan.

On Sun, Sep 11, 2022 at 3:13 PM Ed Merks <ed.merks@xxxxxxxxx> wrote:

At least for the first question about the setup, I've automated that (even the steps of what to do in the installer) and provide information (link) about that in each contributing guide:

https://github.com/eclipse-jdt/.github/blob/main/CONTRIBUTING.md#create-an-eclipse-development-environment
https://github.com/eclipse-platform/.github/blob/main/CONTRIBUTING.md#create-an-eclipse-development-environment

The later is the complete SDK set of projects, including the aggregator project.

Note that if something times out or there is some other network problem during setup, you can try again via Help -> Perform Setup Tasks; this is also useful to run to update the IDE to the latest installation and latest target platform...

Maybe this tutorial helps:

https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning

If there are things that seem broken or could be improved in that regard, I could look into that; the tutorial has a Bugzilla link for that.

Note too that the SDK setup includes a "Runtime Workspace" launcher that should just work...

On 11.09.2022 13:31, Zsombor Gegesy wrote:

As one, who just started contributing a year ago, I could share my experience, that the barrier for contributions are extremely high, due to lack of documentation.

I mean, other open source project generally have some sort of documentation/tutorials, especially if they are doing some non-conventional things.

With lot of wasted hours of reading forums, year old blog posts, tuning google search, and trial-and-error, I could collect that information, but I'm still not sure, if there are simpler way to do this - I guess so, because every couple of months my environment gone haywire, so I need to start from scratch. As a wanna-be-contributor, I would expect:

* how to get the source code, and how to setup my IDE? Originally, I tried to simply 'git clone ...' a couple of repos, and import into Eclipse, but it wasn't successful. Later found, that I need to use an 'advanced tab of 'Oomph' tool to install a separate IDE, which will also do the git checkout. (Of course, if that git operation times out, than you have to start from scratch)

* how to start the project from the IDE? The launcher config is very complicated, and it take a lot of trial and error until I figured out, what projects should I close, what needs to be open, and certain errors reported at startup is just there.

* how to build your changes into a working, shareable software, which can be used in other machines / by other people? Finally, I found, that I need to checkout the 'releng.aggregator' project, adjust the submodules, and after an hour of build, I will get the necessary binaries, that can be used in other installations.

Compared to these problems, for me it's feels minor thing, that if/when to rebase/squash/etc, but your mileage may vary.

Zsombor

On Sun, 11 Sept 2022 at 11:22, Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx> wrote:

> On Sep 11, 2022, at 07:20, Christoph Läubrich <laeubi@xxxxxxxxxxxxxx> wrote:
>
> Just one question:
>
> Are there *that* many contributions to JDT that one really can reject a valuable contribution just because the person uses (or dont uses) force push? Just a thought...

On the flip side, contributions are pointless if the subject matter expert is not able to review them because they require additional work to process. Thus, I think it's a matter of cooperation on being respectful.

You can't optimize workflows for contributions only when the cost implies dumping more work or requiring more time from committers/smes. In the case of JDT, especially the compiler internals needs very careful reviews from a subject matter expert. This might be different in other areas of JDT (eg JDT UI). Thus, having those conventions or rules documented upfront for the community (including some information were they apply or not apply) is not a bad thing. You will be surprised of how open contributors can be when things are communicated upfront.

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

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

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