I have one question, as I make my last PR I have seen that tests startet like codacy and travis ci. My question is should I also make the codacy and travis ci tests local on my repo befor I make a PR ? If yes have you an introduction for setting up codacy and travis ci. Thank you very much.
@Memo2109 No, you don't have to add the checks to your local fork of the repository. As you already pointed out, they are always run when you create a PR onto the main repo.
I changed the description of the Area: X issue labels to state "Issues affecting X". In my opinion, this makes the tags much more usable as they then provide a good tool for getting an overview which PRs affect which area of the code. In my opinion, the current restrictions of having them be "specific to the area" makes sense for issues but not for PRs, as they often bundle multiple commit dealing with different parts of an issue.
Anyone have any issues with this change?
What do you think about 12.12 at 16:30 (I am flexible, we can change the date/time)?
12.12. at 16:30 isn't ideal for me. I have a meeting at 15:15 for which I don't know how long it is going to take. I could be done by 15:45 but it could easily also take until 17:00 (or longer), depending on my waiting time.
For me, the following dates would work better:
- the 9.12. (any time)
- the 10.12. (any time)
- the 11.12. before 17:00
- the 12.12. before 14:30
- the 13.12. (any time)
Or, if don't find any other date/time, you could keep the session on the 12.12. at 16:30 (or 17:00) and I will join in as soon as I can.
What a pity! Sure, I will send you an email.
Do you want to announce some annotation fixes with the new release while there are still issues with them ?
Do you talk about the issue #32 ?
I just noticed that the "Terminate Session" icon (the stop button; adjusted leave session icon on host side) does not get reset to the default "lease session" icon (the door) on session end. This isn't strictly an issue as the icon gets set correctly when a new session is started as a client, but it still seems weird to me as it leads to an inconsistent UI in the disconnected state.
My inclination would be to create an issue for this and mark it as "Prio: Low" and "Help Wanted" & "good first issue" as it is not strictly necessary but nice to have to be consistent.
Any input on this?
Hi, we have multiple stale PRs that are not updated in the last two months.
I would like to avoid a graveyard of old PRs. Therefore, could we clarify which PRs "can be closed" (if so, please close the PR and remove the branch), "is in review" (if so, we should complete the review),...
@srossbach #341 #349 #477 #615 #629 #651 #654 #653
@tobout #395 #681 #748 #750
@stefaus #426
@m273d15 #691
@Memo2109 #772 (IIRC you already said that you will close the PR)
If you want to preserve the commits, because you want to use the code in the future, please close the PR without deleting the branch.
@m273d15 I think I found another flaky STF test: saros.stf.test.roster.HandleContactsTest. See test run and failure report.
The run was started after rebasing the PR and doing some minor changes that should not be able to influence the result. The previous STF run and the STF run on the base branch I rebased on both succeeded and the test runs successfully in my local environment.
If you have suggestions for improvement let me know. My TODOs are: Choose a less aggressive blue, fix broken links, fix table borders.
Hi, I created a new version of the Saros page: https://m273d15.github.io/saros/
If you have suggestions for improvement let me know. My TODOs are: Choose a less aggressive blue, fix broken links, fix table borders.
@m273d15 My list got to long, so I decided to create an issue for it: saros-project/saros#896
EditDuringInvitationStressTest.testEditMultipleClassesDuringInvitation() can fail more than 4 times in a row when run as part as the GitHub action (see build1 and build2). This is also the test that caused the majority of STF failures in the past. So maybe we should mark this test as flaky as well.
Could we also adjust the STF setup to unify the handling of the used build version?
I opened a corresponding PR #951
Totally ok if you do not have them yet, just curious if you have plans for them.
Do you have or have plans for:
- "Shared port", ability to tunnel a specific port, such that participants can execute REST calls against the app running on the HOST's machine
- "Shared terminal", while risky from the security point, it might be nice to have as a feature to troubleshoot Docker issues (for example).
__
Both ideas come from looking at the list of features supported by VSCode LifeShare.
@voronaam Hi, currently we do not plan to implement "Shared Ports" or "Shared Terminals" because we have limited resources and try to focus on synchronizing and sharing code.
If you are interested in our plan:
- The next big thing will be the support of Saros sessions between different IDEs (Eclipse and IntelliJ).
- Furthermore, we would like to support further IDEs/Editors in the future.
- We want to complete the IntelliJ support (still an alpha version).
Because of the idea of sessions between different IDEs we want to avoid integrating deeply into one IDE/Editor (because this could lead to feature sets that are only supported in one IDE).
And from recent build results, it seems like
EditDuringInvitationStressTest.testEditMultipleClassesDuringInvitation()can fail more than 4 times in a row when run as part as the GitHub action (see build1 and build2). This is also the test that caused the majority of STF failures in the past. So maybe we should mark this test as flaky as well.
This was one of the major requirements in the past. You should be able to modify anything you want while another user joins the session because sometimes it takes "a little bit longer" for someone to join a session / complete the resource negotiation and therefore putting the whole session on hold was not a solution.
@srossbach When having a look at the Eclipse EditorManager, I noticed that most of the logic using the EditorPool to obtain open shared editors only uses the IEditorPart objects of the mapping and ignores the mapped IFile objects. Instead, the Eclipse IFile for the editor is requested and then converted to a Saros IFile object.
Is there a specific reasoning for this handling? Can the editor pool mapping be outdated, making it preferable to look up the actual, current file for the editor?
This makes a difference for the migration to the new reference point model as it is no longer as easy/convenient to convert from an Eclipse resource to a Saros resource. Instead of just wrapping the object, the new logic has to check for every shared reference point whether the resource is one of its children and the calculate the reference-point-relative path. This creates a lot of unnecessary overhead for the lookup, which is why I would prefer to instead just request the complete mapping from the editor pool.
The reason for the breaking build is the exception (e.g. in EditorAPITextPositionTest.testCalculateOffsetsOneLineSelection):
java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
no swt-pi4-gtk-4934r6 in java.library.path
no swt-pi4-gtk in java.library.path
Can't load library: /root/.swt/lib/linux/x86_64/libswt-pi4-gtk-4934r6.so
Can't load library: /root/.swt/lib/linux/x86_64/libswt-pi4-gtk.soThis is an issue in :saros.eclipse:test. It is strange that this issue only occurs in the STF workflow. Therefore, the next step is to compare the execution environment (I assume that setting the JDK instead of using the default could fix it).
