On 18.03.2022 19:22, Bernd Ritter wrote:

Hi Lubos,

what does that mean? I would like to contribute.

So you can start right now.

https://github.com/openSUSE/software-o-o

Cheers, Bernd

Am 18.03.22 um 16:03 schrieb Lubos Kocman:

...

Meanwhile following hackweek project is open to any volunteers https://hackweek.opensuse.org/21/projects/software-dot-opensuse-dot-org-repl...

Lubos Kocman píše v Čt 17. 03. 2022 v 21:05 +0000:

...

Hello openSUSE!

One of the outcomes of today's *community meeting was that we need to decomission the current *software.opensuse.org code-base, as we can't find volunteers to maintain it nor develop it any further. The current code-base and its deployment is tied to ruby25 which makes appliacations of security fixes for currently used rubygems almost inpossible.

Our social platforms (forums-o-o, discord, etc) show many cases where incorrect usage of the service leads to Leap systems being partially migrated to Tumbleweed, or you end up with Tumbleweed which has enabled a lot of invalid repos. The situation is not going likely to improve without care any time soon.

At the meeting we agreed that decomission of the service is needed, and that there is still a need to provide functionality that allows people to search for and install software which is not part of their install, and/or to search for version numbering or the status of the NEXT/devel project(s).

There was already a *brainstorm  about the services' future, but there was not much progress in that direction.

I really hope that this can ignite some constructive discussions that could help us to develop a replacement for the current service. As suggesed in the meeting minutes there are upcoming opportunities that we could make use such as gsoc, outreachy, hackweek. We should not try to make this a ruby vs python vs node fight, but instead try to find a sustainable solution to keep the service running for the next decade.

[0] https://github.com/openSUSE/software-o-o [1] https://etherpad.opensuse.org/p/weeklymeeting20220317 [2] https://etherpad.opensuse.org/p/softwareworkshop

Thank you very much in advance

ps. There is no particular date for decomission yet, but it's coming.

Also, just a thought that's maybe completely wrong, but maybe it would be easier for people to contribute if Ruby weren't involved here. I would think just using JavaScript for the backend would be entirely possible and make it easier for people to contribute. All the software site really needs to do is make a couple of API calls for information and render a page with that information... seems like involving Ruby maybe overcomplicates things.

Actually, due to opi and opi-proxy, authentication is no longer needed for any API requests that would be relevant to the search page.

Example: https://opi-proxy.opensuse.org/?obs_api_link=https%3A%2F%2Fapi.opensuse.org%...

On Fr, Mär 18 2022 at 17:42:30 -0000, Sy retia simonizor@protonmail.com wrote:

I assume you're talking about 1-click installs here? I think this is more of a problem with yast-metapackage-handler. It should be checking if the repositories are compatible with the release the user is on, and it needs to offer an option to set the repo priority before installing anything. I think the 1-click installs are a really good idea, but yast-metapackage-handler needs improvement. Making yast-metapackage-handler more robust by adding the option for priorities, probably even defaulting to a lower priority for repos being added through 1-clicks, and making sure the repo being added matches the release the user is running fixes all of the problems for users that you mentioned above. I know a lot of users really like the 1-click installs, and I think abandoning them completely would be a huge mistake.

There's a small issue of packages like the kernel, which is built in a repo based on Factory, so there's no way to automatically tell the metapackage-handler to do the right thing in case of installing on Leap. I was thinking maybe it would be possible to provide a single ymp file for the package in obs instead of splitting them per output repository, which does have a potential to fix some issues there, but of course RPM specs are free to output packages with any name in any distribution, so that still ends up fragmented.

I understand the need to update the backend to something more secure, but I think pushing this discussion in the direction of getting rid of features is a mistake. It really shouldn't be super difficult to tweak yast-metapackage-handler so that it can be safer for users. Also, there are a few other instances where 1-click installs come in handy such as adding codecs from Packman easily. I really think improving yast-metapackage-handler is the better option over abandoning 1-click installs entirely.

Feel free to contribute to yast-metapackage-handler if it's not that hard, it hasn't gotten much maintenance over the past decade, and I can guarantee you the yast team will be happy to accept patches to it. Even a solution outside of yast would work, but the last try with that died quite quickly.

LCP [Sasi] https://lcp.world/

On 2022-03-18 20:14, Sy retia wrote:

I was just identifying the problem and suggesting a possible fix. The whole "feel free to contribute" attitude is unnecessary and off-putting.

So this is only about the one click install feature, and not the entire software.opensuse.org site going to be removed?

On Fr, Mär 18 2022 at 19:14:21 -0000, Sy retia simonizor@protonmail.com wrote:

I was just identifying the problem and suggesting a possible fix. The whole "feel free to contribute" attitude is unnecessary and off-putting.

Apologies, knowing your long term invaluable contributions to the project, I thought you would be excited to work on such a thing. I was wrong though, for which I'm sorry.

LCP [Sasi] https://lcp.world/

On Mär 22 2022, Ludwig Nussel wrote:

The right thing is to not install such things on Leap. I guess you are talking about Kernel:stable which is Factory only. The one built for Leap is in Kernel:stable:Backport AFAICT.

The problem is that it isn't offered as the first option, instead it is hidden behind a Big Red Warning. All you get by default is the Tumbleweed package.

On Mär 22 2022, Martin Wilck wrote:

True. Unfortunately that's expert knowledge, and there's nothing to prevent Leap users who are unaware of it from trying to install Kernel:stable packages.

There is: the kernels from Kernel:stable are uninstallable on Leap.

It would be helpful if the Kernel:stable repository had a name that would suggest "factory only", e.g. "openSUSE_Factory" rather than "standard". Likewise for Kernel:stable:Backport.

The problem actually is that Tumbleweed is offered as an option, and adding *that* to a Leap system is disastrous.

On 3/23/22 04:47, Carlos E. R. wrote:

On 22/03/2022 14.57, Martin Wilck wrote:

...

On Tue, 2022-03-22 at 11:09 +0100, Ludwig Nussel wrote:

...

Sasi Olin wrote:

...

[...] There's a small issue of packages like the kernel, which is built in a repo based on Factory, so there's no way to automatically tell the metapackage-handler to do the right thing in case of installing on Leap.

The right thing is to not install such things on Leap. I guess you are talking about Kernel:stable which is Factory only. The one built for Leap is in Kernel:stable:Backport AFAICT.

True. Unfortunately that's expert knowledge, and there's nothing to prevent Leap users who are unaware of it from trying to install Kernel:stable packages.

It would be helpful if the Kernel:stable repository had a name that would suggest "factory only", e.g. "openSUSE_Factory" rather than "standard". Likewise for Kernel:stable:Backport.

It would help if repositories had a large description field, and both zypper and yast would display this description when attempting to add a repository, and on request.

Most Repos do have such a description, some even have a warning where not to use them on obs, I doubt this is easy to add to repository's because of there design, on the other hand the obs api should make adding it to whatever software.o.o becomes not too hard.

On 18/03/2022 18.42, Sy retia wrote:

I assume you're talking about 1-click installs here? I think this is more of a problem with yast-metapackage-handler. It should be checking if the repositories are compatible with the release the user is on

It is already possible to have a single .ymp file for multiple openSUSE versions and the metapackage-handler picks the correct one based on the current release. For an example, see my generator output at http://multiymp.zq1.de/?base=games&pkg=openarena

On Di, Mär 22 2022 at 09:51:40 +0000, Lubos Kocman lubos.kocman@suse.com wrote:

Hello Sasi,

I think there are in general two problems. We don't have many volunteers for ruby runtime (not sure if it's the code-base or set of technologies).

And then we break systems with current repo enablement, we want to free the forum from half-upgraded Leap/Tumbleweed systems.

That's fairly easy to fix though, don't allow to install the things from default repos with ymp, show an appstream button for desktops and zypper command for everyone who doesn't have a store that handles those links.

I think whoever first announces "This is what I have and it works" and we can see if that would be viable direction wins. I'd love personally if that direction could help us decide what particular devel/home/project to choose. So some sort of stats / thumbs up would be very helpful.

I'd love to see OPI utilization as people generally seem to like it, or at least the people that I regularly speak to.

I don't really see in what way opi is useful within software-o-o. It replaces software-o-o functionality in cli, so it feels like an alternative rather than a thing to integrate within software-o-o.

On the other side, fixing current codebase would help as well as long as we can find active maintainers :-)

What is the guarantee the next stack chosen will be in a better position than the current one? There are plenty of rubists and rails developers in openSUSE, which didn't stop the codebase from becoming stale overtime.

LCP [Sasi] https://lcp.world/

On Tue, 22 Mar 2022, at 11:21, Sasi Olin wrote:

On Di, Mär 22 2022 at 09:51:40 +0000, Lubos Kocman lubos.kocman@suse.com wrote:

...

Hello Sasi,

I think there are in general two problems. We don't have many volunteers for ruby runtime (not sure if it's the code-base or set of technologies).

And then we break systems with current repo enablement, we want to free the forum from half-upgraded Leap/Tumbleweed systems.

That's fairly easy to fix though, don't allow to install the things from default repos with ymp, show an appstream button for desktops and zypper command for everyone who doesn't have a store that handles those links.

...

I think whoever first announces "This is what I have and it works" and we can see if that would be viable direction wins. I'd love personally if that direction could help us decide what particular devel/home/project to choose. So some sort of stats / thumbs up would be very helpful.

I'd love to see OPI utilization as people generally seem to like it, or at least the people that I regularly speak to.

I don't really see in what way opi is useful within software-o-o. It replaces software-o-o functionality in cli, so it feels like an alternative rather than a thing to integrate within software-o-o.

opi was not meant as something within software-o-o, but as an option to look at because opi does work with the Leap 15.3/15.4 repos that software-o-o doesn't show. So what ever fix was included there might work for software-o-o too.

...

On the other side, fixing current codebase would help as well as long as we can find active maintainers :-)

What is the guarantee the next stack chosen will be in a better position than the current one? There are plenty of rubists and rails developers in openSUSE, which didn't stop the codebase from becoming stale overtime.

LCP [Sasi] https://lcp.world/

Hi,

have a look here: https://github.com/openSUSE/opi/blob/master/bin/opi https://github.com/openSUSE/opi/blob/master/opi/__init__.py

Most magic happens here: https://github.com/openSUSE/opi/blob/master/opi/__init__.py#L158 and here: https://github.com/openSUSE/opi/blob/master/opi/__init__.py#L39

Regards, Dominik

Am 22.03.22 um 12:39 schrieb Syds Bearda:

On Tue, 22 Mar 2022, at 11:21, Sasi Olin wrote:

...

On Di, Mär 22 2022 at 09:51:40 +0000, Lubos Kocman lubos.kocman@suse.com wrote:

...

Hello Sasi,

I think there are in general two problems. We don't have many volunteers for ruby runtime (not sure if it's the code-base or set of technologies).

And then we break systems with current repo enablement, we want to free the forum from half-upgraded Leap/Tumbleweed systems.

