[Starlingx-discuss] discuss about initial value of TIS_PATCH_VER when upgrade packages

[Penney, Don]

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.

-----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 at 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.

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.

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