You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The reason will be displayed to describe this comment to others. Learn more.
I find this a good practice
I don't doubt that it is, but as of today it isn't common in the Jenkins community among people releasing plugins or core components manually (i.e., not with JEP-229). If we want to go in this direction, I think it would be a good idea to start a developer list thread about it and to update the developer documentation with instructions so that all developers can follow this best practice as they do manual releases.
The reason will be displayed to describe this comment to others. Learn more.
I don't intentionally sign anything, but maybe GitHub signs them when I use the web interface to merge a PR. I don't know how to sign things that are committed manually and I don't think most Jenkins developers are doing this today, which is why I think you would have more luck convincing people to do what you want through a mailing list thread and documentation rather than leaving comments on already shipped releases for some particular component.
583f671
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@basil could you please sign tag as well? thanks
583f671
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could, but I see no reason to do as you have requested.
583f671
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find this a good practice. probably even more important signing commits as this is what is delivered.
But anyway it's up to you.
583f671
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't doubt that it is, but as of today it isn't common in the Jenkins community among people releasing plugins or core components manually (i.e., not with JEP-229). If we want to go in this direction, I think it would be a good idea to start a developer list thread about it and to update the developer documentation with instructions so that all developers can follow this best practice as they do manual releases.
583f671
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just do not find it consistent to sign your commits but not for the release.
But As I said,
583f671
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't intentionally sign anything, but maybe GitHub signs them when I use the web interface to merge a PR. I don't know how to sign things that are committed manually and I don't think most Jenkins developers are doing this today, which is why I think you would have more luck convincing people to do what you want through a mailing list thread and documentation rather than leaving comments on already shipped releases for some particular component.