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

[Jones, Bruce E]

Saul wrote:
> Do we need a proper Specification for the meaning of the package information, this is where we can change the tis/TIS to stx/STX!

+1!

      brucej

-----Original Message-----
From: Saul Wold [mailto:sgw at linux.intel.com] 
Sent: Monday, January 7, 2019 3:48 PM
To: Scott Little <scott.little at windriver.com>; Penney, Don <Don.Penney at windriver.com>; Friesen, Chris <Chris.Friesen at windriver.com>; An, Ran1 <ran1.an at intel.com>; Lin, Shuicheng <shuicheng.lin at intel.com>; Church, Robert <Robert.Church at windriver.com>; Bailey, Henry Albert (Al) <Al.Bailey at windriver.com>
Cc: starlingx-discuss at lists.starlingx.io; Chen, Haochuan Z <haochuan.z.chen at intel.com>
Subject: Re: [Starlingx-discuss] discuss about initial value of TIS_PATCH_VER when upgrade packages



On 1/7/19 7:28 AM, Scott Little wrote:
> I disagree.   Our experience in the past, is that putting a tis.0 on a 
> package raises questions from both customers and designers.  Why are 
> you compiling this at all if you aren't changing it?I would have 
> thought that the tis.<x> extension would be enough to
indicate this package had patches.

I also think we should really be switching to stx.0, but that's a different discussion I would guess.

> A little digging, and some wasted cycles, and the answer is.  "Oh, we 
> are changing it. we still have 3 patches against it. sorry for the 
> confusion."
> 
> Now as you point out.  We might remove a patch in a non-rebase context. 
> In this case we are compelled to increment, rather than decrement, 
> TIS_PACTH_VER.  In this case we have to live with the misleadingly 
> high number until the next rebase.  That's ok.  No one has complained 
> about that.
> 
I guess I am about the consistency of the meaning of tis.<x> when it increments, such that starting at 0 and later incrementing means change occurs vs starting at N want meaning a patch count and later incrementing and not really having a meaning any more, my OCD kind of kicks in.


> I should have been flagging this in earlier code reviews.  I wasn't.  
> My error.  Had bigger fish to fry in the early months of going open source.
> 
As I said, I had never heard this until now, I understand your busy, but we did the whole 7.5 update without hearing about.

> If the community wants to overrule, that's fine.  I'm just trying to 
> share my hard won experience as 'the rebase guy' for 4 years prior to 
> open sourcing.
> 
Do we need a proper Specification for the meaning of the package information, this is where we can change the tis/TIS to stx/STX!

Sau!

> Scott
> 
> 
> 
> On 2019-01-04 4:52 p.m., Saul Wold wrote:
>>
>> 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
> 

_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss at lists.starlingx.io
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss