View Issue Details

IDProjectCategoryView StatusLast Update
0001617SUMoRefactoringpublic2019-06-02 21:07
Reporterpoutnikg Assigned ToKyle_Katarn  
PrioritynormalSeverityminorReproducibilityN/A
Status acknowledgedResolutionopen 
PlatformNotebook Lenovo T400OSWindows XPOS VersionProfesional SP3
Product Version3.2 
Target VersionLong term 
Summary0001617: OS version dependency of latest version
DescriptionMultiple software has OS version dependent latest version number.
Usually if support of older OS is dropped and latest becomes last.
Or, sometimes 2 paralled version lines are maintained.

Maximalistic variant:
Clients would UL/DL also OS version and comparison would be done
together with OS dependency.

Smaller variant:
Clients would UL only OS version to server.
"Get update" SUMO feature would have marked versions by OS if applies.

Minimalistic variant:
OS info would be able to be trigger by web action
or through forum like stable/beta thread.
Info would have just web informational status, out of SUMO functionality.
TagsNo tags attached.

Relationships

related to 0004826 acknowledgedKyle_Katarn Report updates only for present OS 

Activities

poutnikg

2012-06-27 10:24

reporter   ~0000908

E.g. Access Connections for Lenovo ThinkPads has latest version
5.85.0.0 for XP and Vista
http://support.lenovo.com/en_US/downloads/detail.page?LegacyDocID=MIGR-4ZLNJB
http://support.lenovo.com/en_US/downloads/detail.page?&LegacyDocID=MIGR-67283
5.93.0.0 for W7
http://support.lenovo.com/en_US/downloads/detail.page?&LegacyDocID=MIGR-73682

poutnikg

2012-08-16 11:53

reporter   ~0001118

If SUMO would communicate the OS version with the server,
it could be able determine the proper latest version for give OS.

For still alive W XP the latest version is very often different
to the one for W7.

bytehead

2012-08-16 22:29

reporter   ~0001119

I'm all for the first (maximalistic) approach, which means that current data model should be expanded.

Kyle_Katarn

2012-08-17 01:12

administrator   ~0001120

Sure but for a given users count in the overall database, it would drastically reduce number of users for given {product ; OS}

Would a case by case (by appending OS, like we currently append 64-bitness) be a reasonnable compromise ?

poutnikg

2012-08-17 10:45

reporter   ~0001124

Last edited: 2012-08-17 11:32

View 2 revisions

Well, sometimes drastically reduced number of users is advantage, if the others are not relevant to me.

But I agree it could be better case by case,
e.g. by context menu in sense
"I do insist this is last stable for my OS in spite of existance newer stable".

bytehead

2012-08-17 19:53

reporter   ~0001129

Last edited: 2012-08-17 20:02

View 4 revisions

I agree with poutnikg: OS relevance is more significant for our goals than common prevalence.

Regarding the case-by-case resolution, for me it's seems in line with proposed automatic processing of community beta reports, which would require significant changes in both the communication protocol and server-side code (besides, effective anti-abuse measures should be well thought out and discussed before implementation). And I hope this will be realized eventually.

For the time being, I dislike the current manual exception handling for betas (via mail/forum) and implementing this new feature the same way wouldn't do any good. So, until SUMo back-end is ready for fully automatic community-based training, we should better rely on implicit information obtained by general scanning for platform relevance.

What we need to attain though is the least common denominator in terms of platform major compatibility levels. Which means we can map product versions to relevant platform groups, not to the specific Windows revisions and their Service Packs, e.g.:

1a) [W4.x] for Win 95/95_OSR2/98/98SE/Millenium (is this supported by SUMo at all?);
1b) [NT4.x] for NT4 Workstation/Server (same question here);
2) [NT5.x] for Win 2000/XP, Server 2003;
3) [NT6.x] for Win Vista/7, Server 2008/2008R2, Home Server 2007/2011;
4) [NT7.x]??? for Win 8/Server 2012;

