eclipse.platform.swt
eclipse.platform.swt copied to clipboard
eclipse-platform
Not enough contributors
There has been very few contributors in SWT lately. I also see it as stalemate: without reviewers, we can't get more committers.
Here's a summary of past active members (to my memory, apologies if I got something wrong):
- @niraj-modi contributed quite a bit for Windows, but has been almost missing for a couple years now.
- @nnemkin contributed for Windows, but silently stepped away.
- @iloveeclipse contributed for Linux, but I understand that he's too busy with other work.
- @akurtakov contributed for Linux, recently said that he's too busy with other things and is stepping down as reviewer.
- @ericwill was quite active on Linux around 2018 when I joined SWT, but then switched to some other project.
- @lshanmug contributed for macOS, but is seemingly busy.
On all 3 platforms, there's pretty much noone except me currently. Again, that's my impression, apologies if I got something wrong.
However, I'm hired to do specific work, which mostly involves fixing bugs that are relevant to the hiring company's product. It uses SWT directly and doesn't use bigger Eclipse in any way. I am NOT paid to review or maintain repo or fix any other bugs that are not relevant to the product. I am also not interested in Eclipse personally. I'm not even a Java programmer, I focus on C++ instead.
This means that even though I'm somewhat active in contributing fixes to SWT, I am not a reviewer or maintainer.
I understand that some kind of emergency measures are needed, for example:
- If Eclipse foundation has resources, hire reviewers/maintainers
- Lower entry barrier, and give committer rights after just a couple of meaningful contributions. Hopefully this way, SWT can get a few more committers, which would maybe sometimes review PRs from not-yet-members. One possible candidate here is @basilevs
On all 3 platforms, there's pretty much noone except me currently. Again, that's my impression
I think it's not an impression but more a fact as there is data (Git history and GitHub issues) to back that statement.
However, I'm hired to do specific work, which mostly involves fixing bugs that are relevant to the hiring company's product. It uses SWT directly and doesn't use bigger Eclipse in any way. I am NOT paid to review or maintain repo or fix any other bugs that are not relevant to the product.
Just to be pedantic here: if you're paid to fix bugs in a product based on SWT, you're kind of paid to also maintain the libraries which you depend on. It's actually a good thing that you and your employer do understand it and accept to fix bugs upstream. Unfortunately, as you discover here, very few people have such a clear and efficient understanding of how to be a "good citizen" consumers and the duty of maintenance rarely spread on a fair number of developers.
This means that even though I'm somewhat active in contributing fixes to SWT, I am not a reviewer or maintainer.
I think it's really up to you to work on what you want to work on. You're free to not review, you're free to decline review requests. It's really not a big deal if you do so, declining (politely) a request is welcome in the Eclipse project. If someone asks for a review and you say "Sorry, I don't plan to review this patch as it doesn't affect the products I'm maintaining and I have only time to focus on that", that's fine. But beware, now you're an expert in this area, people will ping you from time to time anyway because you may sometimes be their only hope ;) But again, it's fine to decline.
If Eclipse foundation has resources, hire reviewers/maintainers
The "Eclipse IDE Working Group" is where such financial resources are managed (collected and spent). If you're not aware with it, I suggest you read the related page, and maybe share it with your employer if they want to support Eclipse development with an extra different approach (basically, spend money to get influence on hiring people)
Lower entry barrier, and give committer rights after just a couple of meaningful contributions. Hopefully this way, SWT can get a few more committers, which would maybe sometimes review PRs from not-yet-members. One possible candidate here is @basilevs
As a committer, you're free to nominate a new committer; then the vote would take place. So I suggest that if @basilevs agree, you nominate him (just log in to https://projects.eclipse.org/projects/eclipse.platform and click "Nominate a committer" on the right column). Note that it is usually a good thing to ask directly the candidate whether they're OK being nominated before actually nominating them.
Would be really cool, if you could nominate new committers @SyntevoAlex once you think they are ready, this helps spreading the workload.
Adding @jonahgraham as this item may justify for paid work for the "Eclipse IDE Working Group" (and to my knowledge Jonah is involved in this budget activity).
I would love to support SWT but unfortunately I have moved into a different role at Red Hat.
At the moment the looming threat to SWT-GTK (apart from lack of contributors/reviewers) is the incomplete GTK4 port. Eventually distros will stop shipping GTK3, and without a complete GTK4 port Eclipse won't even run properly. A "complete" GTK4 port means functioning Browser/WebKit-GTK support, without which Eclipse cannot fully function.
I recognise the issue raised by @SyntevoAlex. In addition to what is stated, I believe the platform specific nature of the code and critical code paths that several downstream modules depend on makes code contribution and review relatively harder. In many cases, it is hard to bring behavioural parity between platforms with incompatible graphic elements, making it real hard to contribute. I can only sympathise with existing committers!
I have been active in SWT for an year by now, but was unable to make lot of contributions. This year I switched gears and started contributing to platform UI. I have made good progress so far, thanks to very active and helpful committers in the repo! I started with easy refactorings, but soon able to implement UI features and now also started picking up end-user reported issues: all in a very short period of time.
I want to continue to work on SWT: either as a contributor in which case I need a little more attention from reviewers (I know Open Source Software is voluntary) with improving the code base as the goal, or as a committer in which case I can make more calculated, independent decisions.
I have removed myself from codeowners list as this was putting false expectation by auto assigning me as a reviewer.
I'm still around but this is mostly in case of emergency, answering question and/or fixing bug that bother company/me as keeping the overall SDK deliverable in decent shape, overall releng improvements and lately trying to find time for new JVM versions support gives me zero time for SWT specific work.
From SWT-GTK POV (the only part I have experience with) Gtk 4 port is what is needed desperately as otherwise Eclipse on Linux will suffer another tough transition period just like when Gtk 2 to Gtk 3 happened - a choice of many small bugs in many widgets or totally non-functional widgets .
Regarding new contributors - every committer is supposed to nominate new ones if/when he/she is confident the nominee is a person we can trust to act carefully and in best interest of the project and shown some decent knowledge on the topic. P.S. Note no "experts" requirements as there are tons of low hanging fruits to be picked up!
I have sent a couple of pull requests lately and they had to wait a longer time to be reviewed. Our company Syntevo is paying @SyntevoAlex for his contributions to SWT, specifically, mostly to fix bugs we found in SWT with our products SmartGit, SmartSynchronize, ....
I think, it would make sense that the contributers help each other to review pull requests. I would try to be available as reviewer, however, I'm just a Java developer without native GUI programming experience. Hence, I only could review Java code and from the perspective of a non-Eclipse user.
As a relatively new committer to SWT I'm not entirely clear about the process for approving and merging PRs.
For example, a PR from someone else and on which I have commented:
https://github.com/eclipse-platform/eclipse.platform.swt/pull/771
What happens now? Do we have to wait for all reviewers to approve it? Who will merge it?
Another example, a PR from me:
https://github.com/eclipse-platform/eclipse.platform.swt/pull/969
Again, do I have to wait for all reviewers to approve it? Who will merge it?
Generally, what's the best (and polite) way to get pending PRs approved and merged?
My understanding is that as a committer, you can merge whatever you want (with some legal exceptions) whenever you please (except for when master is closed for upcoming release).
A more polite way however is to give people some time (3 days or so) to react and maybe review. If nobody shows up, then you just merge.
If you come across non-committer's PR, you're welcome to review and merge it.
@Phillipus With current man power - as long as you approve a patch please merge both yours and others . There could be cases for some patches that one may ask for extra reviews preferably by asking concrete person for that and even in that case one doesn't have to wait indefinitely.
@Phillipus You should feel empower to merge commits when they are, in your personal opinion, complete. It's not necessary for all reviewers to complete their reviews. It's polite to give folks some time to review, but not everyone has enough time. Another general problem is (at least for me), that I get floods of email about every little thing that happens in 20 or more projects so it's all too easy to overlook an email...
OK, thanks for feedback.
Another question - what's the best way to merge a PR? From the GitHub web interface with the green button that has "Squash and merge" and "Rebase and merge" options? Or from client git (I use SmartGit).
OK, thanks for feedback.
Another question - what's the best way to merge a PR? From the GitHub web interface with the green button that has "Squash and merge" and "Rebase and merge" options? Or from client git (I use SmartGit).
"Rebase and merge" from GH in order to keep the history linear (where possible) is what I do. I haven't experimenting with other means to merge as this worked just fine for me.
In general you should use the WebUI. It depends of corse as always but I most often ask the author to have ONE commit maybe squash and rebase these and the use the rebase+merge.
In general you should use the WebUI. It depends of corse as always but I most often ask the author to have ONE commit maybe squash and rebase these and the use the rebase+merge.
Right. In the case of https://github.com/eclipse-platform/eclipse.platform.swt/pull/771 it needs both a squash and a rebase.
In general you should use the WebUI. It depends of corse as always but I most often ask the author to have ONE commit maybe squash and rebase these and the use the rebase+merge.
Right. In the case of #771 it needs both a squash and a rebase.
Yes that would be good if you are unsure you can always ask for help in the PR if it is just "how should it be merged" its likley someone is responding fast with an advice as this is less effort than review the whole thing.
In general you should use the WebUI. It depends of corse as always but I most often ask the author to have ONE commit maybe squash and rebase these and the use the rebase+merge.
Right. In the case of #771 it needs both a squash and a rebase.
If a rebase is required, I would perform the rebase locally, test the result and push. If a rebase again is required because main has proceeded in the mean time, I'd perform these steps again.
Can we have some quick "go to" persons per platform listed who can be mentioned for review/merge/test, myself being not a committer yet but interested to be a committer in SWT. I am happy to review and test prs that flow in on windows(actively doing it by the way already).
Other small improvements if they can be considered as listed below
- Can the committers/"anyone aware of the issue" also mark some issues with "good first issue" label when they find such for the new people starting with SWT.
- Also can we increase the usage of labels for the open issues please so that it helps people pick issues of their interest and not spend too much time to "pick an issue" for investigation.
Can we have some quick "go to" persons per platform listed who can be mentioned for review/merge/test,
Usually, looking at the history of the file(s) you've changed allows to build such a list.
Can we have some quick "go to" persons per platform listed who can be mentioned for review/merge/test,
Usually, looking at the history of the file(s) you've changed allows to build such a list.
But sometimes we get those names who are no more active in the repo right now say for example for the issue => https://github.com/eclipse-platform/eclipse.platform.swt/issues/791 I need some pointers to proceed further on the issue though i got to the root cause of the issue.
@deepika-u The source of truth for that should be https://github.com/eclipse-platform/eclipse.platform.swt/blob/master/CODEOWNERS .
If someone doesn't feel like being bugged too much with that, being inactive, etc. - that path is like https://github.com/eclipse-platform/eclipse.platform.swt/commit/ac0c46b273b409f8e73f10ff098b13a5288c5e75 .
If someone feels like he wants to be added as a reviewer and take greater responsibility - the opposite to the my patch would be needed.
I like this constructive discussion. You sorted out quite some points. Are they all somewhere documented in SWTs contributors guide? So that we can find this information easily again?
@BeckerWdf I really have no idea which information you would like to be in which document so please add it wherever you see relevant.
After more than a year I'm closing this issue as it's really non-actionable. It's best if whoever is still active to spend time on PRs.