Also: Does this apply to extensions as well?
Maybe as io.gnome.extensions.* to separate them from the app namespace?
1 Like
My understanding is that Gitlab will automatically redirect if a project’s group changes.
Maybe it could, but I think I’d want to get it up and running for apps and libraries first, at least so we get a sense of the workload involved.
Umm, like a team of developers whose team has a name and wish to improve the application and take care of supporting it. GNOME Circle can help them with infrastructure and other features apart from coding?
If it’s just a team, then sure a project could apply to become a member of the Circle initiative. Or they could even use GNOME infrastructure without joining the Circle.
The particular clause that we’ve been talking about is mostly meant to clarify that the Circle initiative isn’t intended for big projects which don’t really need our help, like LibreOffice or Blender.
2 Likes
Looks like a plan. Let me know where I can follow the final category for gnome world apps like glade or gitg
Anything we came out with will be valid for me, but not really sure when it will be resolved.
2 Likes
The proposal looks good for me, and quite in line with other changes of these last years.
As this proposal will cause (as I understand it) some repositories moves, I’d like to suggest an idea I have in mind since some times, that would be greatly done at the same time. It is related, of course, to games (all games, not only the Games application): instead of placing them in Circles, wouldn’t it be better to have a real Games category of applications in the GNOME infrastructure? Games are a quite specific kind of applications, and that would notably allow distros to have a good filter of known “all public” games; maybe also help for their development coordination. I didn’t discuss this idea with other games maintainers, so really just take it as an idea I had.
1 Like
I get that .io is a popular one per Emmanuele’s post response to this. Did y’all consider using app.gnome instead? I would think that would be more appropriate.
1 Like
gnome.app is already taken, though we could spend EUR 1100 to get it from the domain squatter that owns it.
We need to own the domain in order to use a reverse-DNS notation for an application id.
1 Like
Ah, that’s a shame :/. app.gnome would look pretty well.
Hey @arnaudb!
From a GNOME Circle perspective, I think we could accommodate that kind of arrangement; I think it’s mostly a question for the Gitlab maintainers.
Hi, I think the applications that want to be part of Circle should be translated into Damned Lies, to have a homogeneous translation with the official applications.
Some modules like Nautilus, Evolution and Builder are maintained by people paid by Red Hat (could be other apps and another company). In some cases they are paid to do it full time, in some cases the need for maintenance is lower and that is not their only job.
The proposal as it is currently kind of sounds like such apps can’t be in GNOME Circle since they have that kind of “sponsoring organization”.
Maybe some company like endless once it has completed its change of purpose would fall into this category.
Or even Purism.
Is it really solving any problem, then? Nobody is producing third-party apps named “GNOME Foo” currently. But people do produce third-party apps named “Foo” developed in repositories named “gnome-foo” which everyone calls “GNOME Foo.” If the goal is to get third-party developers to stop using software repositories named “gnome-foo,” then this interpretation of the guidelines doesn’t accomplish much.
It’s just the publicly visible app name that’s covered by the draft policy (the brand name, if you will). Executable names and repo names aren’t a concern.
Sorry if that was unclear; I’ll add a note about repo names to the FAQ.
Yeah. We need some better language for the section on sponsoring organisations.
Red Hat is quite a good example. I would say that it is the sponsoring organisation for Fedora but not for Nautilus, Evolution or Builder. In the former case, it owns some IP for the project and provides support to the wider community. In the latter cases, it pays for developer time but its official relationship with the project ends there.
For me the trickier case would be something like Yorba back when it was active. My feeling is that the products being worked on by a small company like that should be able to qualify for Circle. Maybe it’s just a question of a) scale and b) whether community support is already available.
I’m not sure this is even needed. I guess the targets for this are LibreOffice and Firefox mostly, and I doubt they’d apply?
2 Likes
Hi. You can check the later discussions, the issue was clarified . ^^
If anyone would be interested in helping to get the Circle initiative off the ground, we’ll be looking for volunteers! The work will mostly involve reviewing apps and libraries, to see if they meet the criteria for joining. Just let me know if you’re interested.
1 Like