This way, I guess there will be enough users in every {Product[+bitness]; OS_Platform} group for our goals.

Kyle_Katarn

2012-08-18 01:02

administrator   ~0001133

OK, to be investigated further on my side for feasibility

poutnikg

2012-08-18 12:58

reporter   ~0001139

I dislike email/forum exceptiom handling too,
it is all sides resource demanding and its scalability is very poor.

I do not expect much improvement in exception management,
until some good server client protocol is implemented,
addressing also mentioned abusive issues.

Kyle_Katarn

2012-08-18 16:31

administrator   ~0001144

This is a good idea, especially if we want to extend scope of SUMo (or side product) to drivers (which are OS depend by definition), but my fear is that it makes server maintenance a real burden (beta tagging to be done 4 times instead of one).

Or it will require significant "tooling upgrade" for administrator. I take to action to find out a decent solution.

wolf

2019-06-02 19:01

reporter   ~0003430

Can somebody explain the meaning of the abbreviations "UL" and "DL" used in the description?

Is my impression correct that there is some misunderstanding considering TWO different things as synonyms although being different?

With the two distinct things I mean signature and record. A record may contain as many attributes as conveniant as long as not violating normalisation constraints. A signature refers to identification, independant of attributes irrelevant for identification. For the purpose of SUMo reliability, it seems to me most approriate that signature would become a computed hash. The factors included have to depend on some bit vector. Currently I see four bits of use for such a bit vector which are: relevance of edition, relevance of OS group, relevance of hardware, test version. With relevance of bit-edition I mean if product updates and releases are depending on product edition or independant. Product edition may not only distinguished by 32 or 64 bit edition but also by basic and various professional editions. With relevance of OS group I mean if product updates and releases are depending on OS groups as defined by Microsoft [similar to note https://www.kcsoftwares.com/bugs/view.php?id=1617#c1129 above]. OS groups probably have to take into account system requirements of the editions of the OS group. Editions are distinguished not only by 32-bit or 64-bit edition of OS but something like S, Home, Professional, Enterprise, Server Essential, Server, Datacenter, Ultimate, Embedded, and the like. I.e. Microsoft decided that I'll not receive the feature update of Windows 10 1809 Home 64-bit to Windows 10 1903 Home 64-bit on my tablet as the Intel tablet processor is not supported and the flash disk space is too small. That's probably also the case for those users running Windows 10 S edition. Various Intel management software has some dependency on hardware. It happens that i.e. Intel Management Engine gets updates available one hardware familiy after the other, no longer gets updates or skips some hardware families for one particular patch but not necessarily all future patches. With test software I mean if either the software version is known of not yet being released or the SUMo client device is known to participate in alpha or beta software testing. So the SUMo product records and the SUMo protocol shall include not just a signature but also all attributes relevant like the OS and its edition, the product , its edition and its publisher, the concerned hardware (CPU, GPU, network and/or whatever seems relevant). Default should be that the bit vector is 0 meaning no dependancy of version update on product edition, OS edition nor hardware. Then product signature takes into account only product name and publisher, no edition, no OS nor HW. Product version signature then takes into account the product version in addition to the factors of product signature. If product edition turns to be relevant then the corresponding bit of bit vector has to toggle and signature determination has to change to take into account already recorded edition attributes. Accordingly with the other bit vector components. With such a design, the SUMo user count gets even larger not smaller for most products which will have this bit vector on default value as distinction between product editions has shown irrelevant for release of updates. So as this issue has been raised already years before I've even heard of SUMo, why these attributes have not yet been included into SUMo protocol and SUMo server records with one of the previous major SUMo upgrade releases.

I agree that such protocol and code change is appropriate for major SUMo version upgrades. I agree that for a few products the factors for product version signature are broad enough to have a splittered user base of those few products. The corresponding decrease in SUMo reliability for those few products may be temporary and instead turn in better reliability in the future. I want to emphasize that code changes for evaluating changed signatures may come with later SUMo version as the protocol change and code change for collection and analysis. Thus the decision when to use such a smarter decision vector may be taken on a product by product base. This means that knowledge that a particular product has such dependency may result to a decision to either take this knowledge into account as soon as possible or postponed until seeming more appropriate.

I remind that KC Softwares product page claims implementing and distinguishing between normal version updates, updates of features and updates of just security fixes. There is already one other issue on this security aspect. But as far as I know such a security flag is not yet part of the attributes recorded by SUMo server nor evaluated in contrast to SUMo feature description raising yet unmet expectations!

With such a proposed design change, I don't see that fear of effort for beta tagging as real as I assume that the changes in protocol and client side determination of test participation will allow better automation and increase reliability.

I don't know SUMo server implementation. I fear that there is not sufficient distinction between product records and product version records although a stronger distinctions seems necessary. When implementing such design changes, why not provide appropriate design changes for the other issues about user base, active devices, device-user associations and so on? It's one thing to change these features internally and another when they become visible on one or several UI. These times can then be different too. This concerns also the insufficient distinction between detection and reporting in SUMo implementation.

And I don't know enough yet of the current SUMo protocol nor if the scope of solution to issue https://www.kcsoftwares.com/bugs/view.php?id=5518 is correspondingly broader then its description, then abuse implementations may either be softened or rendered configurable on server side.

Kyle_Katarn

2019-06-02 20:33

administrator   ~0003434

I fully agree. Neither protocol not database model are designed for this (unlike DUMo).
It may come in the future, but it would break compatibility with older versions.

wolf

2019-06-02 21:01

reporter   ~0003435

It's obvious that such changes break compatibility by whatever sense. What sense do you refer to?
How do older versions of SUMo client behave if they find additional information in the protocol they don't expect?

I expect that older SUMo clients will ignore additional protocol information, not crashing nor running amok. And as long as evaluation doesn't change on server side, even the behaviour of older SUMo client shouldn't change.

When gradually enabling evaluation changes on server side after protocol and code changes, many SUMo users will have updated to newer versions with support for the new protocol elements. So it will concern only few SUMo users and even for them such change will not change results for all their detected products just a few.

Kyle_Katarn

2019-06-02 21:07

administrator   ~0003436

Good point, I need to check if I can implement it in a way that it's transparent for older versions

Issue History

Date Modified Username Field Change
2012-06-26 17:51 poutnikg New Issue
2012-06-26 22:29 Kyle_Katarn Assigned To => Kyle_Katarn
2012-06-26 22:29 Kyle_Katarn Status new => acknowledged
2012-06-27 10:24 poutnikg Note Added: 0000908
2012-08-16 11:53 poutnikg Note Added: 0001118
2012-08-16 22:29 bytehead Note Added: 0001119
2012-08-17 01:12 Kyle_Katarn Note Added: 0001120
2012-08-17 10:45 poutnikg Note Added: 0001124
2012-08-17 11:32 poutnikg Note Edited: 0001124 View Revisions
2012-08-17 19:53 bytehead Note Added: 0001129
2012-08-17 19:57 bytehead Note Edited: 0001129 View Revisions
2012-08-17 20:01 bytehead Note Edited: 0001129 View Revisions
2012-08-17 20:02 bytehead Note Edited: 0001129 View Revisions
2012-08-18 01:02 Kyle_Katarn Note Added: 0001133
2012-08-18 12:58 poutnikg Note Added: 0001139
2012-08-18 16:31 Kyle_Katarn Note Added: 0001144
2018-04-09 21:02 Kyle_Katarn Relationship added related to 0004826
2019-06-02 19:01 wolf Note Added: 0003430
2019-06-02 20:33 Kyle_Katarn Note Added: 0003434
2019-06-02 20:33 Kyle_Katarn Target Version => Long term
2019-06-02 21:01 wolf Note Added: 0003435
2019-06-02 21:07 Kyle_Katarn Note Added: 0003436