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

[Saul Wold]

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