View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001800||SUMo||New Feature||public||2012-10-22 08:33||2013-09-17 20:05|
|Platform||Desktop||OS||Windows Vista 64||OS Version||Home Premium SP2|
|Target Version||Fixed in Version|
|Summary||0001800: Optional time postponing of diplaying new versions|
|Description||In case of not displaying beta versions,|
SUMO could optionally (globally or by item bases)
postpone displaying of new version by given times, e.g. 24h.
This could provide time to be considered and marked as beta
and after 24h it would not be displayed at all.
I am not sure how would you consider this feature useful,
or easy to implement...
Could be useful for users not participating actively on SUMO version management.
|Tags||No tags attached.|
|related to||0001794||acknowledged||Kyle_Katarn||Display of beta updates on client side|
|related to||0001704||acknowledged||Kyle_Katarn||the ability to see beta for each individual program|
|related to||0001783||acknowledged||Kyle_Katarn||Management of more product lines/series updates|
|related to||0001851||acknowledged||Kyle_Katarn||Asking user for SW stable/beta status when not registered version is found|
|related to||0001669||acknowledged||Kyle_Katarn||Adressing eternal beta reports|
LOL! Poutnikg, I'm stunned now!.. Just last night I was looking once again at the BurnAware 5.3 being offered as *non-beta* update (which was in fact BETA released *two weeks ago*, check http://fileforum.betanews.com/detail/BurnAware-Free-Beta/1212419334/4) and said to myself: "Gosh, this is a never ending story... Although, while we're still trying to come up with some viable ideas about more automated/maintainable/reliable beta discovery mechanism, why not just... implement some delay before we report new versions to those who doesn't want to be bothered with betas? Hmm, not a bad idea... Worth filing it the other day, I think." And guess what I saw first when I opened Bug Tracker today?! :)
This is not the first time it happens here I must say, but such a short timing is especially amusing...
On a serious note, I think this isolation period should be customizable on the client side. I propose the following range: None [default], 1 day , 2 days, ... , 6 days, 1 week, 2 weeks, ..., 4 weeks.
Some people don't want to keep up with the constant flow of updates on a daily basis, but still need to check their machines every now and then so they're not too far off of the security patches at least. So, for them the period of 1..4 weeks seems quite reasonable to me.
Edit: changed proposed default to be 0 days (none).
People cooperation do bring often funny moments, indeed. :-D
Concerning delay values, you know, it was first snapshot.
I agree it should be client customizable, as trade of being informed versus not being bothered.
It could also save mental health - Updating based on SUMO can become an obsession :-)
If one uses e.g. Secunia Personal software Inspector,
there is no security issue related to SUMO delayed notifications.
Not easy to implement and not a good "standalone" solution because i currently rely on user feedback (complains ?) in order to mark versions as beta.
It would only "postpone" the problem.
Maybe would it be worth to have 2 levels of users, to allow "power users" like you or Bytehead to contribute in advance to the maturity of the database before exposing an update to the rest of the community.
To be investigated deeper before implementation.
It is obvious SUMO relies on user feedback.
But in some way SUMO is over-relying on user feedback.
Users should mark "this crow is white"
and not "this crow is black" .... :-)
In some sense we already have 2 classes of users, based on beta displaying.
But for now it does not work,
as betas are always displayed, until somebody hides them.
In my mind, this delay is only meant for people who:
a) are interested [mostly] in non-beta releases ("Allow Beta updates" disabled);
b) favor information reliability more than immediate updates delivery;
c) are [mostly] passive, not as competent or just casual users (don't usually go into trouble of reporting via forum/email, anyway)
So, if we make the default delay to be 0 days, then such kind of users can practically opt-out to participate in the active [manual] beta feedback while getting a higher chance of relevant (although a bit delayed) update offerings instead. All others will continue to fight the World's entropy...
Exactly, bytehead understands me well in a-c points.
Last sentence is somewhat confusing.
0 days will act exactly as if feature is not implemented.
All new versions are immediately seen by all SUMO users.
After marking as beta Only "Beta users" keep seeing them.
I think lower frequency of "false stable" can have positive effect
on stable user participation.
n days combined with "Do not show betas"
will hide all new version for n days for Non beta users.
After then it appears for them if has stable mark.
SUMO server should help in determining white and black crows,
so beta users would just make corrections of server decisions.
OK, I'll clarify my point:
If we force n>0 days as the default delay, then most people will either not notice this new feature at all or will just complain about the stupid thing, because they don't get it and were not warned in advance. That's bad idea -- most community would just waste its time and do nothing useful (except for a couple of early adopters who will consciously *opt-in* to participate and reset it to 0).
On the contrary, if we set it to 0 by default, nothing will change for most users -- they will get immediate notifications of new versions as before and will still be able to participate in beta-reporting from day 1. But if they really want it (hopefully understanding the side-effects), they can *opt-out* now, tweaking this delay to whatever they feel fit for them.
The latter approach ("opt-out") imho is both safer for DB health and would allow for (a),(b),(c) group users to be less frequently annoyed by misguided offerings if they choose to experiment. Also, the default 0-delay would not discourage other people (especially new users) from being active and report early.
P.S. By the way, enabling "Allow Beta updates" option should effectively disable this delay (both in GUI and in logic): having both ON doesn't make sense.
||I forgot, is "Allow Betas" the default or not?|
I *think* it is not, but I guess, may Kyle will tell...
I agree with N=0 as default initial value....
I suppose many users already use "manual delay version"
by hiding for 1 day/ week,
thinking "we will see, if it is still stable.. ". :-)
I can also see the reason
for filter option like "Show stables and not yet confirmed betas".
As I may want to participate in categorization, best if just in server corrections.
But at the same time I may not be generally interested ( but exceptions )
in seeing betas.
All reported betas should be confirmed first (according to some predefined criteria) before being marked as such in the global DB. Then this would hold true: ["Allow Beta updates" = False] (default now) AND proposed default [delay = 0 days] == ["Show stables and not yet confirmed betas"].
The question is, how do we convert *reported* betas into *confirmed* ones? Atm, it is done only manually by admin, which is not very effective and scalable. We need to come up with a more practical solution before Kyle implements a more direct reporting facility (not using e-mail as transport).
For now, all is set as stable unless beta is confirmed, what fits scenario
like this well ( S-stable, b-beta )
S S S S S S S b S S S S S S S b S S S S S S S S b S S S S S S S S S S
Bit not the reversed scenario
b b b b b b b S b b b b b b b S b b b b b b b b S b b b b b b b b b b
Here beta and stable should switch the roles in server evaluation process.
So as in the former user corrects S to b,
in the letter user would correct b to S
So the item could have 3 flags on the server:
IsBeta Y/N - currently implemented
IsBetaByDefault Y/N - currently implied N, could be set by majority of states
IsConfirmed Y/N - Not implemented, would be default = N, would switch to Y
by verified user intervention IsBeta Y-> N
or vice versa.
||Not so easy to implement but for sure the most accurate and flexible solution.|
Well, here's the summary of ideas on the matter so far:
Possible versions verification paths:
1) manual by admin according to mail/forum user reports (current process, must be deprecated in future);
2) semi-automatic by _registered_ users (e.g. using tripcodes or back-traceable keys in case of intentional abuse or repeated misconduct, so that special tagging rights could be easily revoked) -- needs only 1 verified user to confirm beta/non-beta;
3) semi-automatic by _anonymous_ users -- needs N generic users to confirm (N=3 is a good start, imho);
4) automatic by checking the official sites and/or established software distribution sources (parsing ftp/html/rss/xml/...) -- suitable for high-profile apps only (0001669).
To increase users' responsibility and to prevent easy abuse of the system, verified user IDs must consist of 2 parts (the latter is mandatory, imho):
1) a registered user name -- mapped on the server to a verified e-mail address (although this is debatable due to privacy concerns);
2) a world-wide unique, machine-specific, persistent and hard to spoof anonymous string (say, MD5 hash of [HDD#0 S/N] & [Windows S/N]);
This key could be generated in memory on the client side and then sent alongside every user report and get stored in the DB. Then, the black list of misbehaving users (both registered and anonymous) could be easily maintained on the server, should it be required in future.
The question still remains what approach should we follow in general to be most effective and less error prone in wide usage:
a) continue to consider all new versions as stable and tag only betas* (in fact non-stable and/or non-public builds, to be more precise);
b) consider all new versions as betas* by default and tag only stable public releases;
c) selectively apply [a] or [b] for each item (either via historical data analysis or by manual tweaking).
In any case, all betas should be clearly tagged as such in the UI (e.g. a different column, [beta] suffix, special icon or whatever), otherwise it will be impossible to reliably spot and report errors (see 0001794 and my comments in 0001704). The process of reporting/fixing *improperly* confirmed versions must also be standardized.
The proposed delay of reporting unverified versions makes the above complex approach even more complete, sophisticated and flexible, imho.
Ideally, all this should be combined with reporting minor and major version updates in the separate columns with an added ability to tweak on a per item basis (locally) what one considers to be a major number position in the version pattern. In such a case user would simultaneously see all minor updates (usually security related) and also major updates (usually functional ones) as soon as they become public (see 0001783), and be able to easily maintain concurrent branches, too.
> 2) semi-automatic by _registered_ users (e.g. using tripcodes or back-traceable
> keys in case of intentional abuse or repeated misconduct, so that special
> tagging rights could be easily revoked) -- needs only 1 verified user to
> confirm beta/non-beta;
> 3) semi-automatic by _anonymous_ users -- needs N generic users to confirm
> (N=3 is a good start, imho);
This has of course reflect number of SUMO users using the application.
There are many apps where N=3 means all users or even more.
N = Int( c . Log(Nusers) ) + 1
N = 1/c . sqrt( c . Nusers )
Good point, [int(Log10(N_users))+1] looks fine to me if N_users = *total* number of users of all versions of the particular application.
Regardless of the exact formula, I think we also need to implement 2 more things:
1) a similar counter-correction procedure, so that it would be possible to revert someone's erroneous tagging (incl. your own);
2) if someone has changed (confirmed or reverted) the tag, his local DB should be immediately affected without waiting for others (N-1) to approve the decision globally.
Good points, I like it.
I agree with *total*.
Thank you very much to both of you !
Sorry not to have the time to implement it as quickly as i would like but you're doing a GREAT and valuable work in analysis and solution validation.
For a developper like me, it is greatly appreciated and i wanted to tell it to both of you !
You're welcome, Kyle!
Actually, my natural born laziness is to blame here -- it's usually driving me to seek proper and long term solutions ;) I hate to do boring, tedious and repeated manual tasks, I'd rather strain my brain a bit and give some rest to my other parts -- I might need them for more pleasant things in life ;)
By other words - lazy men were always the source of progress.
They did not regret any effort to make their work easier. :-)
Although the trick is to also have enough mental capacity and knowledge...
When SUMO client realizes a user has a SW version not yet registered in the server, it could ask user for defining the beta/release status.
Then it would upload the new version + status to the server database.
This can work together with default beta/release settings.
Possibly triggered for default beta items only, like MPC-HC or FFDShow.
Edit: Posted as dedicated FR.
||Good idea, and I think it should ask it irrespective to the default beta/non-beta preset, there should be 4 possible answers available: Beta, Stable Release, Other (alpha, dev, preview, OEM or custom build, etc.), Not sure (or I Don't Know). The latter one translates into default status for current item, while the former one (Other) translates into Beta for now (for the lack of a better status yet).|
I agree. I hope users will not be confused by Other.
Improvement: SUMO would ask all users until some of them answerd Stable/Beta, i.e. "Dont know" does not counts.
But, there must be managed possible race conditions.
|2012-10-22 08:33||poutnikg||New Issue|
|2012-10-22 18:16||bytehead||Note Added: 0001277|
|2012-10-22 18:18||bytehead||Note Edited: 0001277||View Revisions|
|2012-10-22 18:19||bytehead||Note Edited: 0001277||View Revisions|
|2012-10-22 18:23||bytehead||Priority||low => normal|
|2012-10-22 18:39||bytehead||Note Added: 0001278|
|2012-10-22 19:11||poutnikg||Note Added: 0001280|
|2012-10-22 21:06||Kyle_Katarn||Note Added: 0001281|
|2012-10-22 21:06||Kyle_Katarn||Assigned To||=> Kyle_Katarn|
|2012-10-22 21:06||Kyle_Katarn||Status||new => feedback|
|2012-10-23 01:40||poutnikg||Note Added: 0001285|
|2012-10-23 01:40||poutnikg||Status||feedback => assigned|
|2012-10-23 01:41||poutnikg||Note Edited: 0001285||View Revisions|
|2012-10-23 06:36||bytehead||Note Added: 0001288|
|2012-10-23 06:38||bytehead||Note Edited: 0001277||View Revisions|
|2012-10-23 06:40||bytehead||Note Edited: 0001278||View Revisions|
|2012-10-24 17:31||bytehead||Note Edited: 0001288||View Revisions|
|2012-10-24 18:33||poutnikg||Note Added: 0001294|
|2012-10-24 18:33||poutnikg||Note Edited: 0001294||View Revisions|
|2012-10-25 06:20||bytehead||Note Added: 0001295|
|2012-10-25 06:21||bytehead||Note Edited: 0001295||View Revisions|
|2012-10-25 06:22||bytehead||Note Edited: 0001295||View Revisions|
|2012-10-25 06:22||bytehead||Note Edited: 0001295||View Revisions|
|2012-10-25 06:24||bytehead||Note Edited: 0001295||View Revisions|
|2012-10-25 06:30||bytehead||Note Added: 0001296|
|2012-10-25 10:31||poutnikg||Note Added: 0001297|
|2012-10-25 10:37||poutnikg||Note Edited: 0001297||View Revisions|
|2012-10-25 14:09||poutnikg||Note Added: 0001298|
|2012-10-25 14:12||poutnikg||Note Edited: 0001298||View Revisions|
|2012-11-10 01:29||bytehead||Note Added: 0001318|
|2012-11-10 02:56||poutnikg||Note Added: 0001319|
|2012-11-10 10:57||poutnikg||Note Edited: 0001319||View Revisions|
|2012-11-10 11:02||Kyle_Katarn||Note Added: 0001321|
|2012-11-10 20:45||bytehead||Note Added: 0001322|
|2012-11-10 21:04||bytehead||Relationship added||related to 0001669|
|2012-11-10 21:04||bytehead||Relationship added||related to 0001794|
|2012-11-10 21:05||bytehead||Relationship added||related to 0001704|
|2012-11-10 21:06||bytehead||Relationship added||related to 0001783|
|2012-11-10 21:12||bytehead||Note Edited: 0001322||View Revisions|
|2012-11-10 21:13||bytehead||Note Edited: 0001322||View Revisions|
|2012-11-10 23:33||bytehead||Note Edited: 0001322||View Revisions|
|2012-11-11 00:07||bytehead||Note Edited: 0001322||View Revisions|
|2012-11-11 00:11||bytehead||Note Edited: 0001322||View Revisions|
|2012-11-11 20:30||bytehead||Note Edited: 0001322||View Revisions|
|2012-11-12 15:49||poutnikg||Note Added: 0001323|
|2012-11-13 00:59||bytehead||Note Added: 0001325|
|2012-11-13 01:00||bytehead||Note Edited: 0001325||View Revisions|
|2012-11-13 01:00||bytehead||Note Edited: 0001325||View Revisions|
|2012-11-13 06:48||poutnikg||Note Added: 0001326|
|2012-11-13 21:20||Kyle_Katarn||Note Added: 0001328|
|2012-11-13 23:59||bytehead||Note Added: 0001329|
|2012-11-14 00:00||bytehead||Note Edited: 0001329||View Revisions|
|2012-11-14 00:38||poutnikg||Note Added: 0001330|
|2012-11-14 03:00||bytehead||Note Added: 0001331|
|2012-11-29 11:22||poutnikg||Note Added: 0001335|
|2012-11-29 11:23||poutnikg||Note Edited: 0001335||View Revisions|
|2012-11-29 20:02||bytehead||Note Added: 0001336|
|2012-11-30 00:14||poutnikg||Note Added: 0001338|
|2012-12-02 23:51||poutnikg||Note Edited: 0001338||View Revisions|
|2012-12-03 12:01||poutnikg||Note Edited: 0001338||View Revisions|
|2012-12-11 04:20||bytehead||Relationship added||related to 0001851|
|2012-12-17 14:16||poutnikg||Note Edited: 0001335||View Revisions|
|2013-09-17 20:05||Kyle_Katarn||Status||assigned => acknowledged|