View Issue Details

IDProjectCategoryView StatusLast Update
0001800SUMoNew Featurepublic2013-09-17 20:05
ReporterpoutnikgAssigned ToKyle_Katarn 
PrioritynormalSeverityfeatureReproducibilityN/A
Status acknowledgedResolutionopen 
PlatformDesktopOSWindows Vista 64OS VersionHome Premium SP2
Product Version3.4.8 
Target VersionFixed in Version 
Summary0001800: Optional time postponing of diplaying new versions
DescriptionIn 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.



TagsNo tags attached.

Relationships

related to 0001794 acknowledgedKyle_Katarn Display of beta updates on client side 
related to 0001704 acknowledgedKyle_Katarn the ability to see beta for each individual program 
related to 0001783 acknowledgedKyle_Katarn Management of more product lines/series updates 
related to 0001851 acknowledgedKyle_Katarn Asking user for SW stable/beta status when not registered version is found 
related to 0001669 acknowledgedKyle_Katarn Adressing eternal beta reports 

Activities

bytehead

2012-10-22 18:16

reporter   ~0001277

Last edited: 2012-10-23 06:38

View 4 revisions

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

bytehead

2012-10-22 18:39

reporter   ~0001278

Last edited: 2012-10-23 06:40

View 2 revisions

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

poutnikg

2012-10-22 19:11

reporter   ~0001280

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.

http://secunia.com/vulnerability_scanning/personal/

Kyle_Katarn

2012-10-22 21:06

administrator   ~0001281

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.

poutnikg

2012-10-23 01:40

reporter   ~0001285

Last edited: 2012-10-23 01:41

View 2 revisions

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.

bytehead

2012-10-23 06:36

reporter   ~0001288

Last edited: 2012-10-24 17:31

View 2 revisions

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

poutnikg

2012-10-24 18:33

reporter   ~0001294

Last edited: 2012-10-24 18:33

View 2 revisions

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.

bytehead

2012-10-25 06:20

reporter   ~0001295

Last edited: 2012-10-25 06:24

View 5 revisions

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.

bytehead

2012-10-25 06:30

reporter   ~0001296

I forgot, is "Allow Betas" the default or not?

poutnikg

2012-10-25 10:31

reporter   ~0001297

Last edited: 2012-10-25 10:37

View 2 revisions

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.. ". :-)

poutnikg

2012-10-25 14:09

reporter   ~0001298

Last edited: 2012-10-25 14:12

View 2 revisions

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.

bytehead

2012-11-10 01:29

reporter   ~0001318

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

poutnikg

2012-11-10 02:56

reporter   ~0001319

Last edited: 2012-11-10 10:57

View 2 revisions

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.

Kyle_Katarn

2012-11-10 11:02

administrator   ~0001321

Not so easy to implement but for sure the most accurate and flexible solution.

bytehead

2012-11-10 20:45

reporter   ~0001322

Last edited: 2012-11-11 20:30

View 7 revisions

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.

poutnikg

2012-11-12 15:49

reporter   ~0001323

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

Something like
N = Int( c . Log(Nusers) ) + 1
or
N = 1/c . sqrt( c . Nusers )

bytehead

2012-11-13 00:59

reporter   ~0001325

Last edited: 2012-11-13 01:00

View 3 revisions

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.

poutnikg

2012-11-13 06:48

reporter   ~0001326

Good points, I like it.
I agree with *total*.

Kyle_Katarn

2012-11-13 21:20

administrator   ~0001328

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 !

bytehead

2012-11-13 23:59

reporter   ~0001329

Last edited: 2012-11-14 00:00

View 2 revisions

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 ;)

poutnikg

2012-11-14 00:38

reporter   ~0001330

By other words - lazy men were always the source of progress.
They did not regret any effort to make their work easier. :-)

bytehead

2012-11-14 03:00

reporter   ~0001331

http://is.gd/ozGpgN

http://is.gd/wukp0P

Although the trick is to also have enough mental capacity and knowledge...

http://is.gd/zbbENO :)

poutnikg

2012-11-29 11:22

reporter   ~0001335

Last edited: 2012-12-17 14:16

View 3 revisions

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.

bytehead

2012-11-29 20:02

reporter   ~0001336

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

poutnikg

2012-11-30 00:14

reporter   ~0001338

Last edited: 2012-12-03 12:01

View 3 revisions

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.

Issue History

Date Modified Username Field Change
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