search

sailfishos-patches / patchmanager

Patchmanager for SailfishOS
https://openrepos.net/content/patchmanager/patchmanager
Other
21 stars 22 forks source link

[Suggestion] need of ALPHA and BETA labels to warn users #439

Closed robang74 closed 1 year ago

robang74 commented 1 year ago

DESCRIPTION

It would be useful to have two labels ALPHA in red and BETA in yelow to clearly aware the users that a Patch Manager is not ready for universal deployment.

ADDITIONAL INFORMATION

https://forum.sailfishos.org/t/the-dnsmasq-connman-may-conflict-patch-available/15947/8

nephros commented 1 year ago

Users of Patchmanager and its Web Catalog are presumed to be end users, not alpha or beta testers.

Therefore releasing on the Web Catalog means the patch is tested and ready for PRODUCTION. Not alpha, not beta, not works-well-enough-for-me. Production.

Untested or not-yet-well-tested patches should be distributed in other ways.
Known-bad patches should never end up on Web Catalog, removed if their badness is discovered later, or (preferrably) fixed to be not-bad.

nephros commented 1 year ago

That being said I believe the idea has its merits, but bears the risk that patches stay at Alpha or Beta mark forever.

Another aspect is that the WebCatalog software is available here and anyone can spin up an instance. And since #296 PM supports different server URLs for its Catalog.
So what could be done is improve upon that PR to make the server runtime-configurable (currently it's compile-time), then a developer could run their own "testing" instance of the Catalog, and beta-testing users can switch to that.

A bit like Chum-GUI allows for switching between chum and chum:testing.

Olf0 commented 1 year ago

If I understand the description of this feature request correctly, this is primarily about the PM-Webctalog to provide an flag attribute (with the values {alpha, beta, release}) and the ability for an uploader of a Patch to set it in the Webcatalog's web-frontend. Patchmanager proper (IIUC) then only needs to be extended to retrieve and display this attribute for each Patch in the Webcatalog, correct?

Consequently IMO this should be filed as a feature request for the PM-Webctalog, just as (likely) issue #440, too. Please mind the details denoted in the discussion thread for issue #440.

robang74 commented 1 year ago

Users of Patchmanager and its Web Catalog are presumed to be end users, not alpha or beta testers.

and

That being said I believe the idea has its merits, but bears the risk that patches stay at Alpha or Beta mark forever.

Please, consider that a testing a patch could be easy - sometimes - and other times quite hard. Not just because the corner cases but also because the different hardware/users interaction like A-GPS patch.

A patch in production with 0.0.1 can be? This is the main point. Among the Web Catalog there are ALSO end-user that do not care that 0.0.1 - 0.0.x means that it is an early attempt to fix a problem, not a solution. Uhm, end-user only? Look at the projects in web catalog some of them have 1.0.0 at one certain point while others simply follow the 0.0.x schema with some patches arrived to 0.1.17 or something like that.

This is the reason because we need two flags. Not 3 but 2. A patch that arrives in production means that has been integrated in the Jolla image or a in a Jolla package or in a 3rd party package. That's is production! :-)

this should be filed as a feature request for the [PM-Webctalog](https://github.com/CODeRUS/django-test

Correct. Now, I know the difference. Thanks Olf0.

robang74 commented 1 year ago

Moved to the right project. This can be closed.

Olf0 commented 1 year ago

O.K.

A patch in production with 0.0.1 can be?

Yes.

… 0.0.1 - 0.0.x means that it is an early attempt to fix a problem, not a solution.

No, semantic versioning is just a suggestion nobody can be forced to adhere to.