Closed HannesWell closed 1 month ago
eparovyshnaya
commented
1 month ago Dear @HannesWell
Pasasge project, as, I suppose, any stable project should do, clings to reason-based changes and avoids changes for the sake of themselves.
Perfect place to stand the reason is a ticket, which also appears to be mandatory according to the project development policy, upon which fact I, actually, am a bit tired of making notes.
HannesWell
commented
1 month ago Pasasge project, as, I suppose, any stable project should do, clings to reason-based changes and avoids changes for the sake of themselves.
Absolutely.
Perfect place to stand the reason is a ticket, which also appears to be mandatory according to the project development policy, upon which fact I, actually, am a bit tired of making notes.
I read your notes, but I have to admit I don't understand why this rule has been introduced in the first place? Github Pull-Requests and issues offer the same capabilities to discuss changes. So having an issue is not an advantage if the code-change is already made. Discussing a topic before something is changed is of course valid, but if the changes is already made discussing at the PR has the advantage that everything is at one place and one can discuss with the changed code. Therefore the Eclipse PMC already decided in March 30, 2022 to remove the obligation to create an issue for all Eclipse top-level projects. We even actively encourage contributors to not create issues, IF the change is small or obvious and they have a PR already prepared for the reasons mentioned above and to avoid unnecessary noise and work. If one wants to discuss a bigger change in advance in an issue that's of course also fine. In times of Gerrit and Bugzilla mandating to create always a bug was useful because Gerrit's capabilities to discuss changes and search them were different, but in GH PRs are AFAIK inferior in no point compared to issues (you find them in the search, assign them to milestones, discuss everything etc.).
Therefore I would like to ask you again to explain why you introduced that rule in https://github.com/eclipse-passage/passage/pull/1134. Because everything that is mentioned there to be done at an issue can also be done in a PR. Therefore I simply don't understand why it was mandated and why such workflow would improve the stability or is an indicator for stability. The most stable project I know is EMF and not even there such rule exist and changes can just be discussed at PRs.
If the initial description of my PR is not clear I can of course update it.
eparovyshnaya
commented
1 month ago @HannesWell Having a ticket is mandatory for Passage project (any project, actually, especially one of low resources) management beacuse it is the most effective instrument that establishes clean, tracable and easily discoverable connection between cause and effect.
Ticket states the problem (cause). Merge request offers a solution (effect).
There can be many merge requests (effects), solving the same problem (following the same cause). And for each of them cause is begetting.
Effect can only appear strictly after cause. That's the basis of casual reasoning, which should be main tool for project management and maintenance.
If a solution is offered and right in it a problem is just mentioned,
Being that said, I'd again ask you to create a ticket that states an actual problem for this merge request (a cause for this effect). In it we will discuss practical value of the problem, this solution applicability and any other aspects should the need arise.
HannesWell
commented
1 month ago Theoretically all your points are right, but in practice it generates more work for everybody, especially contributors, if creating issues for every change is mandatory. My intention is to make contributions more efficient, because contributors are often low on resources too. And I want to emphasize that I only suggest to revoke that makes rule issues mandatory, I don't suggest to avoid issues in general since there are definitely cases where there are helpful, for example the ones you mentioned.
Anyway it seems you have made your decision, so I will just do the extra work. I hope it helps to get this and #1362 resolved.
HannesWell
commented
1 month ago eparovyshnaya
commented
1 month ago The changes you proposed are considered too radical and questionable.
Nevertheless, we thank you verty much for your time spent on this, @HannesWell It, just for one, lead to several critical LOC fixes.
The OSGi-DS component XML files are generated in the IDE (by PDE) and while building Passage (with Maven+Tycho) in the CI. Therefore there is no need to maintain the component xml-files in git, which is also prone to out-of-sync errors as fixed with https://github.com/eclipse-passage/passage/pull/1362.
Fixes https://github.com/eclipse-passage/passage/issues/1365.