Aw: Re: Which build has that fix?
Thats a nice idea. But I wonder about 2 points:- what if you forgot to put [FIXED JENKINS-12345] into the commit message. If it havent been released, yet, its certainly easy to add a bogus commit with that message, but what if it was already released?- what if you want to add more info in the changelog (announcement of new features, warnings about backward-incomaptible changes, migration steps)? That is IMO not something which belongs into a commit message. Gesendet:Montag, 18. Februar 2013 um 20:20 Uhr Von:Jesse Glick jgl...@cloudbees.com An:jenkinsci-dev@googlegroups.com Betreff:Re: Which build has that fix? On 02/17/2013 05:23 AM, Christoph Kutzinski wrote: Another nuisance are the frequent merge conflicts on changelog.html Yes, this complicates pull requests, and makes backporting fixes to the stable branch painful too. A rough idea would be to create a new single file (XML or so) for each changelog entry and let the release process merge this into a single changelog.html. Better to not store changelog.html in Git at all. Just provide a tool to generate target/changelog.html from the Git changelog leading up to the revision you have checked outthe only real truth, after all. Commit messages including keys such as [FIXED JENKINS-12345] or [SECURITY-99] or Merged pull request #1001 would produce sensible hyperlinks. autochangelog-maven-plugin [1] could probably be adapted to this purpose. [1] https://github.com/cloudbees/autochangelog-maven-plugin -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Which build has that fix?
Jesse, I think I have you spoiled with the 'Bees release notes app... even with the complaints you file in redmine! On 18 February 2013 19:20, Jesse Glick jgl...@cloudbees.com wrote: On 02/17/2013 05:23 AM, Christoph Kutzinski wrote: Another nuisance are the frequent merge conflicts on changelog.html Yes, this complicates pull requests, and makes backporting fixes to the stable branch painful too. A rough idea would be to create a new single file (XML or so) for each changelog entry and let the release process merge this into a single changelog.html. Better to not store changelog.html in Git at all. Just provide a tool to generate target/changelog.html from the Git changelog leading up to the revision you have checked out—the only real truth, after all. Commit messages including keys such as ‘[FIXED JENKINS-12345]’ or ‘[SECURITY-99]’ or ‘Merged pull request #1001’ would produce sensible hyperlinks. autochangelog-maven-plugin [1] could probably be adapted to this purpose. [1] https://github.com/cloudbees/**autochangelog-maven-pluginhttps://github.com/cloudbees/autochangelog-maven-plugin -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@**googlegroups.comjenkinsci-dev%2bunsubscr...@googlegroups.com . For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Aw: Re: Which build has that fix?
On 02/19/2013 07:34 AM, Christoph Kutzinski wrote: what if you forgot to put ‘[FIXED JENKINS-12345]’ into the commit message. If it haven't been released, yet, it's certainly easy to add a 'bogus' commit with that message, but what if it was already released? There might need to be a way to add exceptions for cases like these, but I would hope it is easier to drill into people’s heads that commit messages must mention a filed issue than that an entry must be added to a specific section of a separate changelog.html. what if you want to add more info in the changelog Just put it in the commit message; or say to see JIRA for more background and details. Most changelog entries today are just one short line anyway. To put things into perspective, compare the current 1.480.3 changelog [1] with the actual contents of the release according to git log [2]. The latter is admittedly tidied up by hand, but what is more important is how much is outright missing from the former. [1] http://jenkins-ci.org/changelog-stable [2] http://release-notes.cloudbees.com/release/Jenkins+OSS+LTS/1.480.3 -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Which build has that fix?
On 02/17/2013 05:23 AM, Christoph Kutzinski wrote: Another nuisance are the frequent merge conflicts on changelog.html Yes, this complicates pull requests, and makes backporting fixes to the stable branch painful too. A rough idea would be to create a new single file (XML or so) for each changelog entry and let the release process merge this into a single changelog.html. Better to not store changelog.html in Git at all. Just provide a tool to generate target/changelog.html from the Git changelog leading up to the revision you have checked out—the only real truth, after all. Commit messages including keys such as ‘[FIXED JENKINS-12345]’ or ‘[SECURITY-99]’ or ‘Merged pull request #1001’ would produce sensible hyperlinks. autochangelog-maven-plugin [1] could probably be adapted to this purpose. [1] https://github.com/cloudbees/autochangelog-maven-plugin -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Which build has that fix?
Going back to Jesse's original email: I've committed my Issue Update Bot code to Github [1], although am waiting for my pull request on Github-API [2] to be accepted before anyone else could build this (unless they build a snapshot version of my changes [3]). The jenkins-issues bot is currently listening on* #jenkins-commits* for Github's IRC commit messages, and on *#jenkins* for admin messages. The bot is set in listen only mode for now so will not update Jira. I'll keep an eye on what it does for the next week to see if it's identifying previous release number properly before I then see if we want to put it in update mode. Does anyone have any comments on my suggestion of getting such a system to automatically create release numbers in Jira as releases are made and to then link fixed defect to that release number? I no-one comments here then I'll add it to the next Governance Meeting agenda. The bot is currently running from one of my test servers using my Jira login. If it is to be used long term then I'd recommend hosting it somewhere more permanent (i.e. alongside jenkins-admin or even integrating it into jenkins-admin) and providing it with its own Jira login (or using the SCM/Jira link deamon's account). Could I get any comments or improvements on the code for finding the previous release number: it works for the simple use cases I've tested but is reallytoo accepting of previous version numbers being the one that's wanted. Thanks, Michael [1] https://github.com/mc1arke/JenkinsReleaseIssueBot [2] https://github.com/kohsuke/github-api/pull/30 [3] https://github.com/mc1arke/github-api On 18 February 2013 19:20, Jesse Glick jgl...@cloudbees.com wrote: On 02/17/2013 05:23 AM, Christoph Kutzinski wrote: Another nuisance are the frequent merge conflicts on changelog.html Yes, this complicates pull requests, and makes backporting fixes to the stable branch painful too. A rough idea would be to create a new single file (XML or so) for each changelog entry and let the release process merge this into a single changelog.html. Better to not store changelog.html in Git at all. Just provide a tool to generate target/changelog.html from the Git changelog leading up to the revision you have checked out—the only real truth, after all. Commit messages including keys such as ‘[FIXED JENKINS-12345]’ or ‘[SECURITY-99]’ or ‘Merged pull request #1001’ would produce sensible hyperlinks. autochangelog-maven-plugin [1] could probably be adapted to this purpose. [1] https://github.com/cloudbees/**autochangelog-maven-pluginhttps://github.com/cloudbees/autochangelog-maven-plugin -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@**googlegroups.comjenkinsci-dev%2bunsubscr...@googlegroups.com . For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Which build has that fix?
Would be a nice addition.
Another nuisance are the frequent merge conflicts on changelog.html
A rough idea would be to create a new single file (XML or so) for each
changelog entry and let the release process merge this into a single
changelog.html.
Am 15.02.2013 13:56, schrieb cjo:
Keeping on the theme of improving the release process and correctly
tagging of issues to releases.
Seeing as Jesse keeps commenting on pull requests to add @since to new
classes/Methods.
Can there be a definition that developers can use that would be
replaced when the release is made,
so that the information is correct and developers do not need to guess
when their changes are going to be added/released into the core
I suggest that we have something like
JenkinsReleaseVersion
and we could reference it like
/**
* @since {JenkinsReleaseVersion}
*/
public String someMethod() {}
..
and at release time these would be replaced with the correct version
like 1.502
Chris
On Wednesday, 13 February 2013 23:14:04 UTC, Jesse Glick wrote:
We have some bot which comments in JIRA when a commit relating to
an issue appears in the trunk continuous build. This is fine and
well, but I have for one have never
wanted to know this.
What _is_ important is when the fix lands in an official (weekly)
release. Users frequently ask this [1] but it is awkward to find
the answer. The changelog [2] should
say, if the committer remembered to update the changelog, and you
know to click the “Upcoming changes” link.
If you have a source checkout you can use
---%--- ~/.gitconfig
[alias]
which = describe --contains
---%---
to get a clue where a change appeared, though only after the
release tag is made. And even for those who have the source
checkout, this is an annoying context switch when
you are reviewing historical issues.
Much nicer would be if some bot would add a simple comment to JIRA
after the release is published:
This fix is in Jenkins 1.502.
and link to the changelog. This would be clearly visible in the
issue history, and send notifications to watchers. Anyone capable
of making that happen?
[1]
https://issues.jenkins-ci.org/browse/JENKINS-15156?focusedCommentId=173823page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-173823
https://issues.jenkins-ci.org/browse/JENKINS-15156?focusedCommentId=173823page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-173823
[2] http://jenkins-ci.org/changelog http://jenkins-ci.org/changelog
--
You received this message because you are subscribed to the Google
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups Jenkins
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Which build has that fix?
+1 for generating changelog.html
On Sun, Feb 17, 2013 at 3:23 AM, Christoph Kutzinski ku...@gmx.de wrote:
Would be a nice addition.
Another nuisance are the frequent merge conflicts on changelog.html
A rough idea would be to create a new single file (XML or so) for each
changelog entry and let the release process merge this into a single
changelog.html.
Am 15.02.2013 13:56, schrieb cjo:
Keeping on the theme of improving the release process and correctly
tagging of issues to releases.
Seeing as Jesse keeps commenting on pull requests to add @since to new
classes/Methods.
Can there be a definition that developers can use that would be replaced
when the release is made,
so that the information is correct and developers do not need to guess
when their changes are going to be added/released into the core
I suggest that we have something like
JenkinsReleaseVersion
and we could reference it like
/**
* @since {JenkinsReleaseVersion}
*/
public String someMethod() {}
..
and at release time these would be replaced with the correct version
like 1.502
Chris
On Wednesday, 13 February 2013 23:14:04 UTC, Jesse Glick wrote:
We have some bot which comments in JIRA when a commit relating to an
issue appears in the trunk continuous build. This is fine and well, but I
have for one have never
wanted to know this.
What _is_ important is when the fix lands in an official (weekly)
release. Users frequently ask this [1] but it is awkward to find the
answer. The changelog [2] should
say, if the committer remembered to update the changelog, and you know to
click the “Upcoming changes” link.
If you have a source checkout you can use
---%--- ~/.gitconfig
[alias]
which = describe --contains
---%---
to get a clue where a change appeared, though only after the release tag
is made. And even for those who have the source checkout, this is an
annoying context switch when
you are reviewing historical issues.
Much nicer would be if some bot would add a simple comment to JIRA after
the release is published:
This fix is in Jenkins 1.502.
and link to the changelog. This would be clearly visible in the issue
history, and send notifications to watchers. Anyone capable of making that
happen?
[1] https://issues.jenkins-ci.org/**browse/JENKINS-15156?**
focusedCommentId=173823page=**com.atlassian.jira.plugin.**
system.issuetabpanels:comment-**tabpanel#comment-173823https://issues.jenkins-ci.org/browse/JENKINS-15156?focusedCommentId=173823page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-173823
[2] http://jenkins-ci.org/**changelog http://jenkins-ci.org/changelog
--
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an
email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an
email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Website: http://earl-of-code.com
--
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Which build has that fix?
Keeping on the theme of improving the release process and correctly tagging
of issues to releases.
Seeing as Jesse keeps commenting on pull requests to add @since to new
classes/Methods.
Can there be a definition that developers can use that would be replaced
when the release is made,
so that the information is correct and developers do not need to guess when
their changes are going to be added/released into the core
I suggest that we have something like
JenkinsReleaseVersion
and we could reference it like
/**
* @since {JenkinsReleaseVersion}
*/
public String someMethod() {}
..
and at release time these would be replaced with the correct version like
1.502
Chris
On Wednesday, 13 February 2013 23:14:04 UTC, Jesse Glick wrote:
We have some bot which comments in JIRA when a commit relating to an issue
appears in the trunk continuous build. This is fine and well, but I have
for one have never
wanted to know this.
What _is_ important is when the fix lands in an official (weekly) release.
Users frequently ask this [1] but it is awkward to find the answer. The
changelog [2] should
say, if the committer remembered to update the changelog, and you know to
click the “Upcoming changes” link.
If you have a source checkout you can use
---%--- ~/.gitconfig
[alias]
which = describe --contains
---%---
to get a clue where a change appeared, though only after the release tag
is made. And even for those who have the source checkout, this is an
annoying context switch when
you are reviewing historical issues.
Much nicer would be if some bot would add a simple comment to JIRA after
the release is published:
This fix is in Jenkins 1.502.
and link to the changelog. This would be clearly visible in the issue
history, and send notifications to watchers. Anyone capable of making that
happen?
[1]
https://issues.jenkins-ci.org/browse/JENKINS-15156?focusedCommentId=173823page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-173823
[2] http://jenkins-ci.org/changelog
--
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Which build has that fix?
could be dangerous... what happens when the commit gets cherry-picked
back... you'd then have @since 1.480.4 and @since 1.502 and the reality is
you can only rely on it with 1.502+
On 15 February 2013 12:56, cjo cjo.john...@gmail.com wrote:
Keeping on the theme of improving the release process and correctly
tagging of issues to releases.
Seeing as Jesse keeps commenting on pull requests to add @since to new
classes/Methods.
Can there be a definition that developers can use that would be replaced
when the release is made,
so that the information is correct and developers do not need to guess
when their changes are going to be added/released into the core
I suggest that we have something like
JenkinsReleaseVersion
and we could reference it like
/**
* @since {JenkinsReleaseVersion}
*/
public String someMethod() {}
..
and at release time these would be replaced with the correct version like
1.502
Chris
On Wednesday, 13 February 2013 23:14:04 UTC, Jesse Glick wrote:
We have some bot which comments in JIRA when a commit relating to an
issue appears in the trunk continuous build. This is fine and well, but I
have for one have never
wanted to know this.
What _is_ important is when the fix lands in an official (weekly)
release. Users frequently ask this [1] but it is awkward to find the
answer. The changelog [2] should
say, if the committer remembered to update the changelog, and you know to
click the “Upcoming changes” link.
If you have a source checkout you can use
---%--- ~/.gitconfig
[alias]
which = describe --contains
---%---
to get a clue where a change appeared, though only after the release tag
is made. And even for those who have the source checkout, this is an
annoying context switch when
you are reviewing historical issues.
Much nicer would be if some bot would add a simple comment to JIRA after
the release is published:
This fix is in Jenkins 1.502.
and link to the changelog. This would be clearly visible in the issue
history, and send notifications to watchers. Anyone capable of making that
happen?
[1] https://issues.jenkins-ci.org/**browse/JENKINS-15156?**
focusedCommentId=173823page=**com.atlassian.jira.plugin.**
system.issuetabpanels:comment-**tabpanel#comment-173823https://issues.jenkins-ci.org/browse/JENKINS-15156?focusedCommentId=173823page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-173823
[2] http://jenkins-ci.org/**changelog http://jenkins-ci.org/changelog
--
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an
email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Which build has that fix?
I've pulled together some code that does roughly what I think Jesse is looking for by: 1. Listening on #jenkins-commits channel on IRC 2. Watching for a message with 'prepare release' in it (the standard Maven release string), pulling the version number and commit ID from that 3. Call the GitHub API to list all tags from the affected repository to try and find the tag name prior to the current version number (e.g. try and see if jenkins-1.500 is a tag if jenkins-1.501 is listed in the current commit message). Flag an issue if the previous tag can't be found (i.e. it was created with a different naming style) 4. Call the GitHub API to compare the previous tag with the commit ID from step 2 (same as using 'git log tag1...tag2') 5. Parse the commit messages for 'FIXED JENKINS-n+' (fixed issue) or 'JENKINS-n+' (changed issue) to build a list of commit messages per issue 6. Call the Jira API to add comments to the affected issues (this step hasn't been properly tested as I don't want to comment on the live defects) Whilst doing this, it got me thinking: Jira supports a 'fixed in' field for each issue, which we don't currently set since we don't maintain a list of Jenkins release numbers in Jira (I think this is just because it's historically required too much manual effort). However, Jira allows managing of version details through the REST API, so it would be possible for my IRC Bot to create the version number in Jira as it sees the release commit note and then set the correct release per issue. This also then also allows users to set the 'affects versions' field, meaning it would be easy to view which issues are still relevant at any point in time. Does anyone have any thoughts on this being investigated further? As #jenkins-commits also shows messages for plugin commits, my code should also work against releases of plugins, although it would be easy enough to stop it doing that if there was wide-spread objection to such an action. This does introduce some complexity with version numbers (inconsistent naming conventions, skipped releases, major vs minor increments etc) which I still need to work round, but these could also theoretically impact Jenkins core if we're not consistent about our release naming convention. I'm happy to put my code into GitHub at some point, although the following items currently block that: 1. I'm using a snaphost version of Kohsuke's Java Github API where I've added support for the 'compare' and 'refs' interfaces. I'll create a pull request for these today but I'm relying on Kohsuke accepting them before my code could be used properly. 2. My code currently uses my personal details for connecting to Jira which would cause comments to appear under my ID. I'd like to get a generic user account created (like I assume the SCM Issues bot has) and an OAUTH token provided for the bot to use. Does anyone have any comments on this (especially Kohsuke since you know more about how all the infrastructure interacts just now)? Thanks, Michael -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Which build has that fix?
We have some bot which comments in JIRA when a commit relating to an issue appears in the trunk continuous build. This is fine and well, but I have for one have never wanted to know this. What _is_ important is when the fix lands in an official (weekly) release. Users frequently ask this [1] but it is awkward to find the answer. The changelog [2] should say, if the committer remembered to update the changelog, and you know to click the “Upcoming changes” link. If you have a source checkout you can use ---%--- ~/.gitconfig [alias] which = describe --contains ---%--- to get a clue where a change appeared, though only after the release tag is made. And even for those who have the source checkout, this is an annoying context switch when you are reviewing historical issues. Much nicer would be if some bot would add a simple comment to JIRA after the release is published: This fix is in Jenkins 1.502. and link to the changelog. This would be clearly visible in the issue history, and send notifications to watchers. Anyone capable of making that happen? [1] https://issues.jenkins-ci.org/browse/JENKINS-15156?focusedCommentId=173823page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-173823 [2] http://jenkins-ci.org/changelog -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