That's fairly easy to fix though, don't allow to install the things from default repos with ymp, show an appstream button for desktops and zypper command for everyone who doesn't have a store that handles those links.

...

I think whoever first announces "This is what I have and it works" and we can see if that would be viable direction wins. I'd love personally if that direction could help us decide what particular devel/home/project to choose. So some sort of stats / thumbs up would be very helpful.

I'd love to see OPI utilization as people generally seem to like it, or at least the people that I regularly speak to.

I don't really see in what way opi is useful within software-o-o. It replaces software-o-o functionality in cli, so it feels like an alternative rather than a thing to integrate within software-o-o.

opi was not meant as something within software-o-o, but as an option to look at because opi does work with the Leap 15.3/15.4 repos that software-o-o doesn't show. So what ever fix was included there might work for software-o-o too.

...

...

On the other side, fixing current codebase would help as well as long as we can find active maintainers :-)

What is the guarantee the next stack chosen will be in a better position than the current one? There are plenty of rubists and rails developers in openSUSE, which didn't stop the codebase from becoming stale overtime.

LCP [Sasi] https://lcp.world/

On 3/22/22 21:51, Sasi Olin wrote:

On Di, Mär 22 2022 at 09:51:40 +0000, Lubos Kocman lubos.kocman@suse.com wrote:

...

Hello Sasi,

What is the guarantee the next stack chosen will be in a better position than the current one? There are plenty of rubists and rails developers in openSUSE, which didn't stop the codebase from becoming stale overtime.

I think one of the issues we have here is tools like software.opensuse.org are less useful to our usual set of developers because we tend to use build.o.o, our own set of devel repos or just get the packages we care about into the distros we care about.

So maybe we really need to find a new group of users that use software.o.o and are also interested in web development as always how we do that is the much harder question.

On Wed, 2022-03-23 at 12:32 +0100, Henne Vogelsang wrote:

Hey,

On 23.03.22 11:59, Simon Lees wrote:

...

So maybe we really need to find a new group of users that use software.o.o

You don't have to be sick to be a Doctor...

...

and are also interested in web development as always how we do that is the much harder question.

Attracting new contributors is the *first* and *foremost* duty of the openSUSE project. For the distribution, the project *AND* for the infrastructure. We *have* to have an answer for this question.

If we continue to neglect this, openSUSE is going to go the way of the Dodo. Faster than you can say "preinstalled operating system" 3 times in a row.

Right, but Simon's point is valid. Contributors won't be attracted by having to code an UI that they're unlikely to need / use themselves. It's not the sexiest possible project either, because dozens of similar frameworks exist already, just not targeted at OBS as backend.

Moreover, casual contributors would most probably fail at this project. The basic technical part - connecting to the OBS API - is simple enough. But the difficult part - the one at which software.o.o is currently failing [*] - is to figure out which repositories matter for which distribution, a task that sometimes confuses even long time human openSUSE users. I'm not even sure if this could be reliably figured out from OBS in software without a hard-coded and ever-growing list of exceptions and special cases.

IMO SUSE as openSUSE's sponsor should push this forward somehow. This is not a project to try to attract contributors for, it's a feature that must work in order to attract contributors for other tasks.

Martin

[*] As we know, s.o.o fails almost consistently for Leap 15.3.

On Wed, 2022-03-23 at 13:43 +0000, Nicolas Formichella wrote:

