Community
Participate
Working Groups
It appears only JDT core still provides build notes that are regularly updated and available on the download page. See e.g., http://download.eclipse.org/eclipse/downloads/drops/I20111115-0800/buildNotes.php With tagging happening in the build, we need to decide what to do with build notes. The build tagging script produces a single report file with a list of all projects modified, and all bug reports referenced by commits. The simplest solution is to just link this file to the build page and call it done. Another option is a single file that we keep appending notes to for each build for the duration of the release cycle. For new features, new API, etc, I think the best venue to advertise those is the New & Noteworthy document rather than build notes.
See also bug 341618. For Juno JDT UI planned to add fixed build notes with some predefined bugzilla queries.
We still want to keep the build notes though we will remove references to the tags if they cannot be updated.
(In reply to comment #2) > We still want to keep the build notes though we will remove references to the > tags if they cannot be updated. Jay, please figure out the interim course of action that makes sense until we have a resolution one way or other on this.
(In reply to comment #3) > Jay, please figure out the interim course of action that makes sense until > we have a resolution one way or other on this. For the last I build, I have removed the tag reference from the build notes. The build notes also need to be updated with the correct repository links.
Some projects used to send the list of bugs to their project mailing lists. Could we just include this in the mail from the build process that lists changed projects? That way, the list is also available in case the build fails (or if replication to eclipse.org takes a long time). Best would be a list of bugs sorted by projects (or by map files or by repository).
(In reply to comment #5) > Some projects used to send the list of bugs to their project mailing lists. > Could we just include this in the mail from the build process that lists > changed projects? That way, the list is also available in case the build fails > (or if replication to eclipse.org takes a long time). The current state is that the tagging script produces a single "report.txt" file that lists all changed projects, and all bugs related to commits going into that build. I think the first step is just getting the contents of that report into an email at the start of the build process. We could then work on the tagging scripts to improve the format of that report if we want.
*** Bug 376808 has been marked as a duplicate of this bug. ***
For JDT/Core the build notes contain two kinds of information: - resolved bugs - added / changed API Any automation relating to querying bugzilla etc seem to cover only the first aspect. So what will be the future intended way of capturing API additions?
(In reply to comment #8) > For JDT/Core the build notes contain two kinds of information: > - resolved bugs > - added / changed API > > Any automation relating to querying bugzilla etc seem to cover only the first > aspect. So what will be the future intended way of capturing API additions? The New & Noteworthy document that comes out with each milestone? That's the only way other components document new API, AFAIK.
(In reply to comment #9) > (In reply to comment #8) > > For JDT/Core the build notes contain two kinds of information: > > - resolved bugs > > - added / changed API > > > > Any automation relating to querying bugzilla etc seem to cover only the first > > aspect. So what will be the future intended way of capturing API additions? > > The New & Noteworthy document that comes out with each milestone? That's the > only way other components document new API, AFAIK. Isn't that mixing content for different target audiences (end users vs. plug-in developers)?
(In reply to comment #10) > Isn't that mixing content for different target audiences (end users vs. plug-in > developers)? Yes.
I think one small step we could take for Juno is capture the report.txt that is sent in the email when the build starts. This includes all bundles changed and a list of referenced bug reports. If that file was linked from the build notes page (as something like "build input report") it would be a useful reference to put on the build notes page. That's at least as useful as a canned bugzilla query that might not reflect exactly what went into the build. The other nice thing about this report is that all the changes are in one place, which is much nicer than the old notes system where user had to click on 20 components to see what had changed.
I think it's a good time to ask ourselves whether there is *anyone* out there who would actually read this. If not, we could just dump it.
I could be convinced either way, both, neither, just "changed since last build" note. I will say, though, I think the "changed since last build" information is a little specialized, more for committers, or those who follow _real_ closely. By the time we get to a final milestone or RC build there won't be much in it (since little would have changed from last build) and I think the community at large is looking more for "what's been fixed since last milestone" or similar. Git reports probably could be created "from one milestone to the next", but .... that'd be a new piece of work. In the mean time, I'll look to put a link on the buildnotes page itself to "what's changed since previous build" and you (and others) can see what you think. It is actually "already there", just not linked anywhere: http://download.eclipse.org/eclipse/downloads/drops4/I20120510-1900/report.txt
Ah, just looking at it now, I see it just says The following projects have changed: It doesn't say what the reference it, I add that in the email text, then append the report. It'd be more useful (clearer) having the reference.
(In reply to comment #14) > Git reports probably could be created "from one milestone to the next", but > .... that'd be a new piece of work. > While I'm not in a rush to create new work, you would probably be able to generate a milestone report if you took the gitCache for a given build, used the same commandline that the build did, but specified the last milestone build tag instead of the last build tag. PW
(In reply to comment #16) > (In reply to comment #14) > .. if you took the gitCache for a given build ... You mean generically, anyone could :)
Let's not worry about creating anything new for Juno. I was just thinking if we are already generating a report that is useful enough to put in an email, and it is sitting around in the build directory, we might as well link it on the build download page so people can see it. I think there is nobody out there who still reads our build notes, based on the fact that apart from JDT core and SWT they have not been updated in at least four years.
So ... what do you think of the "new" page: http://download.eclipse.org/eclipse/downloads/drops4/I20120514-1900/buildNotes.php I "programmed" the PHP so if there are build notes there, it will show (link) them, if not, it won't. So, in theory, "we" could leave it up to each team/component to decide ... or, they might have some for a few builds/milestones to describe something "special" that had to be done, and then remove them later ... Or ... "you" could make an executive decision to remove them all? If we remove them all, then probably the single "changes since last build" link should be on the same page/section as other "build logs" since its fairly technical in nature, of interest to committers and releng, not so much adopters.
At status meeting today, it was decided to leave logic in place, in case there are times when someone needs a "temporary build note", say, to explain "don't install x with y for M4" or similar, but we'll a reminder and explanation on the build notes page itself of "what they are" are "how committers can add one". And, current components that have old/unused ones will need to remove theirs or rename them to something like "HOLD_buildnotes" ... will need to check exact pattern that's searched for to know for sure what "hold pattern" to use.
Created attachment 215815 [details] Proposed fix David can you please sanity check this.
Created attachment 215820 [details] counter proposal I think the horizontal rule is too much. (You don't those in Orion, do you? :) And, I'd tweak the wording a bit. What do you think of this version?
After "seeing live" decided on the final form/format ... I updated the build by hand at http://download.eclipse.org/eclipse/downloads/drops4/I20120517-1915/buildNotes.php to include these mods, feel free to edit in any way you see fit. echo "<p>Build notes (if any) are used to notify the community of notable, but temporary, issues or changes in a particular build.</p>"; echo "<p>Committers, to include build notes for your component, add a file with the pattern buildnotes_<component-name>.html to the root of one of your bundle's source tree.</p>"; I guess the last step is to remind committers to remove their current build notes, for RC2. I'll assume you'll do that, unless you say otherwise.
Looks good.
Created attachment 215863 [details] Updated patch with David's words
No sense rushing this into RC1.. I'll release when RC1 is done. David can you set the review flag to '+'.
I _might_ have already released it. I "accidentally" released one version, while rushing to investigate bug 379501, that's when I noted the brackets ('<' and '>') had to be escaped. But, feel free to double check.
Yep, David already released for RC1: http://git.eclipse.org/c/platform/eclipse.platform.releng.eclipsebuilder.git/commit/?id=4b58135f0ad340ba2c9c3278c1c57ba5af88f238 Closing.
Is there an action item for the JDT/Core team? We have some changes to release for RC2 and will be updating the build notes per our current process. Is that alright? Or if we are going to be removing the build notes anyway, is is even necessary?
(In reply to comment #29) > Is there an action item for the JDT/Core team? We have some changes to release > for RC2 and will be updating the build notes per our current process. Is that > alright? Or if we are going to be removing the build notes anyway, is is even > necessary? The other components have build notes that haven't been updated in years. I believe all of those should be removed. In the case of JDT/Core, your build notes are up to date. If you think such notes are still valuable to your consumers you are welcome to continue maintaining them. If you leave the build notes in your plugin, they will continue to appear in the build with no further action needed from you.
