A suggestion for a more simple mostly automated way to test a patch.

[the-snowwhite]

The presentation:

In my first adventure of being able to fix 2 Eclipse bugfix issues: #851

There was a moment where I fumbled the ball being unable to answer a simple question:
beginning with this request:
#879 (comment)
(arrived in my mail-inbox: Fri, 10 Nov 2023 06:16:22 -0800)

And the first arrival of the question was:
(arrived in my mail-inbox: Fri, 10 Nov 2023 08:57:50 -0800 )

The moment I fumbled was:
here:
#879 (comment)
(arrived in my mail-inbox: Fri, 10 Nov 2023 09:38:26 -0800)

The time the (correct) decision was made assuming a yes.
(arrived in my inbox:Fri, 10 Nov 2023 10:23:39 -0800 )

the moment I was able to input the correct answer to this very simple question via the method requested was the time stamp of this comment :
#851 (comment)
(right now it says 17 hours ago and my local time is now 16:12 GMT+1 Copenhagen).

So how much time and frustration could have been saved via more automation of the #858 process ?

So that the required swt binaries could be made via a pull request like process ?

This is the end of the time stamped opening more will follow shortly.

[the-snowwhite]

An unmentioned first step (1.a) in the #858 process is to create a usable patch, by picking out the relevant commits,
and theh rewording them to something github likes (changing only the commit messages).
last part of this step is committing to your local branch.
the patch I came up with is right now linked to in this comment:
#851 (comment)

As a test I then made a PR to R_29_Maintenance:

[the-snowwhite]

@mickaelistria
@iloveeclipse

Will you please answer this simple question

Would this proposal have made things easier yesterday ?

The proposal:

If the Releng builds could be made able to provide the build artifacts to the users (Like in current Machinekit).
preferably via a link in the PR gui.
It would make i much easier to test PR's and make the #858 as easy as;
download, rename 3 files(could be skiped if the build names them correctly), copy them in plugins folder, test in your current Stable Eclipse release.(Or whatever there are branches for).

Originally posted by @the-snowwhite in #881 (comment)

the builder only needs to run the same mvn commands as those i copied from the the jenkins build console:
steps 8 and 9 of the #858 process

[mickaelistria]

The SWT artifacts are archived on CI for each build upon success. You can for example get the one PR-883 would generate at https://ci.eclipse.org/releng/job/eclipse.platform.swt/view/change-requests/job/PR-883/lastSuccessfulBuild/artifact/eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.x86_64/target/

[the-snowwhite]

OK
If I understand this correctly the ones for #881 would then now be at:
https://ci.eclipse.org/releng/job/eclipse.platform.swt/view/change-requests/job/PR-881/lastSuccessfulBuild/artifact/eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.x86_64/target/

Without the need for a merge if that build had succeeded ?

(I think that a re-visit from dependa-bot is all that is needed for the build to succeed)
Hmmm
that seems to have been done:
https://github.com/the-snowwhite/eclipse.platform.swt/commits/R4_29_maintenance

[the-snowwhite]

The build seemed to fail with this (non commit related) message:

[ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:4.0.2:compare-version-with-baselines
(compare-attached-artifacts-with-release) on project org.eclipse.swt: Only qualifier changed for 
(org.eclipse.swt/3.124.100.v20231111-0040). Expected to have bigger x.y.z than what is available in baseline 
(3.124.100.v20230825-1346)

familiar ?

[the-snowwhite]

I found 2 of the 3 files needed in
https://ci.eclipse.org/releng/job/eclipse.platform.swt/view/change-requests/job/PR-883/lastSuccessfulBuild/artifact/eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.x86_64/target/

However I also seemed to need to replace:
/home/mib/.p2/pool/plugins/org.eclipse.swt_3.124.100.v20230825-1346.jar

with the renamed version of:

mib@neon-am5:~/.m2/repository/org/eclipse/swt/org.eclipse.swt/3.124.100-SNAPSHOT$ ls -l

-rw-rw-r-- 1 mib mib 19245 nov 10 21:53 org.eclipse.swt-3.124.100-SNAPSHOT.jar

(its only 18.8kb)

before the patched Eclipse would startup correctly ?

I think this file is from the second mvn build not the first build of the binaries repo.

[the-snowwhite]

OK
I think it is at this location:
https://ci.eclipse.org/releng/job/eclipse.platform.swt/view/change-requests/job/PR-883/lastSuccessfulBuild/artifact/eclipse.platform.swt/bundles/org.eclipse.swt/target/

[the-snowwhite]

This leads the to the next logical question:
Why did the build fail with these messages

[ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:4.0.2:compare-version-with-baselines
(compare-attached-artifacts-with-release) on project org.eclipse.swt: Only qualifier changed for 
(org.eclipse.swt/3.124.100.v20231111-0040). Expected to have bigger x.y.z than what is available in baseline 
(3.124.100.v20230825-1346)

and these messages in the build console:

02:12:30  [ERROR] Failed to execute 
goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:4.0.2:compare-version-with-baselines (compare-attached-artifacts-with-release) 
on project org.eclipse.swt: Only qualifier changed for (org.eclipse.swt/3.124.100.v20231111-0040). 
Expected to have bigger x.y.z than what is available in baseline (3.124.100.v20230825-1346) -> [Help 1]
02:12:30  [ERROR]
02:12:30  [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
02:12:30  [ERROR] Re-run Maven using the -X switch to enable full debug logging.
02:12:30  [ERROR]
02:12:30  [ERROR] For more information about the errors and possible solutions, please read the following articles:
02:12:30  [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
02:12:30  [ERROR]
02:12:30  [ERROR] After correcting the problems, you can resume the build with the command
02:12:30  [ERROR]   mvn <args> -rf :org.eclipse.swt

update:

Only qualifier changed for 

(org.eclipse.swt/3.124.100.v20231111-0040). Expected to have bigger x.y.z than what is available in baseline
(3.124.100.v20230825-1346)

in the first message and

and

(org.eclipse.swt/3.124.100.v20231111-0040). Expected to have bigger x.y.z than what is available in baseline 
(3.124.100.v20230825-1346)

in the second message seem to stand out ?
also is the failure in any way related to #868 ?

[the-snowwhite]

From the #881 PR build console.log the last command run is:

mvn clean verify --batch-mode -DforkCount=0 -Dcompare-version-with-baselines.skip=false -Dmaven.compiler.failOnWarning=true -Dmaven.test.failure.ignore=true -Dmaven.test.error.ignore=true

in folder:

/home/jenkins/agent/workspace/eclipse.platform.swt_PR-881/eclipse.platform.swt

The summary and Error messages block contains:

02:12:29  [INFO] ------------------------------------------------------------------------
02:12:29  [INFO] Reactor Summary:
02:12:29  [INFO]
02:12:29  [INFO] eclipse.platform.swt 4.29.0-SNAPSHOT ............... SUCCESS [  6.244 s]
02:12:29  [INFO] org.eclipse.swt 3.124.100-SNAPSHOT ................. FAILURE [ 21.402 s]
02:12:29  [INFO] org.eclipse.swt.fragments.localbuild 3.105.0-SNAPSHOT SKIPPED
02:12:29  [INFO] org.eclipse.swt.tools.base 3.107.400-SNAPSHOT ...... SKIPPED
02:12:29  [INFO] org.eclipse.swt.tools.spies 3.109.100-SNAPSHOT ..... SKIPPED
02:12:29  [INFO] org.eclipse.swt.tools 3.110.100-SNAPSHOT ........... SKIPPED
02:12:29  [INFO] org.eclipse.swt.examples 3.108.100-SNAPSHOT ........ SKIPPED
02:12:29  [INFO] org.eclipse.swt.examples.browser.demos 3.108.100-SNAPSHOT SKIPPED
02:12:29  [INFO] org.eclipse.swt.examples.launcher 3.108.100-SNAPSHOT SKIPPED
02:12:29  [INFO] org.eclipse.swt.examples.ole.win32 3.108.100-SNAPSHOT SKIPPED
02:12:29  [INFO] org.eclipse.swt.examples.views 3.108.100-SNAPSHOT .. SKIPPED
02:12:29  [INFO] org.eclipse.swt.tests 3.107.100-SNAPSHOT ........... SKIPPED
02:12:29  [INFO] org.eclipse.swt.tools.feature 3.109.100-SNAPSHOT ... SKIPPED
02:12:29  [INFO] org.eclipse.swt.tests.gtk 3.109.0-SNAPSHOT ......... SKIPPED
02:12:29  [INFO] ------------------------------------------------------------------------
02:12:29  [INFO] BUILD FAILURE
02:12:29  [INFO] ------------------------------------------------------------------------
02:12:29  [INFO] Total time:  01:36 min
02:12:29  [INFO] Finished at: 2023-11-11T01:12:29Z
02:12:29  [INFO] ------------------------------------------------------------------------
02:12:30  [ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:4.0.2:compare-version-with-baselines (compare-attached-artifacts-with-release) on project org.eclipse.swt: Only qualifier changed for (org.eclipse.swt/3.124.100.v20231111-0040). Expected to have bigger x.y.z than what is available in baseline (3.124.100.v20230825-1346) -> [Help 1]
02:12:30  [ERROR]
02:12:30  [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
02:12:30  [ERROR] Re-run Maven using the -X switch to enable full debug logging.
02:12:30  [ERROR]
02:12:30  [ERROR] For more information about the errors and possible solutions, please read the following articles:
02:12:30  [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
02:12:30  [ERROR]
02:12:30  [ERROR] After correcting the problems, you can resume the build with the command
02:12:30  [ERROR]   mvn <args> -rf :org.eclipse.swt

[the-snowwhite]

https://ci.eclipse.org/releng/job/eclipse.platform.swt/view/change-requests/

PR-890	15 hr #1	N/A	2 hr 3 min		46

PR-890 15 hr #1 N/A 2 hr 3 min 46

I think this shows that I could have answered the question as yes without doubt on time.

[the-snowwhite]

I'm currently assimilating
eclipse-platform/eclipse.platform.releng.aggregator#863
To see if anything there can get me out of my Do not merge PR sandbox dilemma stalemate situation.

in #890
as a result of #881 and #858

Just because i was unsatisfied with this answer
@mickaelistria @iloveeclipse @sravanlakkimsetti @merks
Any suggestions ?

[the-snowwhite]

The Eclipse Versioning Numbering Document has following things to say about bug fixes:

Each segment captures a different intent:

the major segment indicates breakage in the API
the minor segment indicates "externally visible" changes
the service segment indicates bug fixes and the change of development stream (the semantics attached to development stream is new to this proposal, see below)
the qualifier segment indicates a particular build

The minor segment number must be incremented when a plug-in changes in an "externally visible" way. Examples of externally visible changes include binary compatible API changes, an updated BREE (Bundle-RequiredExecutionEnvironment), significant performance changes, major code rework, adding a new extension point, changing files with a somewhat unclear API status (e.g. changing icons from gif to png), etc. Another way to know when this version number should be changed is by exclusion: it should indicate changes that are neither bug fixes (indicated by the service segment) nor breaking API changes (indicated by the major segment). When the minor segment is changed, the service segment is reset to 0.

I think this confirms the LLM's (Chatgpt4) analysis is correct.

Analysis of 3.124.100.qualifier and 3.124.101.qualifier

Major Version (3): Both versions have the same major version number (3), indicating that there are no breaking changes in the API between these two versions.
Minor Version (124): The minor version is also the same in both cases, suggesting that no new "externally visible" features or significant changes have been introduced.
Service Version (100 vs. 101):
    The service version has incremented from 100 to 101. This increment typically indicates bug fixes or other changes that are not visible in the API.
    According to the Eclipse guidelines, if a change occurs in a service release, then the number is incremented by 1. If it happens for the next official release, 100 is added.
Qualifier Segment (qualifier): This is a placeholder segment used to indicate specific builds. In actual usage, this would be replaced by a more specific string, often a date or build identifier.

Implications of the Version Change

The change from 3.124.100.qualifier to 3.124.101.qualifier indicates a progression in the development of the software, most likely due to bug fixes or minor changes that do not affect the API or the external functionality of the software.
This versioning approach allows for detailed tracking of changes and helps in maintaining compatibility, especially in a complex software ecosystem like Eclipse.
By following these guidelines, Eclipse ensures consistent and predictable management of its software versions, facilitating the understanding of the nature and impact of changes for developers and users alike.

The detailed versioning system in Eclipse, as described in the Eclipse_versioning_numbering.txt file, reflects a comprehensive approach to software development and release management, crucial for large-scale and modular software projects.

This means that #851
could have been labeled bug:
I don't know why this didn't happen
I thought I was adding a new feature.

[basilevs]

This happened to me in #883. The key to solution was to ignore any and all errors from API Tools in PDE and rely on CI to correctly verify API changes. It is slow, but configuring API tools to work correctly locally is just impractical for a new contributor.
Also, do not touch versions unless CI orders to do so.