Bugzilla – Full Text Bug Listing
| Summary: | Build notes location should be centralized | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Kim Moir <kim.moir> |
| Component: | Releng | Assignee: | Platform-Releng-Inbox <platform-releng-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | akurtakov, daniel_megert, dj.houghton, john.arthorne, loskutov, nboldt, nick.entin, pwebster, tjwatson |
| Version: | 3.3 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Kim Moir
This line should have read -Some teams store the build notes in multiple plugins. The releng tool doesn't currently update multiple build notes at once. See bug 158525 I like the idea of moving the buildnotes to the releng plugin. Platform UI has a plugin that updates its version a lot without any changes other than the build notes. In conjunction with bug 158525 do we need to consider a mapping file in the common folder? I've added some more thoughts to bug 158525 if we want to have the discussion there. PW <$0.02> Why not centralize by generating your build notes from a database containing CVS commits and Bugzilla data? Eg., http://www.eclipse.org/modeling/emf/news/relnotes.php?project=emf&version=HEAD http://www.eclipse.org/modeling/emf/searchcvs.php?q=project%3A+org.eclipse.emf+days%3A+7 There's a little set up required (of course) but once you've got the database in place and you're running crons to update it from the latest batches of CVS commit data (that is, from `cvs log`), you'll get release notes / build notes, and a searchable database for commits/authors/dates/branches/comments/bug#s. We even went one step further to create "build news" which is just a sideitem box on our website listing recent builds: http://www.eclipse.org/modeling/emf/?project=emf Setting up the Search CVS database can be done via instructions here: http://wiki.eclipse.org/index.php/Search_CVS#Setup </$0.02> +1 to do centralize this. However, the build notes entries should be grouped (e.g. by map file or project) otherwise it will be hard e.g. for someone only interested in SWT or Text changes. I still don't like the current format of the generate notes because it has "incorrect" entries, e.g. from last Platform UI build notes: <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=169843">Bug 169843</a>. Leak Tests failing in N20070106-0010 (NEW)<br> If we generalize this we should also improve the format a little bit, e.g. either don't list bugs that aren't marked fixed or have different sections (FIXED, IN PROGRESS, etc.) instead of just appending it in brackets. In addition it would be good if each project had a readme.txt or buildnotes.txt with a link to where its build notes can be found. regarding comment #3 Nick, if I recall correctly you generate map files for every build from the branch that the build is being run from. We take a different approach and developers are responsible for updating the versions of their projects in the releng project that they intend to include in the integration build. I don't know if your tools take this scenario into account. In any case, I would like to keep things simple and having developers update their own build notes seems when they make their build submissions seems like the approach that will be the least time consuming. Having more up to date build notes is great but I don't have time to set up all the infrastructure to search cvs commits in a database given the many outstanding releng bugs we have to fix. (In reply to comment #5) > Nick, if I recall correctly you generate map files for every build from the > branch that the build is being run from. Yes, currently, but we're changing that approach so that developers can maintain their own versions, as the platform (and other teams) do. Starting with MDT builds, we'll be doing builds with the option of a) static mapfile, or b) generated mapfile. That said, mapfile isn't the issue here, it's cvs commits w/ "[xxxxx]" where xxxx is a bugzilla number, and bugz themselves. If you have these, you can use our tools (and the code's in basebuilder already!) I fully understand the 'no time for more todos', however. ;-) John's summary from the arch call http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg07662.html *** Bug 34839 has been marked as a duplicate of this bug. *** *** Bug 142909 has been marked as a duplicate of this bug. *** builtnotes are not used for years. |