We have moved to a new Sailfish OS Forum. Please start new discussions there.
15

Crowd QA : Jolla Greenlight

asked 2015-10-20 15:57:27 +0300

tortoisedoc gravatar image

updated 2015-10-20 16:02:12 +0300

Hey; given the recent QA team limitations it feels tempting to propose a "Jolla greenlight" - á la Steam Greenlight, for instance;

where SFOS Apps are uploaded in BETA stage; simple RPM validation pass is only entrance requirement and app is then distributed (labeled as BETA) to users. Once Greenlight is OK (=all bugs closed), app can be submitted to harbour QA. Could make things easier?

  • Pros : users can beta-test apps in a crowd-sourced way

  • Cons : needs tools to provide developers with feedback and differentiate Greenlighted beta apps from QA-passed ones.

Point of this is to get users aware of apps needing QA; and as well apps finding testers.

I could envision a similar "service" being deployed on Openrepos.

edit retag flag offensive close delete

Comments

7

A lot of developers do this already, with pre-releases on Openrepos and proper releases on Harbour.

This is somewhat similar to the 'chum' idea for a community repo on MerOBS, although that never really went anywhere.

r0kk3rz ( 2015-10-20 16:19:38 +0300 )edit

yes; the point is just that currently there is not much visibility; unless you sail on openrepos you do not know apps are there. And it would not be so much about the repo, but more about the differentiation of beta vs final apps; as well as the integration with tools(bug reporting etc) A repository alone (as good as it might be) cannot give you that

tortoisedoc ( 2015-10-20 16:32:40 +0300 )edit

1 Answer

Sort by » oldest newest most voted
4

answered 2015-10-20 18:21:00 +0300

r0kk3rz gravatar image

Perhaps a Community QA could be built around Open Source apps, and enabled by referencing the project's Github/Gitlab repository.

Such apps would be built from source in a managed OBS instance, validated, and published in a 'Greenlight' section of Harbour for QA by the community. This would encourage Open Source development, as well as provide a bit of community trust around the apps they're using and what they do (and don't do).

Open Source apps would be easier for the Community to QA, and less risky than allowing people to download arbitrary binaries with only automated verification.

edit flag offensive delete publish link more

Comments

2

and how about non-open source apps? not everyone is necessarily comfortable with open-sourcing; and definitely enforcing opensource by making it mandatory is not a very open way to proceed either, is it? note that this is not a critic against opensource but against the idea to enforce it.

tortoisedoc ( 2015-10-20 18:26:32 +0300 )edit
2

non-open source apps can continue to be submitted as they are now, and released onto harbour when they pass the current QA process.

Nothing mandatory about it at all.

The issue around non-open source applications, is without a reasonable amount of QA you cannot be certain they are safe to even beta test by the community, and automatically publishing them would be open to malware.

r0kk3rz ( 2015-10-20 18:36:29 +0300 )edit

Harbour is in no way safer; i can recall at least two ways of working around the qa. what are the chances for the average user to look at any source? assuming he knows what he is lookinh at? i doubt it being much safer, tbh. openssl is a great example in that sense. for source to b safe, there would need to be constant reviews. this defies the purpose for the system to be efficient im afraid.

tortoisedoc ( 2015-10-20 18:49:46 +0300 )edit

The whole point of QA is about protecting the 'average user', bypassing it for them kinda undermines that effort.

I'm not saying that the current QA process is perfect, but the goals of the QA process should at least aspire to providing a good experience for the 'average user', by ensuring only trustworthy apps are available to them.

Sure, having the source code isn't a silver bullet, but its better than having no source code at all. Comparing phone apps to cryptography libraries is a bit disingenuous though, just because an approach isn't optimal in all cases doesn't mean it is without merit.

r0kk3rz ( 2015-10-20 18:59:44 +0300 )edit
1

From an efficiency perspective, beyond the initial QA, the QA Tester can look at things like the commit history, and code changes since the last release. So can focus their efforts on the areas they know have changed, and have good assurances on the things that haven't changed.

This means for minor releases and bug fixes, QA can be processed efficiently without compromising safety.

r0kk3rz ( 2015-10-20 19:27:07 +0300 )edit
Login/Signup to Answer

Question tools

Follow
1 follower

Stats

Asked: 2015-10-20 15:57:27 +0300

Seen: 683 times

Last updated: Oct 20 '15