There’s a fundamental problem with the Automated IP Log Tool. Now, don’t get me wrong… there’s a lot of good stuff in there. And we’re going to keep on leveragin’ that good stuff as we move forward. But there’s a fundamental problem.
For the uninitiated, the Automated IP Log Tool builds that all-important IP Log that is a crucial part of project release and move reviews (as discussed in the Eclipse Development Process). In short, the IP Log lists the committers who have been working on the project, along with outside contributions. The Automated IP Log Tool mines IPZilla—our repository of contribution questionnaires—to assemble the list of third-party software. It mines the Dash committer database in conjunction with the Foundation database to assemble the committer list. It mines Bugzilla to find additional contributors and their contributions.
The fundamental problem with the tool is that it only ever shows the current state. You can’t, for example, use the tool to show what the log should look like for some earlier release of a project. It just was never really intended to provide that sort of functionality.
The tool does allow for some customization. You can tune the automatically generated stuff by specifying exclusions. You can, for example, override the fact that the tool thinks that somebody is a committer. You can make it exclude Bugzilla records that really aren’t contributions (though it’s better to tune that sort of information within Bugzilla if you can). That’s the other problem: tuning the log is based on exclusions.
After you make all the exclusions you need to make, what happens if somebody enters something new into one of the databases we generate from? You’d have to go back into the tool and exclude that new thing.
I’ve been thinking a lot about changing the way that the Automated IP Log Tool works. I’ve created Bug 278099 to discuss this. My first thought was to change the focus around. Rather than thinking of it as a IP Log generator, instead think of it as a tool for simply capturing the IP Log. At first blush, it is simply a form-based UI that lets the user enter log information in a structured way. Whatever the user enters is captured in the database. The magic comes in in the form of buttons (or some mechanism) that can automatically populate and update parts of the form from the various data sources. Of course, we’d need some clever mechanisms for highlighting (and resolving) inconguencies between the data entered and what exists in the database.
Basically, I’m talking about making it inclusive rather than exclusive. Include the things you want. You have full control. We just help you where and when we can.
With such a mechanism allowing projects to create multiple, possibly named, logs we can easily represent multiple versions of the log. I imagine that it would be pretty easy to create a new version based on an older log. Gabe suggested that we could even have a flag on the logs that indicate they’ve passed the IP review (in this case, we’d lock them down from change). With the information explicitly captured in a database, we could easily do things like dump the logs in different formats (like XML).
On the downside, I’m still basically a web 1.0 guy and this really needs to be a web 2.0 thing. Gabe’s the man, so maybe this isn’t as big a problem as I think.
As I was driving home tonight, hashing this idea about, it occurred to me that it might be cool if the tool was actually Eclipse-based. If I model the IP Log using EMF, I get a heck of a lot of stuff for free. I can interact with the various data sources through web services… We could just represent the log in some XML file that projects can put where-ever they like (or we can push it to our database via web service). Heck, at some point we could just host this using RAP.
So, what do you think? Eclipse-based IP Log Tool, or fancy web 2.0 Ajaxy IP Log Tool?
