On 1/4/19 7:12 AM, Penney, Don wrote:
From a patching perspective, which is why TIS_PATCH_VER was introduced originally, it can be reset to 0 when the source package is upversioned. But I see Scott's point from his review comment about indicating a revision from source, and Chris's below.
Setting it to 1 to show modification from original source seems reasonable to me. Given that it will get incremented and veer from the patch count, I don't see a lot of benefit to needing to count the patches to determine an initial version. But if we're going that route, I'd vote for b - count the number of patch files total.
I am not sure I agree with any of this, first off, just the fact that we have an SRPM and the TIS_PACTH_VER indicates that it's been patched, I really don't see the value in having the patch count indicated as a "Version" item. It makes more sense to start from 0 (option a) and that way we can track each subsequent change to that package with an increment. This issue did not come up at all in past updates, I am not sure why it's becoming an issue now. See below for additional comments
-----Original Message----- From: Friesen, Chris Sent: Friday, January 04, 2019 9:46 AM To: An, Ran1; Lin, Shuicheng; Penney, Don; Saul Wold; Little, Scott; Church, Robert; Bailey, Henry Albert (Al) Cc: starlingx-discuss@lists.starlingx.io; Chen, Haochuan Z Subject: Re: [Starlingx-discuss]discuss about initial value of TIS_PATCH_VER when upgrade packages
When we customize an upstream package for the first time, TIS_PATCH_VER gets set to 1, then generally gets incremented on each subsequent change. Thus, prior to package upgrade TIS_PATCH_VER reflects the number of changes that were made to the upstream package. This can be used to tell at a glance how customized a given package is.
When upgrading, it's possible that some customizations are no longer applicable, while others are. Thus, I think options "a" and "e" don't make sense as they remove the "how customized is this package" meaning.
As mentioned above, just having that additional tis.<TIS_PATCH_VER> in the file name indicates that it's been modified.
Of the options below, I think option "c" is probably the best since for an upgrade we might create a single meta-patch to add all the source patches.
And what happens when a modification is needed to the Specfile or patch with out increasing the actual number of patches, now the value of TIS_PATCH_VER increments and no longer matches the patch count. Therefore, a version should be incremental from 0. Sau!
I think the most accurate value would probably be "number of source patches" plus "number of meta patches that don't add/remove source patches". But we probably don't really need that level of accuracy.
Chris
On 1/4/2019 2:28 AM, An, Ran1 wrote:
Hi all I'm sending this to discuss about the rule of initial value of TIS_PATCH_VER when srpm package is upgraded. "TIS_PATCH_VER" is a counter to indicate change within a major version of the package, on which we put patches.
When I upgraded srpms(related to CentOS) from CentOS 7.5 to 7.6, there are different voices about the initial value of TIS_PATCH_VER(comments on [1][2][3][4]): a). reset it to 0 b). reset to the number of STX patches remaining (source patches and meta_patches together) c). reset to the number of STX patches remaining (source patches only) d). reset to the number of STX patches remaining (meta patches only) e). case by case, better do not reset.
It is not a technical issue, but we will face it each time we upgrade packages, so which would you like to choose?
[1] https://review.openstack.org/#/c/627760/ [2] https://review.openstack.org/#/c/627750/ [3] https://review.openstack.org/#/c/627156/ [4] https://review.openstack.org/#/c/627770/
Thanks Ran