only the GA version and the subsequent updates of HTS can be used for certification. But some vendors did use testing version of HTS and uploaded the results. We should not let that happen again.
The catalog can/should figure out the hts version from the results (depending this may require a change in hts) however ideally we don't want to add an entered by hand maintenance burden, this should be automated using a similar mechanism as the valid RHEL version check, eg. calls into the RH systems which know the answers. The life cycle is already in the policy and unless we want to have spin the policy guide every time we spin hts we should not put version numbers in the policy guide, that said there is value in providing the current version numbers that are accepted and when they will expire within the catalog, I would suggest we could add a logged in header which provides "Current hts: {version} Previous hts: (accecpted until {date}".
Created attachment 315671 [details] Patch Improve:
Created attachment 315672 [details] New template to display the valid hts version and provide the hts_nvr_override option.
Created attachment 315825 [details] Patch Improve:
Created attachment 315833 [details] The sanitycheck_hts_version.pl
Created attachment 315834 [details] sanitycheck_hts_version.cron
[ attachment.cgi ] check. [ defparams.pl && data/params (?)] + desc => 'Send mail to notify a specific hts version has expired after hts version sanitycheck', +Subject: NOTICE: HTS version %expiredhtsnvr% has been deprecated. + +[This e-mail has been automatically generated.] + +HTS version %expiredhtsnvr% has expired starting today. Test result packages which were generated using this version of HTS are no longer accepted and will be rejected by the Hardware Catalog. [ upload_packages.html.tmpl ] <em>Enter the path to the results package or spec file on your computer.</em><p/> <-- instead of <br/> [ create.html.tmpl ] ...We should make this mimic the upload_packages page, "File" instead of "Certification Package File" and the <br/> and dropping the " This file can be found ..." [ sanitycheck_hts_version.pl ] What's the purpose of this conditional? It should work without it from my read? if ($next_release_date) { ... } $next_release_date = $release_date; ...the while loop should pickup on there not being another entry, which means it's only when an NVR fails to have a release date specified which we can avoid by simply defining the release_date as not null during table creation?
Created attachment 316167 [details] Patch Improve:
Created attachment 316168 [details] Improve: sanitycheck_hts_version.pl
*** Bug 456053 has been marked as a duplicate of this bug. ***
defparams.pl +HTS version %expiringhtsnvr% will expire at %expiredate%. Test result packages which were generated using this version of HTS are no longer accepted and will +be rejected by the Hardware Catalog after %expiredate%. should be Starting on %expiredate%, test result package generated using %expiringhtsnvr% will no longer be accepted and will be rejected by the Hardware Catalog. Test result packages generated using this version of HTS will need to be submitted before this date. data/params These changes will get overwritten by cfengine on the live server, as well IIRC this is generated by defparams.pl(?) so we don't need them in the patchset? upload_packages.html.tmpl @@ -66,10 +78,12 @@ Any reason for the hwcert-edit value to be true for nvr override? template/en/default/bug/create/create.html.tmpl @@ -179,7 +190,16 @@ Any reason for the hwcert-edit value to be true for nvr override?
checked into cvs, applied the above, changed the default to false.