Bugzilla – Full Text Bug Listing
| Summary: | Build scan limitations. | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Paul Slauenwhite <paulslau> |
| Component: | TPTP | Assignee: | Samuel Wu <samwu> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P2 | CC: | jcayne, kathy |
| Version: | unspecified | Keywords: | plan |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Paul Slauenwhite
These scans should also include all Technology Preview plug-ins. (In reply to comment #0) Also, this defect should also include the following scans: All copyright patterns Classes using non-TPTP internal packages Comparing version numbers with previous release Modules that have changed since the last tagged build The current scan for comparing version numbers with previous releases determines problematic versions based on the last full release. In the current reports, if the current version of a plugin is greater than the previous version, the current version is not reported as problematic. That is, plugins versioned in a maintenance release that GAed during the full release (e.g. parallel development) that do contained changes specific to the full release are not reported as problematic. By way of illustration, in the Test project we have several plugins (e.g. org.eclipse.hyades.test.tools.core) that were changed in both 4.2.1 and 4.3. However, their version number was updated in 4.2.1 and they do not appear as problematic in 4.3.0 since their current version number is greater than their previous version number. I think we need to track the version numbers relative to the last maintenance release rather than the last full release. Furthermore, the current scan for comparing version numbers with previous releases does not identify defect (requires third digit version updates) vs feature (requires second digit version updates) updates to plugins. Since we can find the list of fixed defects/features for a release from Bugzilla, we should be able to track which plugins/features have been updated for these defects/features. As such, we should be able to do automatic/batch updates of plugin/feature version numbers based on the results of the build report. This could be done at the end of a maintenance/full release. Two more useful features: 1) Email notification to componet/project leads when an action is required (e.g. update version/copyright) or violation is detected (e.g. internal API usage, missing copyright) to expedite the resolution. 2) Automatic copyright year updates. Since the scanning script knows when the copyright year is missing/incorrect, it can automatically fix the mistake and check the file back into CVS. Although this may encourage laziness on the part of the committer/contributor, it is much more efficient and productive (especially when one committer does a mass update). Increasing severity since these are issues that should be evaluated to streamline our release engineering processes. Is this containable in 4.4? Deferral to future with PMC approval Mass update of P1 enhancements and defects targetted to future to P2. As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. Since this defect is more than 2 years old, it may be no longer relevant. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this defect is resolved as WONTFIX. If this defect is still relevant and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open. This is still an issue but hasn't been worked on since a work around is in place. A fix will be done as part of a series of build improvements for 4.6.1. (In reply to comment #10) > This is still an issue but hasn't been worked on since a work around is in > place. A fix will be done as part of a series of build improvements for 4.6.1. Sorry, wrong bug commented on. Reopening since still relevant. As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. Since this defect is more than 2 years old, it may be no longer relevant. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this defect is resolved as WONTFIX. If this defect is still relevant and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open. Still relevant - reopened. Targeting to 4.7.0. Deferring to TPTP 4.7.1. Deferring to TPTP 4.7.2. Re-assigning to Sam. The current tools check copyright, version, module changes and internal use. The project leads and release team usually check the report prior to a release to update versions and copyrights. No plan to fix. Closing. |