The existing Automatic IP Log Tool and the new EMF-based one that I’m unveiling next week at Eclipse Summit Europe both make use of the iplog flag in Eclipse Bugzilla. After spending some quality time with the code that scours the various Eclipse Foundation databases to find contributions to a project, I’ve come to realize that many committers don’t know how exactly to use this flag. The log generation tools are only as good as the input they’re provided with, so I thought I’d spend a few minutes describing when, why, and how to use this handy flag.
You can set the iplog flag on an attachment. This is probably the most natural way to use the flag. To set this flag, open the “Details” for the attachment, set the value to “+”, and commit. That’s it. Do this for any attachment that contains something that you’ve committed into an Eclipse source code repository. This includes things like code patches, image files, XML schemas, and pretty much anything else. Only mark those attachments that actually make it into the repository; just leave any other attachments alone.
You can also set the iplog flag on an entire bug. You would do this if the bug’s summary or one of the comments contains code, or some other valuable asset that you commit into the source code repository. Unfortunately, flagging the bug indicates to the automated tools that every comment on the bug is a potential contribution (sadly, it appears that there is no way to set a flag on an individual comment). When you set the flag on the entire bug, you have to manually go through the generated log and remove any comments that shouldn’t be there. Yes, this can be painful. It’s made more painful by the fact that any new comments added to the bug after you’ve done your clean up will appear the next time the log is generated. This is particularly troublesome in the current Automatic IP Log Tool, and only slightly less so with the new one.
The bottom line is that it is always easier if your contributions come in the form of an attachment.
Only those attachments and bugs that contain contributions from developers who are not committers on the project at the time need be flagged. This is time-sensitive. If the contributor eventually does become a committer, those patches they’ve contributed while they were not a committer still need to be accounted for in the log and must therefore be flagged. The tools are smart enough to check the dates. Make sure that each committer’s Bugzilla email address matches the one in the Eclipse Foundation database, or you’ll wind up with some extra stuff in your IP Log.
