Community
Participate
Working Groups
I have created a simple tool to help WTP generate some of the Project Log information (see it here http://www.eclipse.org/org/processes/ipscanning/timquery3.php). This is probably useful enough that it needs to generalized for use by other project teams. Specifically, it needs to have an initial page that allows selection of: * Bugzilla product(s) to search * Which unix group(s) to check for committer membership * Which target milestone to consider (if any) Then you user will press "go" and the spreadsheet will be generated. In the future, some of this can be extracted from the project-info.xml file (bugzilla and unix groups at least).
I'm all for this sort of documentation-automation-generation. Let me know if I can offer any assistance in php interface construction (parameters noted above) to parameterize the output. In addition to your list of suggested params, I'd suggest UI to allow filtering by: * start/end date * bug status * target milestone Oh, and if you need a catchy acronym for it... how about egads! (Eclipse Generation of Automated Documentation System) ;-)
I have started something similar to this for GMF, with the results visible here http://www.eclipse.org/gmf/development/ipquery.php. The output is closely aligned with the stated requirements for the log, with the addition of the 'committer' field (which needs to be resolved to their ID still). There will need to be some conventions applied to patch submission and subsequent commits in order to make this work, in the absence of changes to Bugzilla itself. Our guidelines are outlined here http://www.eclipse.org/gmf/development/development_guidelines.html#Bugzilla Basically, the contributor must submit the patch (named after the plug-in/component, ending in .txt - no zips, as the file size is used to estimate contribution size. Still, for generated code contributions, all measures seem equally meaningless). The Committer must make an entry containing 'committed' in the body and mark as 'RESOLVED'. We already have close to this convention on GMF, so it really shouldn't be hard to adhere to it. There are a lot of holes here, still.
Richard, the code I've been writing looks at the contents of the attachment itself rather than just the filename - that way you don't have to use a special filename to detect a patch. Plus I can extend it to look into zip files. And I count the lines in the patch rather than look at a filesize. It's quite fast. Do these seem like reasonable choices to you?
It sounds perfectly reasonable to me, Bjorn. I don't depend on the filename to indicate a patch, only to quickly obtain the component name. The ispatch field tells me it's a patch, while a LENGTH() of the blob field gives me the size. From the example you provided, it was not obvious you went into the file. In updating our log manually, I would typically take the component name from the patch file content, so if you have code that does this and even within zips, all the better. Also from your example, it seems that you're checking that the attachment itself is posted by the committer, while this is not always the case. To me, it's not sufficient to rely only on Bugzilla, but also reconcile the CVS log. Maybe it would be helpful for you to describe the logic in your query?
Well, it's a prototype just for WTP so it does: SELECT bugs.bug_id as bug_id, bugs.bug_status as bug_status, bugs.resolution as bug_resolution, bugs.target_milestone as bug_target_milestone, attachments.filename as filename, attachments.thedata as thedata, attachments.creation_ts as timestamp, profiles.login_name as attachment_login_name FROM bugs, attachments, profiles WHERE attachments.bug_id = bugs.bug_id AND attachments.isobsolete = 0 AND (bugs.bug_status = 'RESOLVED' OR bugs.bug_status = 'CLOSED' OR bugs.bug_status = 'VERIFIED') AND bugs.resolution = 'FIXED' AND bugs.product_id = 20 // WebTools AND attachments.submitter_id = profiles.userid ORDER BY bugs.bug_id; and then I look for "patch" in the filename (column G) or "RCS file:" in the file contents (column H), count the lines in the file (column I), check whether the person who added the attachment has an eclipse.org account by looking in LDAP (column J), and if so whether that eclipse.org account belongs to the "webtools" group (column K). I mark the row as "needs inspection by a human" if (G or H) and (I > 150) and !J and !K.
Thanks Bjorn, this is helpful. Some additional comments: - According to the guidelines, the component (CVS directory) is a required element of the log. It would seem you could also get this by parsing the "RCS file:" line in the file. - When you query to see if the patch submitter is a Committer or not, does it take the date of acquiring Committer rights into account? The reason I ask is that if it's a patch that was submitted by an individual as a contributor who later became a Committer, it would give a false positive. Or, does it not matter? - We'd still need to validate that the patch was indeed committed to CVS. My approach was to look for a Committer comment that contains the word 'committed' while an alternative would be to examine the CVS log for the mention of the Bugzilla # in a comment. From this you could also get the actual Committer of the patch. Let me know if you'd like to try this on GMF (product_id = 29) as well. I'd be happy to compare the results to our manual log to help refine it further.
Created attachment 28984 [details] Simple project picker UI / querystring support to wrap around your script to allow other projects to reuse your engine Works with prod_name, prod_id, and neither (picklist): http://eclipse.org/emf/plan/ip.php?prod_name=Web+Tools http://eclipse.org/emf/plan/ip.php?prod_id=29 http://eclipse.org/emf/plan/ip.php
Two questions: 1) Does the tool work correctly when the name of the person that contributes a fix is not the submitter of the bug? For example: https://bugs.eclipse.org/bugs/show_bug.cgi?id=108470 I would assume it would work, but just checking... 2) What should be done when the submitter's name does not show up in the query: For example: https://bugs.eclipse.org/bugs/show_bug.cgi?id=109841 Is the only having the userid enough for the Project Log & IP Policy?
bug 220977 is going to supercede this bug. *** This bug has been marked as a duplicate of bug 220977 ***
