Over the past couple of months, I’ve worked on some tools that I’ve found helpful for project administration.
First up is a listing of proposals and reviews. Now, we actually already do have some of this information available in other places, but the new pages provide dates (when was the project first proposed, when was it updated, when was it created, that sort of thing) and helpful links to the documentation and (where appropriate) IP logs, and such. To be honest with you, my main motivation for creating this one is the listing on the right side of the page that shows the number of proposals/reviews that occur in any given month. But now that I have it, I find myself using it fairly regularly just to have the list of proposal and review events all in one place.
I’m thinking that some summary of the information for a specific project might be a nice addition to the project summary pages.
Next up is the CQ Overview. This page shows the relationship between CQs. For each CQ it shows all the piggyback CQs (if any) and–in the cases that we have this information–the bundles that are associated with the CQ. The bundle information is something that I’ve been assembling over the past couple of years. Whenever a project submits an IP Log as part of the review process, I compare the third-party libraries section to the downloads provided by that project to make sure that they match; as I was doing the comparison, I captured the mapping. Frankly, many of the mappings are not obvious, so it’s a lot work. Capturing the mappings made reviewing subsequent IP Logs a lot easier.
The first real tool is a natural extension of that previous work. The Bundle Scanner, given a dump of either a plugin directory listing, or the contents of a ZIP file, will (when possible) match each of the third-party bundles to a corresponding CQ using the same bundle map. Those bundles for which a mapping to a CQ cannot be determined are indicated at the bottom of the page. I have some thoughts about extending it to handle org.eclipse bundles that start with something other than “org.eclipse”, but for now you’ll just have to parse those out with your mind. I intend to extend this to just automatically scan the downloads directory for a project based on settings provided in the portal.
Matching is done strictly by file name using patterns that match the first three digits in the version name, but ignore the qualifier. There is some discussion on Bug 326383 about using some sort of digital fingerprint to match bundle JARs as name matching is pretty error prone. I’ve presented the issue of how to generate the fingerprint (so that two bundles generated from the same source code have the same fingerprint) to a graduate class at the local university; hopefully they’ll come up with something.
The final tool is the Contribution Review. For a selected project, this tool scans the Bugzilla database for bugs that may potentially contain patches that may have been committed into the project’s VCS. You can use this tool to identify those patches that should be marked as iplog+ and be added to your project’s IP Log. This tool has been used successfully several dozen times now to identify and mark contributions. It is pretty comprehensive: it’ll find bugs with attachments that were contributed by committers before they became committers (these need to be included in your IP Log. Really.)
Unfortunately, Eclipse Platform Project, there is no soup for you! I need to see if I can reduce the memory requirements to a point where you can run this tool without blowing up.
Note that not all projects are using the automated IP Log, so using this tool to check up on other projects may not yield the results you’re looking for.
All of these new tools are available through the Project Tools landing page. Their use is restricted to committers: use your Bugzilla credentials to login. I hope you find them useful. If you see some way that they can be improved, open a bug.