First of all, a very basic regex check of the URL, most repos have distinct URLs that expose their distro (like for ex. Emulators with https://download.opensuse.org/repositories/Emulators/openSUSE_Tumbleweed/ ) would immediately ease that process

For all other repos that don't (i.e Kernel), IMO, outside of normalizing a format for those URLs, I don't have any idea idea about that

I was talking about something else: current s.o.o frequently finds _nothing_ when you search software for Leap 15.3. It isn't as bad as messing up your system, but it's disappointing and frustrating nonetheless.

Regards Martin

On Wed, 2022-03-23 at 15:17 +0100, Richard Biener wrote:

On Wed, 23 Mar 2022, Martin Wilck wrote:

...

On Wed, 2022-03-23 at 13:43 +0000, Nicolas Formichella wrote:

...

First of all, a very basic regex check of the URL, most repos have distinct URLs that expose their distro (like for ex. Emulators with https://download.opensuse.org/repositories/Emulators/openSUSE_Tumbleweed/ ) would immediately ease that process

For all other repos that don't (i.e Kernel), IMO, outside of normalizing a format for those URLs, I don't have any idea idea about that

I was talking about something else: current s.o.o frequently finds _nothing_ when you search software for Leap 15.3. It isn't as bad as messing up your system, but it's disappointing and frustrating nonetheless.

So there is packagehub.suse.com that in some sense targets Leap, is it possible to at least build on its codebase? Does it even do a good (better) job than software.o.o?

packagehub.suse.com is a static website that is more or less a specialized webview of information contained in repodata. It currently only indexes the openSUSE:Backports:SLE-* repositories. So not 100% of Leap. It serves a different purpose than software.o.o, and I don't believe it's something to build on.

-Scott

Am 23. März 2022 15:17:51 MEZ schrieb Richard Biener rguenther@suse.de:

On Wed, 23 Mar 2022, Martin Wilck wrote:

...

On Wed, 2022-03-23 at 13:43 +0000, Nicolas Formichella wrote:

...

First of all, a very basic regex check of the URL, most repos have distinct URLs that expose their distro (like for ex. Emulators with https://download.opensuse.org/repositories/Emulators/openSUSE_Tumbleweed/ ) would immediately ease that process

For all other repos that don't (i.e Kernel), IMO, outside of normalizing a format for those URLs, I don't have any idea idea about that

I was talking about something else: current s.o.o frequently finds _nothing_ when you search software for Leap 15.3. It isn't as bad as messing up your system, but it's disappointing and frustrating nonetheless.

The reason is, that s.o.o only search for repos named 15.3 or 15.4. S.o.o does not search in repos which named openSUSE_Leap_15.3 or openSUSE_Leap_15.4 Why this not can be fixed, I don't understand.

Regards Eric

Am Freitag, 25. März 2022, 00:56:39 CET schrieb Simon Lees:

...

The reason is, that s.o.o only search for repos named 15.3 or 15.4. S.o.o does not search in repos which named openSUSE_Leap_15.3 or openSUSE_Leap_15.4 Why this not can be fixed, I don't understand.

Most 15.3 repos were still openSUSE_Leap_15.3 at some point so that's not the only issue, It should probably also look for the relevant backports, without looking at the code searching three results and aggregating them may not be a simple change.

I tested it in my repos and the result was what I described.

The other major issue is that the repo structure for the official repos is also completely different as its split between packages from SLE and Non SLE packages so that also needs to be resolved because we shouldn't be pointing people to 3rd party repos when there are official packages (In my opinion we probably shouldn't be sending them to non official repos at all which is why my interest in making this better is pretty low we should either officially offer stuff or not at all but i'm sure theres plenty of people who disagree with me).

In my opinion, all results should be displayed. Whether official or not. This was also the case before 15.3. And you should let the user decide what he wants.

Regards Eric

On 3/26/22 02:36, Martin Wilck wrote:

On Fri, 2022-03-25 at 17:03 +0100, Eric Schirra wrote:

...

In my opinion, all results should be displayed. Whether official or not. This was also the case before 15.3. And you should let the user decide what he wants.

Ack. Hiding the non-official repos would make the tool essentially useless. With just official repos, it couldn't do much more than "zypper search" + "zypper install" would be able to achieve.

Yeah I guess that's part of my point, if as a project we decide that we don't want to push 3rd party repo's then maybe we don't really need a tool like software.o.o, sure it's nice to have but the project won't fall apart and won't be less useable without it.

If people actually want it then they can work on it but maybe the better question is what packages are "general users" rather then "power users" actually using from 3rd party repos and can we get those into the distros they use so they don't actually need the tool.

On 3/26/22 19:10, Eric Schirra wrote:

Am 26. März 2022 09:03:32 MEZ schrieb Simon Lees sflees@suse.de:

...

On 3/26/22 02:36, Martin Wilck wrote:

...

On Fri, 2022-03-25 at 17:03 +0100, Eric Schirra wrote:

...

In my opinion, all results should be displayed. Whether official or not. This was also the case before 15.3. And you should let the user decide what he wants.

Ack. Hiding the non-official repos would make the tool essentially useless. With just official repos, it couldn't do much more than "zypper search" + "zypper install" would be able to achieve.

Yeah I guess that's part of my point, if as a project we decide that we don't want to push 3rd party repo's then maybe we don't really need a tool like software.o.o, sure it's nice to have but the project won't fall apart and won't be less useable without it.

Not WE don't want. YOU don't want.

Third party was Show since very long time.

Are Devel repos third-party ,too? Without this also s.o.o not useless.

Yes, any repo that has packages that haven't been reviewed by the review team and gone through our checkers are not considered official packages which frequently includes code in devel repos even though it will be reviewed later.

Devel repos are designed to be used by developers not users and as such you have no indication whether they are intended to be used by users or if they may break things.

We need a tool to search for packages, so we can add repos we need. Without s.o.o I can not find such repo.

build.opensuse.org contains a search and all info you need to add the right repo yes its slightly less friendly

...

If people actually want it then they can work on it but maybe the better question is what packages are "general users" rather then "power users" actually using from 3rd party repos and can we get those into the distros they use so they don't actually need the tool.

S.o.o is the first place to search for software.

No zypper and Yast should be they both list all the software that we as a project officially support. Even adding a devel project may break a users system if not done right especially for certain devel projects. If users add a package without adding a devel project then it will never be updated so we simply can't support users who do this, they do it at there own risk so if its slightly harder to do thats not the end of the world.

Really if we don't have packages people need in the main repo's thats something we should fix by adding them there, unlike some other distro's the restrictions to get packages into openSUSE are pretty light so generally there is no reason why a package couldn't end up in the distro.

On Sat, 2022-03-26 at 18:33 +1030, Simon Lees wrote:

...

Ack. Hiding the non-official repos would make the tool essentially useless. With just official repos, it couldn't do much more than "zypper search" + "zypper install" would be able to achieve.

Yeah I guess that's part of my point, if as a project we decide that we don't want to push 3rd party repo's then maybe we don't really need a tool like software.o.o, sure it's nice to have but the project won't fall apart and won't be less useable without it.

I disagree. In my experience, Leap needs 3rd party repos to be usable for anything but basic tasks. I don't think I've ever used Leap on any system for more than a few months without needing 3rd party repos at least temporarily.

If people actually want it then they can work on it but maybe the better question is what packages are "general users" rather then "power users" actually using from 3rd party repos and can we get those into the distros they use so they don't actually need the tool.

Power users don't need software.o.o. They can use osc or whatever else, use containers, or just build and install locally. We need this exactly for those "general users". Users have highly diverse interests. It's naïve to believe that Leap's default package selection would satisfy them all.

I suppose Flatpak et al. can partly fill the gap (forgetting for a moment that Flatpak users tend to receive discouraging comments in the openSUSE community). But 3rd party repos are not just for non-standard applications. They may be required for updates of packages we deliver, or even bug fixes. If you have a bug that prevents you from working, more often than not you'd rather install an update package from a home project that fixes the bug than wait until the bug fix passes the maintenance queue.

Martin

Am Montag, 28. März 2022, 16:38:33 CEST schrieb Martin Wilck:

...

Yeah I guess that's part of my point, if as a project we decide that we don't want to push 3rd party repo's then maybe we don't really need a tool like software.o.o, sure it's nice to have but the project won't fall apart and won't be less useable without it.

I disagree. In my experience, Leap needs 3rd party repos to be usable for anything but basic tasks. I don't think I've ever used Leap on any system for more than a few months without needing 3rd party repos at least temporarily.

Exactly my opinion. Without the 3Partys home and devel openSUSE is not usable. The official repos simply lack far too much software. There other Distris offer a lot more software.

...

If people actually want it then they can work on it but maybe the better question is what packages are "general users" rather then "power users" actually using from 3rd party repos and can we get those into the distros they use so they don't actually need the tool.

Power users don't need software.o.o. They can use osc or whatever else, use containers, or just build and install locally. We need this exactly for those "general users". Users have highly diverse interests. It's naïve to believe that Leap's default package selection would satisfy them all.

osc is for building packages. But not to search/install software. The standard package selection of Leap is clearly too small.

I suppose Flatpak et al. can partly fill the gap (forgetting for a moment that Flatpak users tend to receive discouraging comments in the openSUSE community). But 3rd party repos are not just for non-standard applications. They may be required for updates of packages we deliver, or even bug fixes. If you have a bug that prevents you from working, more often than not you'd rather install an update package from a home project that fixes the bug than wait until the bug fix passes the maintenance queue.

Flatpack should be the exception. Is also always depicted too. Why should I take flatpacks when I can build normal packages? Are flatpacks supposed to be safer? Nobody believes that here.

Regards Eric

On Mon, 2022-03-28 at 17:17 +0200, Eric Schirra wrote:

osc is for building packages. But not to search/install software.

Well, there's "osc repourls", "osc getbinaries", and various other commands to operate on binary packages and repositories. Developers use this all the time. But it's only useful for developers.

Martin

On Mon, 2022-03-28 at 17:17 +0200, Eric Schirra wrote:

Flatpack should be the exception. Is also always depicted too. Why should I take flatpacks when I can build normal packages? Are flatpacks supposed to be safer? Nobody believes that here.

This is getting OT, and it's my fault. For a variety of reasons, there are applications that are available as flatpak / appimage / snap only. We should face this fact and try to make the best out of it, as Ubuntu and Fedora have done a long time ago, rather than repeating that these packages are evil.

Moreover (and that's really _not_ OT) Flatpak has nice and modern UIs, both locally and on the web, to search for applications, and these UIs actually work. Face it, if you look for something out-of-the-ordinary, searching it on flathub is quicker and more comfortable than anything openSUSE currently offers (except GNOME software :-).

Martin

Hi Martin

thats a good point. At Holarse we try to collect all the links to games as well. Therefore we collect AppImage, Flatpak and Snap-links too.

AppImages are often direct links, ideally to a Github-Repo-Download. But these links only work for a certain version.

Flatpaks have a specific package urls, which don't outdate. Snaps as well.

Beside AppImage Snap and Flat are just packages in a new incompatible package format (beside rpm and deb). Just my two evil cents ;-)

Integration into KDE Discover and GNOME Software are probably a nice feature. Especially as openSUSE already installs these programs. Therefore we should integrate them as good as possible.

Cheers, Bernd

PS: Is there a special discord channel or irc channel where one can meet other possible contributors to this project?

Am 28.03.22 um 18:39 schrieb Martin Wilck:

On Mon, 2022-03-28 at 17:17 +0200, Eric Schirra wrote:

...

Flatpack should be the exception. Is also always depicted too. Why should I take flatpacks when I can build normal packages? Are flatpacks supposed to be safer? Nobody believes that here.

This is getting OT, and it's my fault. For a variety of reasons, there are applications that are available as flatpak / appimage / snap only. We should face this fact and try to make the best out of it, as Ubuntu and Fedora have done a long time ago, rather than repeating that these packages are evil.

Moreover (and that's really _not_ OT) Flatpak has nice and modern UIs, both locally and on the web, to search for applications, and these UIs actually work. Face it, if you look for something out-of-the-ordinary, searching it on flathub is quicker and more comfortable than anything openSUSE currently offers (except GNOME software :-).

Martin

On Mon, 2022-03-28 at 16:38 +0200, Martin Wilck wrote:

On Sat, 2022-03-26 at 18:33 +1030, Simon Lees wrote:

...

...

Ack. Hiding the non-official repos would make the tool essentially useless. With just official repos, it couldn't do much more than "zypper search" + "zypper install" would be able to achieve.

Yeah I guess that's part of my point, if as a project we decide that we don't want to push 3rd party repo's then maybe we don't really need a tool like software.o.o, sure it's nice to have but the project won't fall apart and won't be less useable without it.

I disagree. In my experience, Leap needs 3rd party repos to be usable for anything but basic tasks. I don't think I've ever used Leap on any system for more than a few months without needing 3rd party repos at least temporarily.

I agree, but this deficiency of Leap should not be addressed by encoraging people to use untested, unreviewed, unmaintained, unsupported, unsupportable software.

We shouldn't be pushing people to 3rd party repos, Period.

On Mon, 2022-03-28 at 18:53 +0200, Stefan Seyfried wrote:

On 28.03.22 18:50, Richard Brown wrote:

...

I agree, but this deficiency of Leap should not be addressed by encoraging people to use untested, unreviewed, unmaintained, unsupported, unsupportable software.

We shouldn't be pushing people to 3rd party repos, Period.

OK, so we should advise them to "configure; make; sudo make install" instead?

No, my advice would be not to use Leap, but that's totally getting off topic.

Back to the topic at hand though, if discovering 3rd party software from software.opensuse.org is essential for Leap to be useful, that's a problem that needs to be addressed in Leap, not software.opensuse.org

On Mo, Mär 28 2022 at 20:07:42 +0200, Martin Wilck mwilck@suse.com wrote:

On Mon, 2022-03-28 at 18:56 +0200, Richard Brown wrote:

...

On Mon, 2022-03-28 at 18:53 +0200, Stefan Seyfried wrote:

...

On 28.03.22 18:50, Richard Brown wrote:

...

I agree, but this deficiency of Leap should not be addressed by encoraging people to use untested, unreviewed, unmaintained, unsupported, unsupportable software.

I find this statement disrespectful against everyone who maintains software in inofficial repos. Almost all packages in openSUSE started out in home projects and passed through a devel project before eventually being added to the distro. At the end of the day, the quality difference between official and inofficial packages is not as huge as you imply.

Of course, when you activate someone's home repo, you don't know. The repo owner may be long gone or be a malicious jerk. So no, we shouldn't actively encourage it. But we shouldn't discourage it, either, because we'd be discouraging our distribution as such.

Perhaps some weak "review" process could be established around public, inofficial OBS repositories. For example, a bot could auto-uncheck the "publish" flag for repos that haven't seen any updates for a long time, and users setting the "publish" flag could be asked to provide meaningful descriptions for their repos and the packages therein.

From software-o-o side, we could make it so that to actually have the package show up in the search on the site, the maintainer of the package would have to agree to it, with a reminder every 3ish months, that way users wouldn't have the option to install my experiment on removing half of the source code of grub and seeing if it still works fine on TW.

At that point though, I really don't understand why people wouldn't just submit the package to Factory if they have to go through that process. This is kind of the reason why during oSC19, when discussing software-o-o, we decided it would be best to notify the maintainers their software is popular and that it would be great to have it be a part of the main repositories. Realistically for openSUSE, it would be far better if we all focused our attention on maintaining some common resource, instead of spreading the work across a lot of different places.

LCP [Sasi] https://lcp.world/

On Mo, Mär 28 2022 at 20:52:52 +0200, Vojtěch Zeisek vojtech.zeisek@opensuse.org wrote:

Dne pondělí 28. března 2022 20:28:41 CEST, Sasi Olin napsal(a):

...

At that point though, I really don't understand why people wouldn't just submit the package to Factory

Well... I don't think submission to Factory is so simple and straightforward, i.e. there might be obstacles for users with lower expertise, so they "just" keep their work in their home projects. It's for other discussion, bit OT here, sorry, and IMHO, even if everything would be in Factory, it doesn't mean s.o.o is unneeded.

This is a pretty important thing to discuss in general though. Factory is the gateway for all the packages in openSUSE distros as well as SLE and derivatives. Factory submission process is the only way for those to be able to grow, and if we are unable to attract even novice maintainers to be able to do it, there is no way for the openSUSE Project to continue existing past the current generation of maintainers.

LCP [Sasi] https://lcp.world/

On 28.03.22 20:28, Sasi Olin wrote:

At that point though, I really don't understand why people wouldn't just submit the package to Factory if they have to go through that process.

I have actively removed packages from Factory and thus future Leap because I was no longer willing to waste work on working around bugs of stupid bots enforcing even more stupid rules on changelogs (to just pick one of the rules).

Those packages live on happily ever after in a "devel project" and apparently still have their users, at least the bug reports I'm getting suggest that.

Getting stuff into / keeping stuff in Factory is not as painless as some might suggest here.

(And yes, I remember the argument that these rules were all about quality management and about the poor guy who will have to fix the package in SLES 42 years from now and thus needs some sort of machine-parsable changelog or such. But nobody could show me any quality complaint about the packages in question and besides that it was never in SLES anyway.)

On Mon, 2022-03-28 at 20:31 +0200, toganm@dinamizm.com wrote:

...

...

...

...

And why would we want to police the developers in their choice of providing or not providing a meaningful, according to who, description.

Because public repositories are for users, not developers.

Martin

On Montag, 28. März 2022 20:07:42 CEST Martin Wilck wrote:

On Mon, 2022-03-28 at 18:56 +0200, Richard Brown wrote:

...

On Mon, 2022-03-28 at 18:53 +0200, Stefan Seyfried wrote:

...

On 28.03.22 18:50, Richard Brown wrote:

...

I agree, but this deficiency of Leap should not be addressed by encoraging people to use untested, unreviewed, unmaintained, unsupported, unsupportable software.

I find this statement disrespectful against everyone who maintains software in inofficial repos. Almost all packages in openSUSE started out in home projects and passed through a devel project before eventually being added to the distro. At the end of the day, the quality difference between official and inofficial packages is not as huge as you imply.

The important part is "*started* out home projects". If a package is actually in a good state, there is no reason it can not be forwarded to a devel project and to Factory.

I maintain a lot of packages, and I would not recommend anyone to use the work-in-progress from my home repositories. I use packages from devel projects for testing only, and only because I know what I am doing.

Of course, when you activate someone's home repo, you don't know. The repo owner may be long gone or be a malicious jerk. So no, we shouldn't actively encourage it. But we shouldn't discourage it, either, because we'd be discouraging our distribution as such.

Perhaps some weak "review" process could be established around public, inofficial OBS repositories. For example, a bot could auto-uncheck the "publish" flag for repos that haven't seen any updates for a long time, and users setting the "publish" flag could be asked to provide meaningful descriptions for their repos and the packages therein.

And who will do the review? And if someone does the review and it passes, why not let *everyone* use the result in a straight forward way, and push it to Factory?

...

...

...

We shouldn't be pushing people to 3rd party repos, Period.

OK, so we should advise them to "configure; make; sudo make install" instead?

No, my advice would be not to use Leap, but that's totally getting off topic.

and use ... what? Factory also needs 3rd party repos. Not as strongly as Leap, but it still does. Not to mention that Factory has other disadvantages that simply don't make it suitable for everyone.

Does Factory really need 3rd party repos? I can definitely work without any.

For Leap, the picture unfortunately is a different one. It misses quite some packages, but this is for a large part caused by its quite old core. Many upstream projects have dropped support for GCC 4.7 and Python 3.6 (to name just the biggest two elephants, but there are plenty), and providing up-to- date packages for Leap 15.3/15.4 has become quite hard.

Despite all the hard work done by many contributors, Leap 15.4 is quite old even on its coming release. From a 15.3 perspective it may look good, but from a TW perspective it feels like stone age. IMHO Leap would be in a much better shape if it were Leap 16.0 - but this will probably take another year ...

Btw, the discussion is not OT as long as people claim that simply

ditching s.o.o was a step in the right direction:

...

Back to the topic at hand though, if discovering 3rd party software from software.opensuse.org is essential for Leap to be useful, that's a problem that needs to be addressed in Leap, not software.opensuse.org

Looking forward to your suggestions how to do that.

1. streamline the Leap submission/upgrade process 2. rebase the core more frequently

Updating packages in Leap still takes too much effort. For Factory, the process is trivial, update in the devel project, forward, done. For Leap, one first has to find the right target project (Leap vs SLE package). If the Factory package is too new (5 years of changes is not uncommon), one has to find a version which is sufficient, but does not break SLE/Leap. Then after a few months someone may act on the MR. And then you notice the update deadline has passed, the dependencies are updated, but you have no chance of updating the leaf package you wanted to update. Been there, done that.

I don't like Ubuntu, but its core is updated every two years, and that *is* the reference for many upstream projects. When Leap 15.4 is released, people will compare it with Ubuntu 22.04 LTS, and that will be quite unfavorable for 15.4. Upstream projects will mostly target 20.04/22.04 LTS, and the dependencies from Leap 15.4 will not suffice.

Kind regards,

Stefan

On Mon, 2022-03-28 at 21:43 +0200, Stefan Brüns wrote:

I maintain a lot of packages, and I would not recommend anyone to use the work-in-progress from my home repositories. I use packages from devel projects for testing only, and only because I know what I am doing.

You wouldn't set the "publish" flag on these repos that you wouldn't recommend, right? If someone sets this flag, it should be for a purpose.

...

Of course, when you activate someone's home repo, you don't know. The repo owner may be long gone or be a malicious jerk. So no, we shouldn't actively encourage it. But we shouldn't discourage it, either, because we'd be discouraging our distribution as such.

Perhaps some weak "review" process could be established around public, inofficial OBS repositories. For example, a bot could auto-uncheck the "publish" flag for repos that haven't seen any updates for a long time, and users setting the "publish" flag could be asked to provide meaningful descriptions for their repos and the packages therein.

And who will do the review? And if someone does the review and it passes, why not let *everyone* use the result in a straight forward way, and push it to Factory?

The submission and review process and its bots aren't everybody's best friends. Going into details would be really OT...

Some applications and libraries may be so special that they simply don't need to be part of the core distro. Every package causes metadata to need to be downloaded and updated, dependencies to be calculated, etc. I'd rather ask the opposite question: why insist on everything going through one big monolith?

Does Factory really need 3rd party repos? I can definitely work without any.

I hardly ever delete repositories I had once configured. I only disable them. Indeed, the only repo I have currently enabled besides the official ones is google-chrome. But I have no less than 46 disabled repos on my 6y-old TW installation. Some are debug repos, many of them are my own. Another large part consists of devel projects. And some are from other people's home projects.

Martin

On 3/29/22 08:41, Stefan Seyfried wrote:

On 28.03.22 23:46, Martin Wilck wrote:

...

On Mon, 2022-03-28 at 21:43 +0200, Stefan Brüns wrote:

...

I maintain a lot of packages, and I would not recommend anyone to use the work-in-progress from my home repositories. I use packages from devel projects for testing only, and only because I know what I am doing.

You wouldn't set the "publish" flag on these repos that you wouldn't recommend, right? If someone sets this flag, it should be for a purpose.

If I do not set the publish flag, it's almost impossible for me to test that stuff myself.

But the description of e.g. home:seife:testing contains a warning for the users :-)

Yeah I also have publishing enabled on all my test repos, some are well named others less well so. But once your working with multiple packages together the only sane way to test such things is to enable publishing add the repo to a VM and test from there.

On 3/29/22 20:40, Martin Wilck wrote:

On Tue, 2022-03-29 at 10:49 +1030, Simon Lees wrote:

...

...

If I do not set the publish flag, it's almost impossible for me to test that stuff myself.

But the description of e.g. home:seife:testing contains a warning for the users :-)

Yeah I also have publishing enabled on all my test repos, some are well named others less well so. But once your working with multiple packages together the only sane way to test such things is to enable publishing add the repo to a VM and test from there.

Looks like a missing feature to me. Perhaps we should be able to distinguish between "public" repos that are meant for the public (and should be included by opi, s.o.o, and whatnot), and repos that just need to be made available to the developer himself in a fashion that facilitates testing.

Currently this is simple "Public" repos start with either.

https://download.opensuse.org/distribution/ https://download.opensuse.org/tumbleweed/

And anything under https://download.opensuse.org/repositories/

Is not yet an official part of an openSUSE "product" and should be used with upmost caution.

If what we are trying to address is mostly old packages in Leap maybe we should look at a similar approach to package hub (not the same) rather then pointing people to devel projects. For example before a package can be accepted into package hub we run checkers to make sure it wont conflict with or break packages that come from SLE.

Maybe we could take this idea further and if I wanted to provide the latest version of fish or enlightenment (examples because I maintain them) for fish its an individual packge so maybe it could go into a common repo if it passes our basic checks. Enlightenment on the other hand requires a group of packages so maybe there should be a separate repo with just those packages people can add should they want them. You could probably even do something similar with kernels.

Where it gets much harder is there was a number of packages that couldn't be updated in Leap 15.3 because Qt was too old. So do you add a new version of Qt to a repo (or multiple) and hope that there backwards compatibility promises work right and it doesn't introduce new bugs. Atleast with this kind of setup you could add those packages then run the KDE openqa test suites and have some idea of the answers. But then I guess the other question here is how far should you go with this because if you took this idea to its extremes you basically just end up with tumbleweed.

The other issue here is while something like this is probably a much better solution its probably also a large amount of work for a someone or group of someones and we'd have to find them somewhere. But on the plus side we'd no longer end up with cases where users click a one click install and end up with the wrong python on there system and everything broken (Yes this has happened plenty of times in the past). So until we have an actual proper solution as a project we should just be recommending the official repos at the same time if 3rd parties recommend 3rd party repos there isn't alot more we can do.

On Montag, 28. März 2022 23:46:45 CEST Martin Wilck wrote:

On Mon, 2022-03-28 at 21:43 +0200, Stefan Brüns wrote:

...

I maintain a lot of packages, and I would not recommend anyone to use the work-in-progress from my home repositories. I use packages from devel projects for testing only, and only because I know what I am doing.

You wouldn't set the "publish" flag on these repos that you wouldn't recommend, right? If someone sets this flag, it should be for a purpose.

...

...

Of course, when you activate someone's home repo, you don't know. The repo owner may be long gone or be a malicious jerk. So no, we shouldn't actively encourage it. But we shouldn't discourage it, either, because we'd be discouraging our distribution as such.

Perhaps some weak "review" process could be established around public, inofficial OBS repositories. For example, a bot could auto-uncheck the "publish" flag for repos that haven't seen any updates for a long time, and users setting the "publish" flag could be asked to provide meaningful descriptions for their repos and the packages therein.

And who will do the review? And if someone does the review and it passes, why not let *everyone* use the result in a straight forward way, and push it to Factory?

The submission and review process and its bots aren't everybody's best friends. Going into details would be really OT...

Some applications and libraries may be so special that they simply don't need to be part of the core distro. Every package causes metadata to need to be downloaded and updated, dependencies to be calculated, etc. I'd rather ask the opposite question: why insist on everything going through one big monolith?

Everything that is not part of TWs Ring:1 does not need to be part of the core distro. Everything else is a matter of taste and need.

Even on an RPi3 dependencies are not a problem, and that is probably the lower end for openSUSE.

For many devel projects, most or even all packages are also part of the distribution proper, so you download this metadata twice when you add the devel project.

The origins of dependencies have to form a directed acyclic graph. When you have the same package in multiple projects, you are asking for trouble. You can achieve proper dependencies by layering, like done for SLE/Leap, or you put everything in one repository. Even with layering, you have to be careful because you have to synchronize metadata updates over the whole tree (typical example is breakage due to Packman being late).

...

Does Factory really need 3rd party repos? I can definitely work without any.

I hardly ever delete repositories I had once configured. I only disable them. Indeed, the only repo I have currently enabled besides the official ones is google-chrome. But I have no less than 46 disabled repos on my 6y-old TW installation. Some are debug repos, many of them are my own. Another large part consists of devel projects. And some are from other people's home projects.

So apparently also for you the answer is "no" (proprietary packages are obviously a corner case openSUSE can not provide in its main repo).

The disabled repositories actually proves the point. You needed these for very specific scenarios, but you no longer need them. But you are also a user with sufficient technical background to handle this - definitely not the case for the average user.

Kind regards, Stefan

On 28.03.22 21:43, Stefan Brüns wrote:

And who will do the review? And if someone does the review and it passes, why not let *everyone* use the result in a straight forward way, and push it to Factory?

There are additional costs of getting things into Factory not everyone is willing to pay.

Does Factory really need 3rd party repos? I can definitely work without any.

strolchi:~ # zypper info Arduino arduino-core Loading repository data... Reading installed packages...

Information for package Arduino: -------------------------------- Repository : cross-avr Name : Arduino Version : 1.8.19-2.3 Arch : x86_64 Vendor : obs://build.opensuse.org/CrossToolchain:avr

[...]

Information for package arduino-core: ------------------------------------- Repository : cross-avr Name : arduino-core Version : 1.8.3-2.90 Arch : x86_64 Vendor : obs://build.opensuse.org/CrossToolchain:avr [...]

Just one example. And while I have been helping keeping this up to date, I'm clearly not going to maintain this for Factory or Leap.

Updating packages in Leap still takes too much effort. For Factory, the process is trivial, update in the devel project, forward,

... have it rejected immediately by stupid bots ;-)

On Mon, 2022-03-28 at 20:07 +0200, Martin Wilck wrote:

On Mon, 2022-03-28 at 18:56 +0200, Richard Brown wrote:

...

On Mon, 2022-03-28 at 18:53 +0200, Stefan Seyfried wrote:

...

On 28.03.22 18:50, Richard Brown wrote:

...

I agree, but this deficiency of Leap should not be addressed by encoraging people to use untested, unreviewed, unmaintained, unsupported, unsupportable software.

I find this statement disrespectful against everyone who maintains software in inofficial repos. Almost all packages in openSUSE started out in home projects and passed through a devel project before eventually being added to the distro. At the end of the day, the quality difference between official and inofficial packages is not as huge as you imply.

Why oh why, if, as you imply the difference is not as huge and consequently the effort required to push an app from random home repo to official Leap/TW repo is low, is the app not in any of the official repos? As someone who regularly submits packages to TW, and am deeply appreciative of the additional reviews that that entails, I have no idea why one would instead make these random, untested home (or even devel) repos even close to semi-official by recommending them from s.o.o or any o.o.

Even if for some reason a packager does not want their home package to end up in the official repos, there are other ways to "advertise" their packages. For example, I package bleeding edge releases of the app xournalpp on my home repo, and I pointed upstream [1] to these. They were happy and quick to set up links to my prj from their GitHub page.

Alternatively, a packager can write a blog highlighting their home project that they think may serve the end user. They could highlight the "zypper ar <URL>; zypper in -r <repo_name>" similar to how ppa's are advertised for unofficial Debian packages. Such blogs may even be carried on news.o.o I suppose.

Pending any effort from the packager towards any of these options, you should assume the packages in their home repos are not recommended for installation on any system and certainly should not be advertised at all from any o.o pages, in my opinion. Furthermore, one should stray far far away from any one click shopping from such repos.

So, I would recommend shutting down s.o.o without replacement.

Of course, when you activate someone's home repo, you don't know. The repo owner may be long gone or be a malicious jerk. So no, we shouldn't actively encourage it. But we shouldn't discourage it, either, because we'd be discouraging our distribution as such.

As a distro, we should of course discourage the installation of un- reviewed apps that easily carry the potential of breaking users' systems or worse. That nothing untowardly has happened so far does not mean it cannot in the future, and the distro should wash its hands off it asap.

Perhaps some weak "review" process could be established around public, inofficial OBS repositories. For example, a bot could auto-uncheck the "publish" flag for repos that haven't seen any updates for a long time, and users setting the "publish" flag could be asked to provide meaningful descriptions for their repos and the packages therein.

To what end? I think you will find that a significant majority of packagers willing to do this distance already submit their apps to Factory or advertise these in some other way.

...

...

...

We shouldn't be pushing people to 3rd party repos, Period.

OK, so we should advise them to "configure; make; sudo make install" instead?

Of course, the user may of their own accord do whatever they want with their system. That is not for the distro to recommend or even suggest weakly.

...

No, my advice would be not to use Leap, but that's totally getting off topic.

and use ... what? Factory also needs 3rd party repos. Not as strongly as Leap, but it still does. Not to mention that Factory has other disadvantages that simply don't make it suitable for everyone.

Factory is not TW. No distro is suitable for *everyone* I guess, but if you elaborate (perhaps on a separate thread) as to why you would not recommend TW to a user, perhaps we could figure out how to fix such complaints.

Btw, the discussion is not OT as long as people claim that simply ditching s.o.o was a step in the right direction:

...

Back to the topic at hand though, if discovering 3rd party software from software.opensuse.org is essential for Leap to be useful, that's a problem that needs to be addressed in Leap, not software.opensuse.org

Looking forward to your suggestions how to do that.

For example, stop recommending random home repos so packagers wanting to distribute their packages _have_ to submit it to official repos or work with upstream to publicise, etc.

[1] https://github.com/xournalpp/xournalpp

Do we really want new users to spin up a VM, install opi and check with opi or zypper se if the packages they want are available?

/Syds

Yes, absolutely we do!

No one is going to install openSUSE because software.o.o says we have a specific package, but the lack of a package would be an excuse to avoid openSUSE.

Therefore, the information on software.opensuse.org just gives people excuses to not install openSUSE. This will still be true if we fix it.

But instead if we require users to use openSUSE to find out about it.. then they’ll already be using it and judging us on what we actually are good at building, rather than a crusty old Ruby web service which no one has maintained for years…

Am 28. März 2022 22:43:08 MESZ schrieb Syds Bearda opensuse@syds.eu:

This tread is going greatly out of topic.

The topic is: software-o-o is not working as intended, let's fix it. It's not about a discussion which packages a user is allowed to use and what not.

Also not everyone using software-o-o is an openSUSE user already. Just yesterday I had a discussion with someone who was thinking about using openSUSE Leap 15.4 as their new workstation OS instead of Ubuntu because of the push for snapd, but he first wanted to know if all the packages that he needs are available, software-o-o would be the perfect website for that.

Do we really want new users to spin up a VM, install opi and check with opi or zypper se if the packages they want are available?

That is exactly my opinion ng. I, too, already cited your example as a reason why all repos should appear in the search. Furthermore, I already had several packages that were not in the official repos, but I needed them. Many of them were in the dev repos. But they did not work properly. So I corrected the errors and then tried a request. Often it is not accepted. Sometimes with good reason, but often for unimportant reasons. This then turns into a back and forth that I don't have the time or inclination for. Or you get the answer that the package is only for Tumbleweed and Leap is not interested. So you just don't return the goods. Then I want a stable system, but a few packages that are up to date. But not all of them. And then I don't feel like integrating several repos. So I branch them into my repo. Then there are users who write to me and ask me for help because they can't get any further officially or in the development. That's another reason why I create packages. And last but not least, of course, for packages in which I am the maintainer in order to carry out updates. Since I take the task seriously, I first test everything on my end before I send it to the development. I have been doing this for more than ten years in my private and professional life and I have never paralysed a system. So the idea of tested packages is much too high. There are a few more reasons to have your own repos and why they should be found via s.o.o., but that's enough for now.

Regards Eric

Hi Syds,

we should definitly not let software.o.o die. This is my first place to go when I miss some software. Most of my demands are satisfied by main-repo, packman, games.

Of course there may be outdated data. But still, at least something is found. Emptyness or the lack of visible software may look to a newcomer as like openSUSE was abandoned.

At least we should index base (for various main versions, just to show what is in Leap X and in Leap Y), packman, games. In general just what's there in YaST2 software community repositories.

But stuff like vscode, dotnet should be mentioned there as well.

The web interface just looks fine and works. We probably should replace the backend with something that is technologywise close to the other technologies used to power opensuse.

I can do Ruby, Python, Java and whatever is necessary to contribute. Maybe we should "elect" someone who is in charge?

Cheers, Bernd

Am 31.03.22 um 00:18 schrieb Atri Bhattacharya:

On Mon, 2022-03-28 at 20:43 +0000, Syds Bearda wrote:

...

This tread is going greatly out of topic.

The topic is: software-o-o is not working as intended, let's fix it.

The topic is also, as I understand it: should we fix it --- therefore investing in it --- or just let it die, and for the security issues and ease with one-click-shopping from random repos will break your system, we should let it die (at least in its current form).

...

It's not about a discussion which packages a user is allowed to use and what not.

Also not everyone using software-o-o is an openSUSE user already. Just yesterday I had a discussion with someone who was thinking about using openSUSE Leap 15.4 as their new workstation OS instead of Ubuntu because of the push for snapd, but he first wanted to know if all the packages that he needs are available, software-o-o would be the perfect website for that.

If *and only if* it showed just the official distro packages (both for Leap and TW).

We do not want to get the users' hope up too much by showing them software from all sorts of repos, then to catastrophically let them down when their system eventually breaks.

Cheers,

Martin Wilck wrote:

On Sat, 2022-03-26 at 18:33 +1030, Simon Lees wrote:

...

...

Ack. Hiding the non-official repos would make the tool essentially useless. With just official repos, it couldn't do much more than "zypper search" + "zypper install" would be able to achieve.

Yeah I guess that's part of my point, if as a project we decide that we don't want to push 3rd party repo's then maybe we don't really need a tool like software.o.o, sure it's nice to have but the project won't fall apart and won't be less useable without it.

I disagree. In my experience, Leap needs 3rd party repos to be usable for anything but basic tasks. I don't think I've ever used Leap on any system for more than a few months without needing 3rd party repos at least temporarily.

FWIW, on my standard office laptop, used for office work, a bit of development, and managing other infrastructure, my only 3rd party repo is packman. Which I think was for ffmpeg.

On Fri, 25 Mar 2022, Andrei Borzenkov wrote:

On 24.03.2022 21:02, Eric Schirra wrote:

...

Am 23. März 2022 15:17:51 MEZ schrieb Richard Biener rguenther@suse.de:

...

On Wed, 23 Mar 2022, Martin Wilck wrote:

...

On Wed, 2022-03-23 at 13:43 +0000, Nicolas Formichella wrote:

...

First of all, a very basic regex check of the URL, most repos have distinct URLs that expose their distro (like for ex. Emulators with https://download.opensuse.org/repositories/Emulators/openSUSE_Tumbleweed/ ) would immediately ease that process

For all other repos that don't (i.e Kernel), IMO, outside of normalizing a format for those URLs, I don't have any idea idea about that

I was talking about something else: current s.o.o frequently finds _nothing_ when you search software for Leap 15.3. It isn't as bad as messing up your system, but it's disappointing and frustrating nonetheless.

The reason is, that s.o.o only search for repos named 15.3 or 15.4.

Wrong. It is not about third-party repositories, it is about packages that are part of Leap.

For third-party repos it seems the appropriate check would be a <path project="openSUSE:Leap:15.3:Update" .../> in their project config, using the repository name is eventually misleading.

...

S.o.o does not search in repos which named openSUSE_Leap_15.3 or openSUSE_Leap_15.4

Point to the official OBS API specification that tells us how search engine should determine distribution from which repository is derived (or for which repository is built).

In any case, your statement is not correct:

    # one off exception for Leap 15.3, which switched it's default
    # repository name from openSUSE_Leap_15.3 to 15.3
    elsif package.repository == 'openSUSE_Leap_15.3'
      leap153 = @distributions.find { |d| d[:dist_id] == '19032' }
      next unless leap153

      package.baseproject = leap153[:project]
    end

...

Why this not can be fixed, I don't understand.

Care to step up and do it?

On 25.03.2022 19:05, Eric Schirra wrote:

Am Freitag, 25. März 2022, 06:04:35 CET schrieb Andrei Borzenkov:

...

...

...

...

I was talking about something else: current s.o.o frequently finds _nothing_ when you search software for Leap 15.3. It isn't as bad as messing up your system, but it's disappointing and frustrating nonetheless.

...

...

The reason is, that s.o.o only search for repos named 15.3 or 15.4.

Wrong. It is not about third-party repositories, it is about packages that are part of Leap.

And home directories or factory do not belong to leap?

Of course not.

I don't care where they come from A search should return all the results. And so it was in Leap 15.2 and bevor.

...

...

S.o.o does not search in repos which named openSUSE_Leap_15.3 or openSUSE_Leap_15.4

Point to the official OBS API specification that tells us how search engine should determine distribution from which repository is derived (or for which repository is built).

In any case, your statement is not correct:

    # one off exception for Leap 15.3, which switched it's default
    # repository name from openSUSE_Leap_15.3 to 15.3
    elsif package.repository == 'openSUSE_Leap_15.3'
      leap153 = @distributions.find { |d| d[:dist_id] == '19032' }
      next unless leap153

      package.baseproject = leap153[:project]
    end

I don't know what you're trying to tell me.

I am trying to tell you that you do not fix problems by picking "the reasons" out of the hat and smugly telling others "that is what you need to do". You fix problems by troubleshooting them, determining "the reason" (not inventing it) and then fixing the real root cause.

If I name my repos openSUSE_Leap_15.3/15.4 a search returns no hits.

And the reason for this is not repo name.

If I rename the repos to 15.3 and 15.4 I get hits on a search.

...

...

Why this not can be fixed, I don't understand.

Care to step up and do it?

This is the answer I have been waiting for. I would do it smoothly if I knew about it.

If you do not know about it why are you telling others what they must do?

On 3/23/2022 7:43, Nicolas Formichella wrote:

Right, but Simon's point is valid. Contributors won't be attracted by having to code an UI that they're unlikely to need / use themselves. It's not the sexiest possible project either, because dozens of similar frameworks exist already, just not targeted at OBS as backend.

Moreover, casual contributors would most probably fail at this project. The basic technical part - connecting to the OBS API - is simple enough. But the difficult part - the one at which software.o.o is currently failing [*] - is to figure out which repositories matter for which distribution, a task that sometimes confuses even long time human openSUSE users. I'm not even sure if this could be reliably figured out from OBS in software without a hard-coded and ever-growing list of exceptions and special cases.

IMO SUSE as openSUSE's sponsor should push this forward somehow. This is not a project to try to attract contributors for, it's a feature that must work in order to attract contributors for other tasks.

I agree with this. There are some things that no matter how hard you try you are not going to attract (many) contributors. Nothing wrong with the community or with the people trying to attract the community, it just is a crummy task.

-- Jason Craig

On Thu, 2022-03-24 at 09:07 +0300, Andrei Borzenkov wrote:

...

Moreover, casual contributors would most probably fail at this project. The basic technical part - connecting to the OBS API - is simple enough. But the difficult part - the one at which software.o.o is currently failing [*] - is to figure out which repositories matter for which distribution, a task that sometimes confuses even long time human openSUSE users. I'm not even sure if this could be reliably figured out from OBS in software without a hard-coded and ever-growing list of exceptions and special cases.

When I tried to raise this concern with OBS maintainers the response was

• not our problem. OBS stays for Open *Build* Service, this is not

the tool to build distribution, we do not care what you are doing with packages that we build.

It is possible to dynamically build list of inherited repositories by (recursively) following <link ...> elements. What is not clear - how to resolve ties between these repositories (i.e. if package is present in several of them). Is it done by OBS itself? Is there any side band tool and configuration to select which packages are part of distribution?

Even less clear is the situation with updates. They are "imported" into openSUSE by some undocumented black magic. Somehow they end in different paths on download server and I have no idea whether these paths are present in any (publicly available) metadata.

Thanks a lot for explaining this much better than I did.

Eventually all this is expressed in OBS logic, I suppose. But OBS has a lot of logical concepts (linking, branching, aggregation, repo inheritance, prjconf, locking, maintenance process, you name it) that interact in non-obvious ways. Recreating this logic in a different tool such that it correctly reproduces the OBS logic is a daunting task.

Which is an argument to actually design this tool as a simplifed UI for OBS itself [*], and have it designed and written by people who are deeply familiar with OBS internals.

Martin

[*] More precisely, for a limited portion of OBS' functionality, basically just determination of suitable repositories for the given distribution and download of binaries.

On Thu, 2022-03-24 at 07:28 -0500, Malcolm wrote:

But osc command line tool (it has a search option) and for a GUI there is already qactus?

These are tools for developers.

We're looking for an end user tool. Something really simple, that just finds and installs apps for users.

Martin

Hey,

On 23.03.22 14:30, Martin Wilck wrote:

Moreover, casual contributors would most probably fail at this project. The basic technical part - connecting to the OBS API - is simple enough. But the difficult part - the one at which software.o.o is currently failing [*] - is to figure out which repositories matter for which distribution

I think you are confusing contributing to software-o.o with fixing this one issue?

And as usual, once you are going about it, you will find many people being able to help you. Even if it's hard :-)

Henne

On 24.03.2022 19:38, Martin Wilck wrote:

On Thu, 2022-03-24 at 15:59 +0100, Henne Vogelsang wrote:

...

Hey,

On 23.03.22 14:30, Martin Wilck wrote:

...

Moreover, casual contributors would most probably fail at this project. The basic technical part - connecting to the OBS API - is simple enough. But the difficult part - the one at which software.o.o is currently failing [*] - is to figure out which repositories matter for which distribution

I think you are confusing contributing to software-o.o with fixing this one issue?

IMO it's the #1 issue to be solved either in s.o.o or any other tool that serves a similar purpose.

OK, so

- the original issue was papered over in https://github.com/openSUSE/software-o-o/pull/1065 (and I personally confirm that search did work after this was deployed)

- this PR hardcoded distribution ID that needs "special treatment" in https://github.com/openSUSE/software-o-o/blob/master/config/initializers/dis...:

# maps a distro_id to an Array of project names that could be the baseproject DISTRIBUTION_PROJECTS_OVERRIDE = { # Leap 15.3 '19032' => ['SUSE:SLE-15:GA', 'SUSE:SLE-15:Update', 'SUSE:SLE-15-SP1:GA', 'SUSE:SLE-15-SP1:Update', 'SUSE:SLE-15-SP2:GA', 'SUSE:SLE-15-SP2:Update', 'SUSE:SLE-15-SP3:GA', 'SUSE:SLE-15-SP3:Update', 'openSUSE:Leap:15.3', 'openSUSE:Backports:SLE-15-SP3'] }.freeze

DISTRIBUTION ID IS HARDCODED IN OTHER PLACES TOO

./app/controllers/obs_controller.rb: leap153 = @distributions.find { |d| d[:dist_id] == '19032' }

./config/initializers/distributions_projects.rb: '19032' => ['SUSE:SLE-15:GA', 'SUSE:SLE-15:Update', 'SUSE:SLE-15-SP1:GA',

bor@bor-Latitude-E5450:~/src/openSUSE/software-o-o$

- distribution ID changed after Leap 15.3 respin:

bor@bor-Latitude-E5450:~/src/openSUSE/software-o-o$ osc api -X GET /distributions/19032

Server returned an error: HTTP Error 404: Not Found

Couldn't find Distribution with 'id'=19032

bor@bor-Latitude-E5450:~/src/openSUSE/software-o-o$ osc api -X GET /distributions/20043

<distribution vendor="openSUSE" version="15.3" id="20043">

<name>openSUSE Leap 15.3</name>

<project>openSUSE:Leap:15.3</project>

<reponame>15.3</reponame>

<repository>standard</repository>

<link>http://www.opensuse.org/</link>

<icon url="https://static.opensuse.org/distributions/logos/opensuse.png" width="8" height="8"/>

<icon url="https://static.opensuse.org/distributions/logos/opensuse.png" width="16" height="16"/>

<architecture>x86_64</architecture>

</distribution>

bor@bor-Latitude-E5450:~/src/openSUSE/software-o-o$

- boom. Search stopped working again.

So minimal "fix" is to change distribution ID which at least allows search to work again for 15.3 again. Of course it will not fix 15.4 or any future version.

The lesson learned - software.o.o cannot be maintained by external volunteers alone. This MUST be driven and coordinated by openSUSE release management. At the very least openSUSE release management must sit down with OBS maintainers and come up with stable API for searching for packages belonging to distribution. But I do not hold my breath. openSUSE release management was aware of this problem for almost a year and did nothing. Apparently this is not considered a problem.

Hey,

On 26.03.22 06:52, Andrei Borzenkov wrote:

So minimal "fix" is to change distribution ID which at least allows search to work again for 15.3 again.

So... how about you create a pull request to the repository? Let's continue there, shall we? :-)

And that Ladies and Gentlemen is how you contribute to the our project. You gather the code, you analyze the problem and you propose a fix/workaround/feature. Everything else (especially talking on some mailinglist) is based on *THIS*.

The lesson learned - software.o.o cannot be maintained by external volunteers alone.

External to what exactly? Everything is there. software-o-o, OBS, the data. It just needs someone, like you, to debug the problem and come up with a solution/workaround/issue.

This MUST be driven and coordinated by openSUSE release management.

I guess you think because this team has "management" in their name that they have actual resources to direct? They don't, just a group of people that tries to do their best. If they can't pin-point/understand the problem, they can't. If they can't implement the fix, they can't...

Henne

On Tue, 2022-03-29 at 12:26 +1030, Simon Lees wrote:

It is worth pointing out though that its very much in SUSE's interest for openSUSE to continue functioning to the point of creating a couple of distros because they use that as the foundation of some of there projects.  To that they commit to meeting what they see as the core needs of openSUSE to keep it running.

This means that SUSE needs to put some basic building blocks in place. Otherwise this foundation is going to crumble sooner or later. A decent tool for searching and installing software is one of the basic building blocks of a Linux distribution, IMHO. Especially because independent upstream 3rd party projects usually just target Ubuntu and Fedora, and because the standard GUI tool (GNOME software / KDE discover) is at most a 2nd-class citizen on our distro.

SUSE (as a company) can't just simply sit down and say "Hey community, write a nice Web UI for openSUSE". It may happen, but it might as well not - community members are entitled to decide that other projects are more insteresting for investing their spare time. If it doesn't happen, the non-availability of such a tool will be a competitive disadvantage in the eyes of quite a few users.

But they do that as equal volunteers with everyone in the community for the most part.

And this is the problem, it doesn't work this way. At least not for software.o.o, quite obviously. Fixing s.o.o wouldn't be a billion- dolloar project, assigning some company resources for it would be a good investment.

Martin

On Tue, 29 Mar 2022, at 11:35, Richard Brown wrote:

On Tue, 2022-03-29 at 12:33 +0200, Martin Wilck wrote:

...

On Tue, 2022-03-29 at 12:26 +1030, Simon Lees wrote:

...

It is worth pointing out though that its very much in SUSE's interest for openSUSE to continue functioning to the point of creating a couple of distros because they use that as the foundation of some of there projects.  To that they commit to meeting what they see as the core needs of openSUSE to keep it running.

This means that SUSE needs to put some basic building blocks in place. Otherwise this foundation is going to crumble sooner or later. A decent tool for searching and installing software is one of the basic building blocks of a Linux distribution, IMHO. Especially because independent upstream 3rd party projects usually just target Ubuntu and Fedora, and because the standard GUI tool (GNOME software / KDE discover) is at most a 2nd-class citizen on our distro.

SUSE (as a company) can't just simply sit down and say "Hey community, write a nice Web UI for openSUSE". It may happen, but it might as well not - community members are entitled to decide that other projects are more insteresting for investing their spare time. If it doesn't happen, the non-availability of such a tool will be a competitive disadvantage in the eyes of quite a few users.

Why should SUSE consider this as a basic building block? No other distribution has an equivalent to software.opensuse.org. SUSE can't be pointed at Ubuntu or Fedora and be told to spend money where those projects suceed without it.

Ubuntu has: https://packages.ubuntu.com/ & https://launchpad.net/ Fedora has: https://packages.fedoraproject.org/ & https://copr.fedorainfracloud.org/

openSUSE has the nice advantage that OBS is working for both official repos AND community repos (excluding Packman), as such software-o-o works for all public repos.

/Syds

On 3/29/22 22:29, Henne Vogelsang wrote:

Hey,

On 29.03.22 12:33, Martin Wilck wrote:

...

This means that SUSE needs to put some basic building blocks in place.

Au contraire mon ami. SUSE already does *way* too much for openSUSE. If this is supposed to be a healthy FOSS project, openSUSE needs to be able to attract contributors. If we can't, SUSE can't fix this either.

Well really at the moment openSUSE is significantly limited in the amount it can do due to its legal structure so in order to change how much SUSE currently does and for openSUSE to be more independent that'd need to change as well. How much that would attract new contributors I don't know but I also know the vast majority of our current contributors aren't web developers so it doesn't surprise me that we struggle to find people to help here.

On 3/29/22 23:23, Henne Vogelsang wrote:

Hey,

On 29.03.22 14:23, Simon Lees wrote:

...

On 3/29/22 22:29, Henne Vogelsang wrote:

...

On 29.03.22 12:33, Martin Wilck wrote:

...

This means that SUSE needs to put some basic building blocks in place.

Au contraire mon ami. SUSE already does *way* too much for openSUSE. If this is supposed to be a healthy FOSS project, openSUSE needs to be able to attract contributors. If we can't, SUSE can't fix this either.

Well really at the moment openSUSE is significantly limited in the amount it can do due to its legal structure so in order to change how much SUSE currently does and for openSUSE to be more independent that'd need to change as well.

I have no idea what the legal structure of *anything* has to do with starting to attract contributors to a FOSS project.

You need legal if you need money. You don't need money to attract contributors.

I have seen at least several partnerships that would have likely resulted in attracting new contributors both from within those partners and outside stopped because the partner was uncomfortable with signing an agreement with SUSE directly rather then openSUSE.

You wrote in another reply

SUSE is the single dominant source of manpower and resources for

> openSUSE. For the sake of openSUSEs sustainability, SUSEs dominance > shouldn't be increased at every turn, there should be diversification.

Only so much diversification can happen while openSUSE has the inability to sign agreements with partners, own any form of assets and to a lesser extent collect our own funds. Sure we can and do attract contributors without these things, but in my time on the board I saw how not having these things limited us as a project particularly in diversification which is why I spent alot of time looking at foundation related topics.

On 3/30/22 20:59, Henne Vogelsang wrote:

Hey,

On 30.03.22 10:24, Simon Lees wrote:

...

which is why I spent alot of time looking at foundation related topics.

And that is nice and all. But *additionally* to doing the grunt work of attracting contributors, not *instead* of it.

Sure, do you have a magical time tree for me? I have a young family and most of my board work was done around that my day job and the various other open source projects I contribute to.

If I could think of simple easy things to attract new contributors I would absolutely have been doing them as well, but its hard and I don't have many ideas, do you? One thing I do know is how to package so if anyone wants to learn packaging or needs help with it I have and always will go out of my way to help them.

But if you can think of a bunch of "grunt" work that can be done to attract new contributors and you don't have time to do it yourself why don't you share your ideas because maybe someone else does have time to.

Hi

On 3/31/22 09:21, Emily Gonyer wrote:

It seems like this is an ongoing issue, whereby openSUSE is limited by it's own guidelines and bylaws. This seems like a fixable issue, and one which can be and should be worth working on in the future. Perhaps a workshop at the upcoming openSUSE conference is in order to discuss and hopefully implement a new set of guidelines and bylaws which can allow openSUSE to expand beyond SUSE.

Unfortunately its a fair bit more complex then that, currently openSUSE doesn't have any form of legal entity currently everything is handled by and through SUSE. Setting one up that meets all the various legal regulations and is sustainable also isn't as simple as it seems at face value. But if other people would like to help working on a proposal to put to SUSE i'd be happy to help, currently with the amount of spare time I have I can't drive this on my own.

On Wed, Mar 30, 2022, 7:23 AM Simon Lees <sflees@suse.de mailto:sflees@suse.de> wrote:

On 3/30/22 20:59, Henne Vogelsang wrote:
> Hey,
>
> On 30.03.22 10:24, Simon Lees wrote:
>
>> which is why I spent alot of time looking at foundation related
topics.
>
> And that is nice and all. But *additionally* to doing the grunt
work of
> attracting contributors, not *instead* of it.

Sure, do you have a magical time tree for me? I have a young family and
most of my board work was done around that my day job and the various
other open source projects I contribute to.

If I could think of simple easy things to attract new contributors I
would absolutely have been doing them as well, but its hard and I don't
have many ideas, do you? One thing I do know is how to package so if
anyone wants to learn packaging or needs help with it I have and always
will go out of my way to help them.

But if you can think of a bunch of "grunt" work that can be done to
attract new contributors and you don't have time to do it yourself why
don't you share your ideas because maybe someone else does have time to.

-- 
Simon Lees (Simotek)                            http://simotek.net
<http://simotek.net>

Emergency Update Team                           keybase.io/simotek
<http://keybase.io/simotek>
SUSE Linux                           Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On 3/31/22 11:09, Emily Gonyer wrote:

I would definitely be interested in working on such a proposal, and am sure some other folks would be as well. I know that I am a relative newcomer to openSUSE, but I believe that forming a foundation for openSUSE, so that it can act on its own behalf is certainly a worthwhile goal.

This proposal from 2019 [1] is probably the best reading for getting started, at the time we as the openSUSE board discussed this with the management at SUSE and had a positive response, unfortunately soon after that there were a significant number of changes in SUSE's management and we decided it would be best for that to settle before moving any further forward with it. Now its once again waiting for people to have time to start driving the discussion again.

In terms of changes one thing we could consider is there is a similar not for profit structure in the US that maybe better or worse so could be worth looking at especially if anyone has had some involvement with them.

We also need to spend some time developing a better business case, with the previous management this was less of an issue. But there are a number of ways that openSUSE having a foundation could save SUSE money such as being able to get more and better conference sponsorship and so putting together a business case would be useful.

Anyway if your interested it might be worth starting another discussion on the project list to see if we can find some more people.

Cheers

Simon

1. https://lists.opensuse.org/archives/list/project@lists.opensuse.org/message/...

On Wed, Mar 30, 2022 at 8:17 PM Simon Lees <sflees@suse.de mailto:sflees@suse.de> wrote:

Hi

On 3/31/22 09:21, Emily Gonyer wrote:
> It seems like this is an ongoing issue, whereby openSUSE is limited by
> it's own guidelines and bylaws. This seems like a fixable issue,
and one
> which can be and should be worth working on in the future. Perhaps a
> workshop at the upcoming openSUSE conference is in order to
discuss and
> hopefully implement a new set of guidelines and bylaws which can allow
> openSUSE to expand beyond SUSE.

Unfortunately its a fair bit more complex then that, currently openSUSE
doesn't have any form of legal entity currently everything is handled by
and through SUSE. Setting one up that meets all the various legal
regulations and is sustainable also isn't as simple as it seems at face
value. But if other people would like to help working on a proposal to
put to SUSE i'd be happy to help, currently with the amount of spare
time I have I can't drive this on my own.

> On Wed, Mar 30, 2022, 7:23 AM Simon Lees <sflees@suse.de
<mailto:sflees@suse.de>
> <mailto:sflees@suse.de <mailto:sflees@suse.de>>> wrote:
>
>
>
>     On 3/30/22 20:59, Henne Vogelsang wrote:
>     > Hey,
>     >
>     > On 30.03.22 10:24, Simon Lees wrote:
>     >
>     >> which is why I spent alot of time looking at foundation related
>     topics.
>     >
>     > And that is nice and all. But *additionally* to doing the grunt
>     work of
>     > attracting contributors, not *instead* of it.
>
>     Sure, do you have a magical time tree for me? I have a young
family and
>     most of my board work was done around that my day job and the
various
>     other open source projects I contribute to.
>
>     If I could think of simple easy things to attract new
contributors I
>     would absolutely have been doing them as well, but its hard
and I don't
>     have many ideas, do you? One thing I do know is how to package
so if
>     anyone wants to learn packaging or needs help with it I have
and always
>     will go out of my way to help them.
>
>     But if you can think of a bunch of "grunt" work that can be
done to
>     attract new contributors and you don't have time to do it
yourself why
>     don't you share your ideas because maybe someone else does
have time to.
>
>     --
>     Simon Lees (Simotek)                           
http://simotek.net <http://simotek.net>
>     <http://simotek.net <http://simotek.net>>
>
>     Emergency Update Team                         
 keybase.io/simotek <http://keybase.io/simotek>
>     <http://keybase.io/simotek <http://keybase.io/simotek>>
>     SUSE Linux                           Adelaide Australia, UTC+10:30
>     GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
>

-- 
Simon Lees (Simotek)                            http://simotek.net
<http://simotek.net>

Emergency Update Team                           keybase.io/simotek
<http://keybase.io/simotek>
SUSE Linux                           Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

-- Whatever you can do, or dream you can, begin it. Boldness has genius, power and magic in it. -  Goethe

...

...

...

...

"HV" == Henne Vogelsang hvogel@opensuse.org writes:

HV> Hey, redirected to project@ as this the more appropriate list for me to HV> rant about community building :-)

Sorry not in the project mailinglist,

HV> This is a well established, written about, even researched topic.

HV> There are tons of things we can do "passively" for our projects. And by HV> projects I don't mean openSUSE as a whole. I mean all the building blocks HV> that make up openSUSE. The teams, the software projects, the distribution HV> etc.

Have you (meaning every one so plural) read the Phoenix Project by Gene Kim,

My understanding is we are exactly in the same boat and this has been always so ever since I got my self on the suse/opensuse mailinglist ages ago. The sad part is nothing has changed, it has been always the same problems. Has nothing got better, sure there have been improvement but it is always in my mind a firefighting scenario, or a first aid bandage to the finger.

So the moral of this mail is if haven't read the Phoenix Project yet please do read it and believe you in me it is a page turner, if read before go through your notes you have taken. I am sure we all be thinking a different approach next time around.

Have a great weekend,

Togan

--

Life is endless possibilities, and there is choice!

On So, Apr 3 2022 at 19:20:54 +0200, Sarah Julia Kriesch ada.lovelace@gmx.de wrote:

...

I want to recommend an additional book for our openSUSE Board.

Just to note, hoping the obvious doesn't get missed here, this is not just the responsibility of the board, we are in this together. I don't want the board to stay still and not move their finger either, but I also hope we don't collectively stop and think that selecting 5 people a year solves this issue for us. We all need to take part in community building.

LCP [Sasi] https://lcp.world/

n Sun, 2022-04-03 at 19:49 +0200, Sarah Julia Kriesch wrote:

There is also a general book in this direction with the name The Open Organization. That is really interesing for all (but also for companies). https://www.amazon.de/Open-Organization-Igniting-Passion-Performance/dp/1625...

Best regards, Sarah

"You can't lead an open organizion in the tradtional top-down fashion" (Page 15)

"Top-down decision making simply doesn't work.." (Page 16)

"...each person is equally accountable for [thier] contributions and performance to everyone else, regardless of reporting relationship" (Page 81)

"Don't wait for your manager to provide context" (Page 81)

"Engage with your peers" (Page 81)

"Don't use phrases like 'the boss wants it this way' or rely on hierarchical name dropping" (Page 106)

"Consider whether your influence comes from your position [..], or whether is truely comes from the respect you have earned" (Page 106)

(All Page citations are from ISBN 978-1-62527-527-1 (Hardback) - "Open Organization" by Jim Whitehurst (Signed))

I do not think that book sells the type of leadership your recent and historical posts on this mailinglist clearly seem to be desiring.

Regards,

Richard

On Mon, 2022-04-04 at 11:48 +0200, Sarah Julia Kriesch wrote:

...

I do not think that book sells the type of leadership your recent and historical posts on this mailinglist clearly seem to be desiring.

I did not  say anything in against these statements. I wanted to see Board Members interacting as role models others want to follow. If you are interacting on the same way as in the past on these mailing list, I have to create the first moderator ticket.

Thanks for your feedback, maybe the below will clear up where I'm coing from.

One of the fundemental lessons of "The Open Organisation" is that leaders in open organisations are _not_ intended to be role models, but to provide, nuture, and support an environment where people can define their own role.

The book stresses this point repeatedly, both directly, and implicitly with its constant deliniation between 'leaders' and 'associates'.

The Board is designed to be a body that adds some of that necessary provisioning, nuturing and support to the openSUSE organisation. It is not designed to be a body of role models, and I think that's fine.

After all, it is hard to do the duty of conflict resolution and still keep on everyones good side.

And on that note, considering your threat regarding the moderators, I will quote again from the book (it IS a good book)

"Proactively invite feedback and then thank those who give it to you. Feedback is a gift. As a leader or manager, if you react defensivly, you are unlikely to get that gift again"

On Mon, 2022-04-04 at 13:33 +0200, Sarah Julia Kriesch wrote:

Then I want to reference also from the recommended books. The Open Organization Leaders Manual, p.78: "Exponential leadership occurs when an individual's impact gets multiplied. Exponential leaders compound and integrate the strengths of teams (groups of people) to create new organizational capabilities. They create new leaders and catalyze vibrant ecosystems of teams that channel their passion and energy toward a shared organizational purpose to deliver rapid results. Their leadership contributions have a powerful effect, with the potential to profoundly influence an organization's culture."

Thanks! Very interesting to see you jump to that part of the document (for anyone wishing to following along - https://github.com/open-organization/open-org-leaders-manual/blob/master/10-... )

The whole document describes 3 stages of leadership. Leading Personally, Leading through a team, and Leading exponentially by catalzing other leaders.

If I look at the principles of the rest of that essay and super-impose openSUSE atop it, it seems to undermine any suggestion that _The Board_ have a particually special role to play in such a journey.

In openSUSE we can all choose to lead (personally) in whatever areas we wish. I've done that, you've done, the door is wide open for others to do that.

The same goes for Team Leadership, as you are well aware with the team you have around you from your past leadership of the Localization process in openSUSE.

Exponential leadership, taking someones leadership and compounding it with others, creating new leaders in the process, is not something we need the Board to do, but something good leaders can do throughout the project.

Just thinking of my own personal story in openSUSE, I can think of countless examples of this -

Kostas being an exponential leader and pushing me forward to contribute more to openSUSE.

Myself trying to be somewhat of an exponential leader encoraging and mentoring various people across the Project, many of whom have become leaders in their own right (as examples - Sasi, Marina, Dario, Neal).

There's lots I used to do as a 'leader' in openSUSE which is now handled by people better at it than I..being able to obsolete yourself is a key part of exponential leadership.

It's an important part of community building, sure. I agree with you there.

And it's certainly an area where we have weaknesses - your example of the Localization team no longer have a coordinator is a good one.

But, where I disagree is - we don't need the Board to do it - infact the Board as an entity is compromised by it's role as a dispute resolution body and escalation point for various private matters.

Speaking from experience, it's REALLY hard to balance those burdens with a desire to do _anything else_ for the Project so I can totally understand when good leaders in the community find themselves ironically _less_ visible as a Board member than they did as a non- Board member.

Sticking with the Localization Team example - It's not the Board's job to figure out who should coordinate it.. it's the Team's job to figure out who amonst them should do it - or whether they actually need a coordinator at all.

Given things are still getting translated, maybe we don't need one, maybe the community is mature enough to figure that out on it's own. That would be a good thing, no?

Look into our community and our situation. How  do you  define people with passion for their role in the community? Are these people role- models or how do you define them?

I do not want to judge nor define people who volunteer this community.

I want our volunteer maintainers to be able to define themselves.

I believe this is the core point Henne was also trying to make with starting this thread, with his suggestions as to how openSUSE could be better at doing that.

None of Henne's suggestions require the Board to do any of them.

- R

Hey,

On 29.03.22 15:41, Martin Wilck wrote:

On Tue, 2022-03-29 at 13:59 +0200, Henne Vogelsang wrote:

...

On 29.03.22 12:33, Martin Wilck wrote:

...

This means that SUSE needs to put some basic building blocks in place.

Au contraire mon ami. SUSE already does *way* too much for openSUSE.

In what sense? Financially? In terms of developer resources? Can you provide any reasoning for this strong statement?

SUSE is the single dominant source of manpower and resources for openSUSE. For the sake of openSUSEs sustainability, SUSEs dominance shouldn't be increased at every turn, there should be diversification.

So far I thought that openSUSE, in particular Factory, is a valuable asset for SUSE in various ways.

Sure there is a reason for SUSE to do what they do, they benefit from openSUSE. One has nothing to do with the other...

If openSUSE wants to be a sustainable free software project it needs to have a broad set of maintainers. Obviously we don't have that for many parts that are somewhat basic functionality of our community. Lot's of things are held together by bubble gum and shoe strings.

You don't attract contributors by calling out for them.

Not exclusively no. Nothing as complex as a people is monocausal :-)

If SUSE wants the project to thrive, it has to invest in it.

And SUSE does. It pays people like Doug, Dominique, Lubos or me to do this full time. It gives it Employees time to contribute to Open Source of their choosing. It's the by far the largest source of money, other resources (servers, network etc.) and "workforce" for openSUSE.

So to paraphrase some president: Don't ask what SUSE can do for your Free Software project, ask what you can do for your Free Software project.

Henne

On 3/29/22 21:03, Martin Wilck wrote:

On Tue, 2022-03-29 at 12:26 +1030, Simon Lees wrote:

...

It is worth pointing out though that its very much in SUSE's interest for openSUSE to continue functioning to the point of creating a couple of distros because they use that as the foundation of some of there projects.  To that they commit to meeting what they see as the core needs of openSUSE to keep it running.

This means that SUSE needs to put some basic building blocks in place. Otherwise this foundation is going to crumble sooner or later. A decent tool for searching and installing software is one of the basic building blocks of a Linux distribution, IMHO. Especially because independent upstream 3rd party projects usually just target Ubuntu and Fedora, and because the standard GUI tool (GNOME software / KDE discover) is at most a 2nd-class citizen on our distro.

SUSE (as a company) can't just simply sit down and say "Hey community, write a nice Web UI for openSUSE". It may happen, but it might as well not - community members are entitled to decide that other projects are more insteresting for investing their spare time. If it doesn't happen, the non-availability of such a tool will be a competitive disadvantage in the eyes of quite a few users.

...

But they do that as equal volunteers with everyone in the community for the most part.

And this is the problem, it doesn't work this way. At least not for software.o.o, quite obviously. Fixing s.o.o wouldn't be a billion- dolloar project, assigning some company resources for it would be a good investment.

Well in this case it is really up to the project to convince SUSE of that, because likely at the level of management that can do something about it (ie allocate resources) no one is aware.

The correct way for the community to do such a thing would be via the board. I am no longer on the board but they have fortnightly meetings and i'm sure they would welcome an agenda item on the topic and possibly after that a detailed business case that could be presented to SUSE. Of course they may not say yes but it never hurts to ask nicely.

Hey,

On 29.03.22 12:41, Andrei Borzenkov wrote:

On 28.03.2022 18:29, Henne Vogelsang wrote:

...

On 26.03.22 06:52, Andrei Borzenkov wrote:

...

So minimal "fix" is to change distribution ID which at least allows search to work again for 15.3 again.

So... how about you create a pull request to the repository? Let's continue there, shall we? :-)

There is nothing to discuss. The current approach is wrong, nothing better can be done without involvement of OBS developers, they already bounced the problem off to "openSUSE release management" that does not exist as you explained.

You seem to think that there are OBS developers to freely commit by someone, to do any work that comes up. There are not. There is a shitload of things to do and people already pick their fights wisely.

This (as BTW 99% of any other problem in software/OBS) is solvable by anyone who can contribute code to an Ruby on Rails project. You are proof of that.

So now that I have cleaned up the project and you fixed the #1 bug, all everyone can do is to try to attract long term maintainers.

Henne

On 29.03.2022 15:13, Henne Vogelsang wrote:

So now that I have cleaned up the project and you fixed the #1 bug

It did not fix anything. As soon as Leap 15.4 is available users get exactly the same problem with this version.

On 3/22/22 23:33, Eric Schwarzenbach wrote:

Could there be some well-developed software used by another distro (or a collaboration of distros) for the same purpose that could be adopted and adapted?

Not really, we use a completely different build system from other distro's so its likely the amount of work to use / adapt any of there solutions is more then writing our own.