As the discussion of perks of Ubuntu Membership process is going on I came across a perk that can potentially be used to attract more perspective ubuntu members
Why can’t we expand the purview of Ubuntu contributing developers to those who work on snaps and flutter apps and the Ubuntu software center or have them as “non-uploading” Ubuntu developers so that another avenue for Ubuntu membership path opens up motivating people who contribute to snaps and maintainence of such apps in the Ubuntu software center to get Ubuntu membership through quality contributions.
Well, since you split this out into its own topic, let me repeat the answer i gave in the other thread
I don’t think you can count snaps in general as an Ubuntu contribution, after all they are supposed to be used universally across all linux systems …
Regarding snaps that are focused on Ubuntu like the snap store or the installer etc, I’d count the contribution based on github activity instead, not necessarily bound to the packaging format they are delivered with…
Yes I understand that, I made it into a separate topic because I want to understand the definition of a contribution here, like if it impacts ubuntu as an ecosystem… then it fits the definition I guess
maybe there is needed more collaboration with Github about CLA and with situations about dedicated gitlabs like in GNOME and long year efforts to make something into upstream something is maybe broken…
and some qa status not bring foundations air into some release trouble or bugs overviews when a lot of years of bugs on launchpad does not have drive for it desolation even when today there are associations for bug hunting maybe not only in CVE world…
so some memberships does not solve a lot of things and CLA does not in current world bring something which is easy collaborable for others to catch some issues when needed and maybe something more overtime, cloud is not everything…
And thousands of Canonical github repos is only mismatch in a more wider launchpad mess when there is no easy overview of issues and what is desired to do…
The CLA is not required for contribution to Ubuntu. Watch my wording very closely as to take out any ambiguity, namely product vs project.
Ubuntu, as a product, is an enterprise product of Canonical, but is not exclusively worked on under a CLA by any means, only if you want to work on certain, very specific items, such as ubuntu-desktop-provision (the framework behind the installer). For instance, you don’t have to sign the CLA to work in packaging and patching, you only need to gain the proper developer memberships through the Developer Membership Board by demonstrating the proper competence.
Ubuntu, as a project, is community-driven and doesn’t require the CLA to be involved at all. There are many components to this project, such as community moderation, idea contribution, and such.
Snapcraft, Juju, and such are products of Canonical that are not projects of Ubuntu which very well may require signing of the CLA. Ubuntu is just one of many Canonical products, but it doesn’t require a CLA, only certain, very specific components
Let’s say for instance, I do a bunch of snaps and maintain it in the Ubuntu ecosystem and provide free access and free community support through my GitHub repository as the main hosting platform, in line with our community philosophy, then
Will it be considered as a contribution towards the Ubuntu community and development?
Going back to my days on the app review board, we had a strict parameter that if a piece of software need to be maintained in the Ubuntu software center it has to follow certain guidelines of free software…
So what in the case of a scenario like this applied to snaps or apps on the software center by a developer?
Hah, funny you mention that since it was actually one of the reasons that caused snaps to be as they are today (a system designed in a way that you do not need to review the apps due to the security model that applies)
I guess you remember as well that single Deb reviews could take months (I think when we stopped doing that there were still a good bunch of unreviewed uploads idling since months)
All the technical guidelines that were applied back then actually formed the base for the existing snap confinement and interface system…
So in the snap ecosystem no guidelines need to exist (well, there are some but very few) and reviews only need to happen in certain special cases where super privileged interfaces are used.
I’m not remembering if we had a single of these Deb based app developers apply for membership based on these packages though…
(So I don’t know if we would have counted it as a contribution enough to become a member only based on this)
Well, I’m neither in the membership board nor in the community council
I’m just stating my personal opinion here and enjoy the discussion, it is not up to me to make any decisions, if our governing entities above decide for it, guidelines could indeed be set up and if they think snap contributions should count then this is fine
& upload package to some TestingCentre like if builds are reproducible or there is some issue
in snap world it could mean also under some clamav(now Cisco… or others…) package scan or SCentre hook with addons and policies, it could not be so problem when also AppImages or NodeJS problems could also vary…
with Debian reproducible builds and apt list & download possibility… but with AppImages there are also traffic hosting issues and Github APIs are also limited with juicy region sets not much widespread in some areas…
Just that when I attend conferences and see the snap workshops or talks, it has made me think about what is the contribution of snaps wrt ubuntu development and ubuntu ecosystem… so having fun discussing ideas
Seems good but what about dependent packages in control file? How can we be sure that they work for a specific version of Ubuntu and also they don’t depend on something from the multiverse repo?
In other simple words, make quality and autopkgtests a minimum mandatory standard in accordance to the debian standards version?
Snaps, are an asset to Ubuntu, yet, Canonical as a company has more control over it than Ubuntu Community. This can be seen where the review team consists no one from the community, there is no policy feedback and general feedback taken into account while developing snapd and snapcraft. Even if they’re taken, it takes years to actually see it in work. Whataboutism is not really a good idea, IMO, but, we can clearly see other packaging formats and how their policies are hugely influenced by distros that are even derivatives of Ubuntu.
@eeickmeyer if you remember last year’s summit when I showed you, how we can fix the theming issue with KDE apps, you and David(Ubuntu Budgie) told me, that it’s a one liner fix. Well, to find that one liner fix, I needed to delve into the source code of Kirigami, how themes are set, it led me to the source code of KConfig and from there to Qt StandardPaths, that’s when I realised that it reads the $HOME/.config/kdeglobals file, and we need to add $HOME/.config in XDG_CONFIG_DIRS. I created a PR first in snapd to update the desktop plug, that allows read access to $HOME/.config/kdeglobals, but the next step, setting the path, was not yet merged. But the PR in snapd was the reason why even that one liner fix was working. It was me, who had no idea about any of these things, that’s why it took me months to figure it out. I believe if that was done by someone from the snapd team, in response to our feedback that theming in KDE snaps ain’t working. I believe it could’ve hardly taken a week or two.
I think that should be on the applicants and not us. We should not search for whom to make a member and whom not. Rather, we should focus on those, when someone brings it up.
EDIT: I guess we’re forgetting the division between Ubuntu Member and Ubuntu Developer. One can be easily an Ubuntu Member, as it takes all kind of contributions into account, but not an Ubuntu Developer. Even with my contributions, I am not and don’t think can apply for Ubuntu Developer status.
Fair enough as it’s a case by case basis but what @ogra pointed out is the free structure of how the snap ecosystem is setup.
In that case, some sort of a mandatory standard should be setup I guess as you pointed out above… kde snaps can be used for other distros too so how to maintain the standards reflecting our community philosophy?
Yes but no as there is a route for Ubuntu membership through contributing developer status means one who is active in ubuntu development but doesn’t have upload rights yet