As many of you have no-doubt noticed, I've been using bugs to track
releases for some time. I've been creating bugs for Kepler projects
as IP Logs are submitted. I've added a few Bugzilla queries to the
Kepler wiki page [1] that you can use to see if I've heard from you.
Note that I have not been explicitly capturing whether or not a
projects has submitted an IP Log (only if it has been approved by
the IP team). But if you have a record in the master list, then it's
a pretty good bet that I think you have.
Let me know if there are any discrepancies.
Wayne
[1]
http://wiki.eclipse.org/Kepler
On 05/29/2013 12:58 PM, Wayne Beaton
wrote:
Greetings folks.
Most projects have submitted their Kepler IP Logs for review. If
you have submitted your IP Log, please accept my thanks. But keep
reading, there's some good stuff below.
The deadline to submit IP Logs for Kepler was last Friday.
If you have not yet submitted your IP log, you are late. Being
late has a downstream effect that and adds stress to the process.
If you have not already done so, please make it happen ASAP.
The deadline to submit your PMC-approved review materials to
EMO is June 5/2013. Earlier is fine (better, even). Send me
the document, or a link to the document along with a link to the
public approval discussion with your PMC. Please do not be late.
Let me know if you require assistance.
Please take a minute to use the Download Review tool (e.g. [1]) to
review your project downloads before submitting your IP Log. Note
that I've added a handy "Review Downloads" link on project pages
in the PMI (you need to be logged in as a project committer). I
use this tool as part of the review that I do before handing the
log off to the IP team to complete the review.
This page displays the result of scanning your project's download
directory for JAR files. It scans the file structure itself as
well as the contents of any ZIP, JAR, and WAR files it finds (I
only just added support for nested JARs in JAR files). The scan
runs weekly on Friday afternoon. Contact me directly via email if
you want me to manually invoke the scan.
The tool is not perfect, but it is generally useful for most
projects (it fails miserably on the Eclipse project due--I
believe--to the shear size of its download directory). It does
sometimes report reasonable files as potential problems (this
deficiency is noted on the page itself).
To function, the tool depends on a mapping from CQ to bundle file
name pattern that I maintain. I update the mapping whenever I
discover a bundle pattern that's not covered. The tool currently
only considers the absolute file name, so it incorrectly
identifies JARs that do not have version information in their name
as potential issues (many 'ant' files for example). A future
version--that considers the full file path--will reduce the number
of false hits.
It also attempts to identify the inclusion of bundles from other
Eclipse projects (and their corresponding third-party libraries)
based on file paths. Some reports do include 'org.eclipse.*' hits
in cases that the project is difficult to determine from the
bundle name (the generally happens when a project does not follow
the convention of using their project short name as the third
segment in bundles). I have another mapping for exceptions that I
update periodically. I'm considering adding an entry in the
project metadata to allow projects to explicitly specify bundle
patterns that belong them.
Please take a few minutes to review the project downloads
every-once-in-a-while. There should almost never be a
legitimate missing CQ warning in the report. The only case
in which this should happen is if the project has been given
parallel IP check in permission for a library in advance of full
approval of the CQ.
HTH,
Wayne
[1]
http://www.eclipse.org/projects/tools/downloads.php?id=technology.dltk
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|