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.

This entry was posted in Community. Bookmark the permalink.

2 Responses to +iplog

  1. Eike says:

    Hi Wayne,

    Where in the process is it written that the iplog+ flag on an entire bug means that *all* comments are subject to IP clearance? In my opinion this makes absolutely no sense. You already mentioned one technical reason: If comments could be subject to IP clearance at all then this should certainly apply to dedicated single comments. For me the main reason against this usage of the flag is that I can not query the flags of the attachments. Or can I? Not that it’s particularly convenient or free of redundancy to set the bug to iplog+ if any attachment has iplog+, but how else could I get a list of those bugs?

  2. Wayne Beaton says:

    Hi Eike. The Bugzilla interface certainly doesn’t make it easy to query the flags. However, the Automated IP Log tool does just this. If there is a different sort of query you need, let me know, and we can work something out.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s