A usable Vector *release* hasn't been made since 1.0.1 in 2015-April or so. It was included through pcp 3.10.7. Now pcp 3.10.8 includes a random unreleased git snapshot of vector, like the rawhide-autogenerated builds do, but as warned in bug #1268322, there is no version information identifying it. If we do want to ship a nonreleased vector with released pcp, we should give identify a pseudo-release tag name. If we don't want to ship a nonreleased vector with released pcp, we need to go back to the 1.0.1 release, or else urge vector upstream to release pronto.
As was discussed on IRC - I didn't include a _random_ vector snapshot. I ran fedpkg newsources with the new pcp tarball (3.10.8), along with the currently committed vector and pcp-webjs tarballs (after having downloaded them with fedpkg sources). The vector and pcp-webjs tarballs included in the 3.10.8 release are thus the same versions as we'd been QA'ing during the development phase. I certainly agree we need to add version information to the vector and pcp-webjs tarballs and some API mechanism for querying this. I think Nathan discussed this with the vector team when he met with them .. Nathan?
Yep, discussed with the netflix guys - Martin has already implemented it and Lukas has updated the PCP build processes (for both pcp-webjs and vector), too.
Fixed with Lukas' change to scripts/spin-rawhide : commit b594c2d8ad37ecfc79a8a916c0832edfb89357b1 Author: Lukas Berk <lberk> Date: Wed Nov 11 14:53:47 2015 -0500 Add date/git hash to source tarball names when we spin pcp for rawhide which basically does this: + VECTOR_GIT_DESCRIBE=`git describe | rev | cut -f1 -d"g" | rev` + VECTOR=`echo vector-${TAG_DATE}git${VECTOR_GIT_DESCRIBE}.tar.gz` (and similar for pcp-webjs). When we run fedpkg newsources, we use the currently committed vector and pcp-webjs tarballs for the release. Any remaining issues with this bz Frank?
> The vector and pcp-webjs tarballs included in the 3.10.8 release are thus > the same versions as we'd been QA'ing during the development phase. OK. It would be helpful to add details of the QA'ing you (who?) had done to the qa-notes.txt file in webjs [1], so we can repeat them at the next release. [1] http://oss.sgi.com/pipermail/pcp/2015-September/008336.html
(In reply to Frank Ch. Eigler from comment #4) .. > OK. It would be helpful to add details of the QA'ing you (who?) had done to > the qa-notes.txt file in webjs [1], so we can repeat them at the next > release. > > [1] http://oss.sgi.com/pipermail/pcp/2015-September/008336.html Well, it was just "install and does-it-work-at-all" manual QA, on my behalf anyway, which is obviously the absolute minimum prior to release. Others may have done more QA than that ... we need to improve in this area for the bundled web APIs, and as you suggest, documenting any non-automated QA is a step in the right direction. Ditto for pcp containers. Regards -- Mark
> Well, it was just "install and does-it-work-at-all" manual QA, on my behalf > anyway, which is obviously the absolute minimum prior to release. The qa-notes.txt file was written & announced just as that set of guidelines for that absolute-minimum manual testing. It sounds as if even less than that was done for this particular vector snapshot. That was my concern about this switch to webapp snapshots.
This is a bit of an aside, but if qa-notes.txt is to be considered an 'absolute-minimum' for manual testing, could I ask that it be updated to include any testing that was done above and beyond qa-notes.txt, before the aforementioned switch to snapshots? It would be helpful to make those aspects more widely known to the community for future reference, avoiding information silos.
(In reply to Lukas Berk from comment #7) > [...] could I ask that it be updated to include any testing that was done > above and beyond qa-notes.txt, before the aforementioned switch to snapshots? There were no qualified upstream webapp releases -after- the qa-notes.txt file was assembled, so is already current & up-to-date.