Having a up-to-date (and correct) IP Log is important for projects and we’re trying to provide as much help as we can to make sure that they’re in order.
I’ve been working with a couple of projects to help them get their IP Logs in order. In the process, I’ve managed to generalize a “review” script that run queries against the Eclipse Bugzilla instance to help identify bugs and attachments that should potentially be referenced as contributions in a project’s IP Log. I’ve already used this script to identify a couple of contributions that I neglected to record for the Examples and Eclipse IDE for Education (ide4edu) projects.
The script is currently pretty rough. I haven’t made any linkage to it from any other eclipse.org page, so you have to manually modify the URL to make it work for your project. It could probably also stand to have a little more prose added to better describe what it provides. You can see the results of running the script for Mylyn, and Examples. To try other projects, change the id parameter value to the id of the project (e.g. tools.mylyn, or technology.examples). FWIW, it doesn’t work on eclipse.platform as it requires too much server memory and it bails out. Close to a decade’s worth of bug reports will do that for you.
Using this script to poke around a bit, I’ve noticed a few projects that still don’t quite get the iplog+ thing. Clearly, I need to do a better job of working with projects to get this right.
The main benefit of using the Bugzilla iplog flag is that we can use this information to automatically generate an IP Log for the project. However, the generation process is only as good as the data it’s provided with. Here are a few pointers:
- Only actual code contributions need to be included in the IP Log.
- Only contributions from non-committers need to be included in the IP Log
- Contributions that come from a developer before they become a committer do need to be included in the IP Log; the tools are smart enough to handle this time-sensitivity (so committer-provided contributions erroneously flagged as iplog+ are ignored).
- Ideally, attachments should be flagged as iplog+ rather than bugs (if an attachment is flagged, the bug itself almost certainly should not be).
- A bug might be flagged as iplog+ if the summary or one of the comments contains code that’s been rolled into the project’s source code repository.
- Marking the bug iplog+ means that the summary and every comment are potential contributions that will need to be manually filtered when the IP Log is generated.
The page that results from the “review” script is read-only. You can’t actually change the iplog flag’s value from the page. But there are handy links that take you right to where you need to be if you decide that you do need to flag something. Hopefully this makes it easier.
As always, I invite your feedback. If this page turns out to be useful, I’ll sort out how to better incorporate it into eclipse.org.
