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@linux.intel.com] Sent: Monday, January 7, 2019 3:48 PM To: Scott Little <scott.little@windriver.com>; Penney, Don <Don.Penney@windriver.com>; Friesen, Chris <Chris.Friesen@windriver.com>; An, Ran1 <ran1.an@intel.com>; Lin, Shuicheng <shuicheng.lin@intel.com>; Church, Robert <Robert.Church@windriver.com>; Bailey, Henry Albert (Al) <Al.Bailey@windriver.com> Cc: starlingx-discuss@lists.starlingx.io; Chen, Haochuan Z <haochuan.z.chen@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@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss