Unable to sync my fork today.

[the-snowwhite]

I get this error message:
protected branch 'master' check failed: Commits must have valid signatures.
Update:
I know see the error message:
This CODEOWNERS file contains errors …
In the last commit to master branch.
Best whishes

[mickaelistria]

This is not a project issue, but most likely an issue with your usage of Git. Discussions are more appropriate for such support that is not related to project code. So I'm converting it to discussion.

[the-snowwhite]

Sorry for dragging in the topic of LLM's here however I would like to notify you that recently it has become possible to ask Chatgpt4
Questions like the 2 below via Bing.

Me: please analyze #893 in regards to https://wiki.eclipse.org/Version_Numbering

It: From the information available, it appears that the discussion on GitHub (#893) is not directly related to the version numbering guidelines. The discussion on GitHub deals with a specific issue in syncing a fork and is a Git-related issue, while the Eclipse version numbering guidelines provide a framework for how to version Eclipse plug-ins based on the nature of changes made.

Me: please analyze what changing v20231113-1333 to forceContextQualifier>v20231113-1355 in regards to https://wiki.eclipse.org/Version_Numbering is about.

IT: In summary, changing the forceContextQualifier in the manner described is about identifying a different build of the software, with the qualifier providing specific information about the build time. This change aligns with the Eclipse version numbering guidelines, which recommend using the qualifier segment for such purposes​

[mickaelistria]

ChatGPT is likely to be wrong (really don't put too much trust in it, the assertive tone of the answers doesn't make them necessary reliable) as the documentation above forceContextQualifier mentions, and the git blame for that line mentions too; the version is supposed to be changed by the build process according to other parameters.
However, 1 issue is that since there is no ongoing build process for 4.29, it could be that this version is now incorrect. But the solution is there to revive the build process for 4.29 to properly update the qualifier more than randomly changing the value here.
As the project won't revive 4.29 build, I think you just have to deal with the build part on your end with local builds as you see fit; but the manual change to qualifiers are likely not welcome in a PR.

[the-snowwhite]

I would like to ask:
What is dependabot[bot] ?

[the-snowwhite]

@mickaelistria
I have spent some time analyzing #851
around the point when it was closed

There is an odd unintended pattern with commits with me as the owner from:
2a5264b
(when the issue was closed)
To:
#879
(which only merged the Polished version of the second commit added to #851 )

Or from:
2a5264b
I Think the source of this suggestion was the one who polished my second commit.
to:
https://github.com/eclipse-platform/eclipse.platform.swt/pull/879/files/5c6a7a7a38b1fbbb373c408780c40cb24efddf96#

And where I fumbled the ball not being able to verify:
UTF8_STRING_ID = TEXT_PLAIN_UTF8_ID

and that there was no need to:
// Convert the text into RFC-1341 format

[the-snowwhite]

Thank you this is better than creating a blank issue.

[the-snowwhite]

The compare button shows this message:
Akurtakov no longer codeowner for gtk port
And I received a a very informative mail in my inbox from him. 4 days ago.

[the-snowwhite]

Also this is what fails to validate:
v20231113-1333
v20231113-1355