Planning decomission of software.opensuse.org (Community meeting)
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.
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.
-- Best regards Lubos Kocman openSUSE Leap Release Manager
Hi Lubos, what does that mean? I would like to contribute. 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.
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.
Lubos Kocman wrote:
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.
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. 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.
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.
On Fri, 2022-03-18 at 17:52 +0000, Sy retia wrote:
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.
Well, I think the problem with Java/ECMA-Script is that building it as package like is currently done with software-o-o [0] is basically not possible [1]. Relying on the existing OBS infastructure seems like a better choice, so maybe langs like go (with obs-service-go_modules) or python (with proper split packages) seems like a better way to go. However as Lubos said,
We should not try to make this a ruby vs python vs node fight so I don't care too much about the language being chosen :)
All the software site really needs to do is make a couple of API calls for information and render a page with that information...
One could in theory get arround the issue of node packaging, if one were to only build a static page does does the API calls client side, however to access the API you need to be authenticated, so the any proposed software-o-o alternative will need some kind of server stack to do proxy auth in order to access OBS.
seems like involving Ruby maybe overcomplicates things.
[0]:https://build.opensuse.org/package/show/openSUSE:infrastructure:software.ope... [1]:https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/N... -- $\int_\text{now}^{+\infty}\text{Keep trying}$ Matrix: @sp1rit:tchncs.de <sp1rit@disroot.org> D248BF2F4C6A82A1E0569D897D8C1CD573166D09 <sp1rit@national.shitposting.agency> BBDE032EAAFBFC627FB7E635B1F4055D8460CE34
Actually, due to opi and opi-proxy, authentication is no longer needed for any API requests that would be relevant to the search page.
Hi, "Sy retia" <simonizor@protonmail.com> writes:
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.
if you decide to go down the JavaScript/Typescript route, then you could leverage my OBS API wrapper: https://github.com/SUSE/open-build-service-api/ It does not support the opi-proxy that you mentioned downthread, but adding it should be actually not that hard. Also, then the new software.o.o could be completely backend free. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev
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/
I was just identifying the problem and suggesting a possible fix. The whole "feel free to contribute" attitude is unnecessary and off-putting.
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? -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On Fri, 2022-03-18 at 21:47 +0100, Carlos E. R. wrote:
So this is only about the one click install feature, and not the entire software.opensuse.org site going to be removed?
No, If I've understood correctly, software-o-o is going to be deprecated and it's replacement will not feature the one click install ymp thingy, because it doesn't work well on modern openSUSE.
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/
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. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Ivo Totev HRB 36809 (AG Nürnberg)
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. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
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. Martin
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. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
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. Users are left to guess what is the purpose of a repository just from its name. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.3 (Legolas))
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. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 18.03.2022 20:42, Sy retia wrote:
Lubos Kocman wrote:
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.
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
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 Do, Mär 24 2022 at 08:28:51 +0100, Bernhard M. Wiedemann <bernhardout@lsmod.de> wrote:
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
We could use that, but maybe it would be possible to integrate it into OBS itself? In any case, I have left an issue on software-o-o about it, and may have a look at integrating it in the future. https://github.com/openSUSE/software-o-o/issues/1147 LCP [Sasi] https://lcp.world/
On Do, Mär 17 2022 at 21:05:14 +0000, Lubos Kocman <lubos.kocman@suse.com> wrote:
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.
I can update the deps over a weekend or two, which version of ruby should I aim for, to best work with the deployment?
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.
If you don't mind, could we maybe also have a space to discuss this with some IM solution? We do have the old #software-o-o:opensuse.org matrix room, that was at some point bridged to gitter, though idk if that's still the case. If that doesn't work for you, I can bridge with some other platform as well. LCP [Sasi] https://lcp.world/
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. 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. On the other side, fixing current codebase would help as well as long as we can find active maintainers :-) Lubos Sasi Olin píše v Pá 18. 03. 2022 v 19:49 +0100:
On Do, Mär 17 2022 at 21:05:14 +0000, Lubos Kocman <lubos.kocman@suse.com> wrote:
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.
I can update the deps over a weekend or two, which version of ruby should I aim for, to best work with the deployment?
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.
If you don't mind, could we maybe also have a space to discuss this with some IM solution? We do have the old #software-o-o:opensuse.org matrix room, that was at some point bridged to gitter, though idk if that's still the case. If that doesn't work for you, I can bridge with some other platform as well.
LCP [Sasi] https://lcp.world/
-- Best regards Lubos Kocman openSUSE Leap Release Manager
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 Di, Mär 22 2022 at 12:21:29 +0100, Sasi Olin <hellcp@opensuse.org> wrote:
On Di, Mär 22 2022 at 09:51:40 +0000, Lubos Kocman <lubos.kocman@suse.com> wrote:
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.
Answering myself a little bit, but on the topic, I hope you know that packages-o-o existed for a while too, though there has not been much interest there either. https://github.com/openSUSE/packages-o-o 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/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2022-03-22 at 11:39 -0000, Syds Bearda wrote:
On Tue, 22 Mar 2022, at 11:21, Sasi Olin wrote:
On Di, Mär 22 2022 at 09:51:40 +0000, Lubos Kocman <> wrote:
...
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.
opi as an alternative to the search in software.opensuse.org doesn't "work" very well. Example: cer@Telcontar:~> opi firefox 1. MozillaFirefox 2. MozillaFirefox-devel 3. MozillaFirefox-debuginfo 4. MozillaFirefox-debugsource 5. MozillaFirefox-buildsymbols 6. MozillaFirefox-branding-openSUSE 7. MozillaFirefox-branding-upstream 8. MozillaFirefox-translations-other 9. MozillaFirefox-translations-common 10. firefox-esr-branding-openSUSE 11. firefox-theme-breeze-dark 12. firefox-esr 13. eid-mw-firefox 14. firefox-esr-debuginfo 15. firefox-esr-debugsource 16. firefox-uget-integrator 17. firefox-esr-branding-upstream 18. firefox-esr-translations-other 19. firefox-esr-translations-common 20. firefox-beta 21. schule-firefox 22. firefox-pkcs11-loader 23. firefox-esr-devel 24. schule-firefox-sas 25. schule-firefox-sasnb 26. schule-firefox-gymhim 27. schule-firefox-gymhimnb 28. firefox-esr-buildsymbols Pick a number (0 to quit): 0 cer@Telcontar:~> It doesn't give "information", just names. If I choose "1" then I get some information on that entry only: Pick a number (0 to quit): 1 You have selected package name: MozillaFirefox 1. openSUSE:infrastructure:software.opensu + | 60.6.2 | x86_64 2. mozilla:Factory ? | 98.0 | x86_64 3. mozilla ? | 98.0.1 | x86_64 4. mozilla:beta ? | 94.0 | x86_64 5. home:schaats ! | 97.0.1 | x86_64 6. home:manfred-h:mozilla ! | 98.0.1 | x86_64 Pick a number (0 to quit): Pick a number (0 to quit): 3 You have selected binary package: mozilla ? | 98.0.1 | x86_64 [sudo] password for cer: and then tries to install. It gives very little information, it goes directly to installation. It doesn't clearly say which repo, which URL, what it is going to do. Previous times I used it, "opi --help" failed, today I see a nice help. Good. I also see now a man page (stamped March 2022). But that man page does not explain the usage process of opi. For example, nowhere do I see if I above give the password whether it will be a direct install, or if a repo will be added first. - -- Cheers, Carlos E. R. (from openSUSE 15.3 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYjm58xwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV0moAoIMuIzJ2REKWz0USneEC xOt1aJASAJ9/Sper6CttScjsUo0UYWNNHE1gww== =zy8K -----END PGP SIGNATURE-----
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/
Hey, On 22.03.22 12:21, Sasi Olin wrote:
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.
This is not a matter of software-o.o. It's a matter of the application layer of *most* openSUSE infrastructure. It is simply bit-rotting away. The *only* way to fix this is to attract more contributors. This is not a technical problem.... Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson
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. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
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. Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson
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.
De : Martin Wilck <martin.wilck@suse.com> Envoyé : mercredi 23 mars 2022 14:30 À : factory@lists.opensuse.org <factory@lists.opensuse.org> Objet : Re: Planning decomission of software.opensuse.org (Community meeting) 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. 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
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, 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? Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)
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
Richard Biener píše v St 23. 03. 2022 v 15:17 +0100:
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? Just to mention there are currently two tracked issues on software-o-o.
https://github.com/openSUSE/software-o-o/issues/1101 (missing Leap 15.3+ packages) https://github.com/openSUSE/software-o-o/issues/1064 (grouping issue for packages available for Leap 15.3+ that can be seen)
Richard.
-- Best regards Lubos Kocman openSUSE Leap Release Manager
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
On 3/25/22 04:32, 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. 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. 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). -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
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 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. Martin
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. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
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. 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.
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. And the first place for user who search a distro to look if the program which they need is in it. And the first place to search for repos to include in zypper Regards Eric
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. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Sat, 2022-03-26 at 18:33 +1030, Simon Lees wrote:
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.
I might be a bit biased, but I've seen OBS (and OPI) "advertised" in various communities (mostly Reddit, but also other ones like HN, 4chan and similar) as the AUR replacement for openSUSE. While I don't necessarily with that statement, It seems using third party "community" repos from OBS is certainly a common usecase and it wouldn't seem right for "the project" to remove any kind of mention of non-offical software, because also "community" repos extend the amount of available software as a whole, which in turn is a requirement for more users (and that results in new contributors, which is, as discussed elsewhere in this thread, the main goal of the project). However it seems that instead of software-o-o and the yast metapackage "One click installers", usualy OPI gets reccomended, presumably because it is less likely to break the install and I feel it does a better job (more AUR like) at differentiating between package and repository. I hope that whatever will come as replacement for software-o-o will be able to show OBS package relations, because the bunch of unmodified published branches from a popular package really doesn't help anyone.
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.
-- $\int_\text{now}^{+\infty}\text{Keep trying}$ Matrix: @sp1rit:tchncs.de <sp1rit@disroot.org> D248BF2F4C6A82A1E0569D897D8C1CD573166D09 <sp1rit@national.shitposting.agency> BBDE032EAAFBFC627FB7E635B1F4055D8460CE34
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
Dne pondělí 28. března 2022 16:38:33 CEST, Martin Wilck napsal(a):
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.
Yes. Easiness of adding 3rd party repos is important strength of openSUSE. Removal of such (easy) option would significantly crippled the distribution.
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.
Yes. "Normal" users use to go to s.o.o, search, click, click, click, and the SW is installed. All other options are less convenient, harder, ...
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.
Exactly. In my case, without OBS repos like science or R, openSUSE would be hardly usable (and basically not recommendable to my colleagues). -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
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
* Eric Schirra <ecsos@opensuse.org> [03-28-22 11:19]:
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.
opi appears decent for tw, but do not know about leap -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc What sort of day was it? A day like all days, filled with those events that alter and illuminate our times...
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
Am 28. März 2022 17:49:56 MESZ schrieb Martin Wilck <mwilck@suse.com>:
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.
Yes. But I wrote not about developer. I wrote about the view of user. Regards Eric
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
Am 28. März 2022 18:39:20 MESZ schrieb Martin Wilck <mwilck@suse.com>:
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 :-).
When I want use flatpack. I can use Windows. Regards Eric
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 17:40 +0000, Bernd Ritter wrote:
PS: Is there a special discord channel or irc channel where one can meet other possible contributors to this project?
There is a Channel on the openSUSE Discord [1], which is also bridged to Matrix [2] [1] https://discord.gg/opensuse [2] https://matrix.to/#/#software-o-o:opensuse.org -- Have a lot of fun! Marcel Kühlhorn
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 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? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
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 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.
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. 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. Martin
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/
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. -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
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 Monday 2022-03-28 21:01, Sasi Olin wrote:
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
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
You can't grow forever, and, sometimes, less is more. Just because some other Linux distros can brag with ">30k packages" does not necessarily mean they are all up to par. That said, IMO Factory has fewer hurdles for package inclusion than e.g. Debian. But also more than build-script-only distros, because our packages need to successfully build regularly. Perhaps we have already hit the sweet spot and just don't know it.
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.) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
"MW" == Martin Wilck <mwilck@suse.com> writes:
MW> Perhaps some weak "review" process could be established around public, MW> inofficial OBS repositories. For example, a bot could auto-uncheck the MW> "publish" flag for repos that haven't seen any updates for a long time, MW> and users setting the "publish" flag could be asked to provide meaningful MW> descriptions for their repos and the packages therein. And why would we want to police the developers in their choice of providing or not providing a meaningful, according to who, description. -- Life is endless possibilities, and there is choice!
On 3/29/22 05:25, Martin Wilck wrote:
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.
Developers need a way to collaborate and develop packages together, this is exactly why we have devel projects (not for users). Sure we could make this "private" somehow but this would be likely doing a disservice to everyone. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
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 -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
On Mon, Mar 28, 2022 at 3:43 PM Stefan Brüns <stefan.bruens@rwth-aachen.de> wrote:
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.
To put it bluntly, we rely on SUSE Linux Enterprise product development for openSUSE Leap. While we have made significant headway in adding the community to the process[1], at the end of the day, it is SUSE's choice on how major and minor version evolution works. Personally speaking, I think SUSE needs to do what Red Hat has done and come out with a fully defined, predictable schedule so that the community and the company can work more effectively together to drive the future for the SUSE Linux family of distributions. To note, starting with RHEL 8, RHEL gets new point releases every six months, and new major releases every three years. RHEL 9 is coming in two months, which is three years after RHEL 8 arrived. I'd love something similar for SLE. [1]: https://code.opensuse.org/leap/features -- 真実はいつも一つ！/ Always, there's only one truth!
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 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 :-)
The submission and review process and its bots aren't everybody's best friends. Going into details would be really OT...
Amen :-)
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?
This is a sensible question to ask IMHO. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
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. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
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. Martin
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. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Tue, 2022-03-29 at 12:10 +0200, 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.
Martin
We have a standard for the latter...they're called devel repos and they exist to funnel packages into Factory/Tumbleweed. We dont have a standard for the former.
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 -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
On 3/29/22 08:16, Martin Wilck wrote:
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?
As a project we have always been open to everyone's contribution if they believe it maybe useful for other people. Maybe we could go to a "Module" approach where we have a series of repo's but how far do we go with this? we could have some kind of vague "Core" and "Extra" but chances are almost everyone will eventually find something they want in extra so will enable it anyway. You could take it further and maybe split more based on patterns so you have a number of repos ie you could easily make the case that Gnome and KDE could be there own repos because lots of people use one or the other. But in this kind of setup other then minimal servers most users are going to end up with a large number of repos and I suspect from experience that getting zypper to refresh 5-6 repos with much smaller metadata will still be slower then refreshing one repo with all the metadata. This is an interesting discussion to have every now and then though because maybe we could do things better here. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
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 ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Dienstag, 29. März 2022 00:06:22 CEST Stefan Seyfried wrote:
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.
You are apparently referring to: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/ ZN26H5IRDHZMRRTC2IIKMSA5JMXJVILA/ "I, as someone who takes some pride in its packages, refuse to create such a braindead changelog." You could have copied the changelog from your mail, and would have been done with it. So where is the huge amount of extra work you are referring to? You state you like clean packages. Thats good. Lets check https://build.opensuse.org/package/view_file/home:seife:vdrdevel/vdr/vdr.spe... expand=1 --- BuildRoot: %{_tmppath}/%{name}-%{version}-build ... %if 0%{?suse_version} >= 1220 ... --- Does not look very clean to me, also the inconsistent mix of tabs and spaces. And according to the changelog, actual cleanups were only done by regular factory contributors. So for me it looks like you are just pulling some straw-man here, and are exaggerating minor issues.
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 ;-)
Of course bots are stupid, but the rules are not. In this specific case, it might have been somewhat annoying, but the problem was easy to fix. In many other cases, I have seen the bots catch nontrivial problems which slipped through review by several humans. So, given the trade-off, IMHO the bots are very worthwhile. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
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 -- Atri Bhattacharya Mon 28 Mar 21:24:55 CEST 2022 Sent from openSUSE Tumbleweed on my laptop.
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? /Syds
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…
On Montag, 28. März 2022 22:43:08 CEST 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. It's not about a discussion which packages a user is allowed to use and what not.
One major problem of s-o-o is it is not working as intended. And with the current setup of projects it is almost impossible to fix it.
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.
When s-o-o only takes the packages from the official repositories it becomes significantly easier to implement correctly, and every Leap installation becommes significantly more robust. If you add more or less random repositories to your system, sooner or later you will run into trouble. So this discussion is completely on topic: How do we provide a consistent set of packages to openSUSE users, and make it discoverable. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
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
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, -- Atri Bhattacharya Thu 31 Mar 00:07:47 CEST 2022 Sent from openSUSE Tumbleweed on my laptop.
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,
On 3/29/22 04:37, 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.
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.
This sounds far more complicated then encouraging people to submit there packages into official distro's, modifying the publish flag will also cause significant issues for developers who need to test there packages. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
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. -- Per Jessen, Zürich (16.2°C) Member, openSUSE Heroes
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.
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 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?
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? 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. If I name my repos openSUSE_Leap_15.3/15.4 a search returns no hits. 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. Regards Eric
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?
Am 26. März 2022 07:05:58 MEZ schrieb Andrei Borzenkov <arvidjaar@gmail.com>:
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.
That may be your opinion. I think it is. Because it is a way to get software. A lot of things can only be found there. Also much which is bugfixed to the Devel repos. Or a lot for Leap which is otherwise only available for Tumbleweed and requests for bug fixes regarding Leap are simply rejected. Devel repos are not the ultimate.
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?
Because then I would like to point out in which direction to look. And the arrays and hard coded things reinforce that. And, do you can read? Or only read that what you wan't? I wrote: a) If I name my repos openSUSE_Leap_15.3/15.4 a search returns no hits. b) If I rename the repos to 15.3 and 15.4 I get hits on a search. Regards Eric
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 23.03.2022 16:30, Martin Wilck wrote:
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.
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. And of course relation between distribution and "third-party" repositories is pure ad-hoc. We assume that is repository contains "Leap_15.3" string it is for Leap 15.3 but that is pure convention not formalized or enforced.
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 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 24 Mar 2022 10:02:23 AM CDT, Martin Wilck wrote: <snip>
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.
Hi Martin But osc command line tool (it has a search option) and for a GUI there is already qactus? -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) Tumbleweed 20220322 | GNOME Shell 41.4 | 5.16.15-1-default HP Z440 | Xeon E5-2690 V3 X24 @ 2.60GHz | AMD RX550/Nvidia Quadro T400 up 3 days 13:29, 2 users, load average: 0.77, 0.62, 0.39
On 3/25/22 01:17, Martin Wilck wrote:
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.
Well i'd put yast and maybe zypper in this category, if they don't show up there they aren't officially supported and so i'm not convinced that it should be really easy to install them. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
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 -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson
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.
And as usual, once you are going about it, you will find many people being able to help you. Even if it's hard :-)
I hope you're right... so far, it doesn't seem to have taken off, but maybe that's because noone was really "going about it" the way you envision. Martin
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.
On 26.03.2022 08:52, Andrei Borzenkov wrote:
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.
While updating distribution ID does show packages for Leap 15.3 (including third-party projects with openSUSE_Leap_15.3 repo :) ) it is still hopelessly incomplete. Generated links to repo or direct downloads are simply wrong, like https://build.opensuse.org/package/show/openSUSE%3ALeap%3A15.3/patchinfo.212... to official package (does not exist because actual location is SUSE, not openSUE) https://download.opensuse.org/repositories/SUSE:/SLE-15-SP3:/Update/pool/x86... (does not exist because actual location is openSUSE, not SUSE) The version listed does not match generated link (it shows version for patchinfo.21281, but generated link is for patchinfo.20489). It does not realize that it found update and presents it as "official release". It presents direct download links for SUSE instead of openSUSE (well, personally I think this is more OBS issue because native OBS GUI does the same. Again, response of OBS maintainers - not a bug).
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 -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson
On 3/29/22 01:59, Henne Vogelsang wrote:
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*.
Yes thanks for your contribution.
The lesson learned - software.o.o cannot be maintained by external volunteers alone. 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...
Yeah openSUSE is a complete volunteer project, sure some of those volunteers such as myself are paid by a company to work on certain things but really that is a company volunteering time. The openSUSE Project has no bank account or resources to work on anything so for things like this the project really does depend on volunteers such as yourself. 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. But they do that as equal volunteers with everyone in the community for the most part. So if people like you don't step up and help then often things simply don't happen. Without changes to our legal structure and alot of additional sponsorship its not really possible for the project to have a group of people working on things that the project thinks are important but that no one is stepping up to take care of. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
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, 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. -- Richard Brown Linux Distribution Engineer - Future Technology Team SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev
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
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. Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson
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. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
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. Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson
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. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
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. Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson
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 Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
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. On Wed, Mar 30, 2022, 7:23 AM Simon Lees <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
Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
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
-- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
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. On Wed, Mar 30, 2022 at 8:17 PM Simon Lees <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>> 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
-- Simon Lees (Simotek) http://simotek.net
Emergency Update Team 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
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
-- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Hey, redirected to project@ as this the more appropriate list for me to rant about community building :-) On 30.03.22 13:23, Simon Lees wrote:
On 3/30/22 20:59, Henne Vogelsang wrote:
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?
Sure not. And if you can't you can't. Your time, your decision. But you are not the only person in this crowd :-)
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?
This is a well established, written about, even researched topic. There are tons of things we can do "passively" for our projects. And by projects I don't mean openSUSE as a whole. I mean all the building blocks that make up openSUSE. The teams, the software projects, the distribution etc. - clarify *what* we want to achieve. What are the priorities? *Who* is the priority? - establish contribution guidelines - clearly express roles and responsibilities - clearly express how we do conflict management - document the path to leadership - clearly express areas/problems that need attention - establish onboarding practices for new contributors - establish mentoring practices for contributors - establish decommission practices (something isn't salvageable, get rid of it!) - establish successor practices (people leave all the time) So help existing openSUSE maintainers/projects by setting up a golden path to follow for maintainership. Basically define what is openSUSEs shared understanding of how FOSS projects are supposed to be if they are part of openSUSE. Once the "passive" things are under control you can go out and be active about attracting people to projects. - Practice running projects to our standards - Practice mentoring & onboarding - Ask *people* you think will be a fit personally (best thing to do) - Hook into the existing mentoring programs - Events - Shouting to the public via blogs, social media, podcasts etc. This isn't something we are alone with. *Every* healthy FOSS community does this. There are whole communities about building communities! Books, events, guides etc. https://lists.freedesktop.org/mailman/listinfo/foundations https://chaoss.community https://github.com/maintainers https://sustainoss.org https://opensource.guide/best-practices https://foss-backstage.de https://communityrule.info Working in Public by Nadia Eghbal The Art of Community by Jono So there is, as usual, just a shitload of things to learn and to do. And also as usual: A crowd (like this one here) will not collaborate. Some people out of the crowd will be interested. And only a very small amount of those interested will actually be able to do it. And *those* are the openSUSE community. We need to be more efficient in turning our crowd into a community of maintainers. Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson
"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!
Hi Henne, a community of maintainers requires also the correct leadership. The last sureveys had (not published) content by multiple community contributors with "reasons" for this situation.
Gesendet: Freitag, 01. April 2022 um 16:50 Uhr Von: "Henne Vogelsang" <hvogel@opensuse.org> An: project@lists.opensuse.org Cc: factory@lists.opensuse.org Betreff: How to build a FOSS maintainer community (Was: Planning decomission of software.opensuse.org)
Hey,
redirected to project@ as this the more appropriate list for me to rant about community building :-)
On 30.03.22 13:23, Simon Lees wrote:
On 3/30/22 20:59, Henne Vogelsang wrote:
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?
Sure not. And if you can't you can't. Your time, your decision. But you are not the only person in this crowd :-)
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?
This is a well established, written about, even researched topic.
There are tons of things we can do "passively" for our projects. And by projects I don't mean openSUSE as a whole. I mean all the building blocks that make up openSUSE. The teams, the software projects, the distribution etc.
- clarify *what* we want to achieve. What are the priorities? *Who* is the priority? - establish contribution guidelines - clearly express roles and responsibilities - clearly express how we do conflict management - document the path to leadership - clearly express areas/problems that need attention - establish onboarding practices for new contributors - establish mentoring practices for contributors - establish decommission practices (something isn't salvageable, get rid of it!) - establish successor practices (people leave all the time)
So help existing openSUSE maintainers/projects by setting up a golden path to follow for maintainership. Basically define what is openSUSEs shared understanding of how FOSS projects are supposed to be if they are part of openSUSE.
Once the "passive" things are under control you can go out and be active about attracting people to projects.
- Practice running projects to our standards - Practice mentoring & onboarding - Ask *people* you think will be a fit personally (best thing to do) - Hook into the existing mentoring programs - Events - Shouting to the public via blogs, social media, podcasts etc.
This isn't something we are alone with. *Every* healthy FOSS community does this. There are whole communities about building communities! Books, events, guides etc.
https://lists.freedesktop.org/mailman/listinfo/foundations https://chaoss.community https://github.com/maintainers https://sustainoss.org https://opensource.guide/best-practices https://foss-backstage.de https://communityrule.info Working in Public by Nadia Eghbal The Art of Community by Jono
So there is, as usual, just a shitload of things to learn and to do.
I want to recommend an additional book for our openSUSE Board. "In The Open Organization Leaders Manual, a community of open-minded writers, consultants, speakers, and educators explains how those same open principles can help leaders refine their approaches to setting goals, building organizational cultures, and motivating teams." https://opensource.com/open-organization/resources/leaders-manual The Open Organization Leaders Manual is something what is necessary now. We are living all open principles in the FOSS community and with that at openSUSE.
And also as usual: A crowd (like this one here) will not collaborate. Some people out of the crowd will be interested. And only a very small amount of those interested will actually be able to do it. And *those* are the openSUSE community.
We need to be more efficient in turning our crowd into a community of maintainers.
Henne
Best regards, Sarah
-- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson
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/
Gesendet: Sonntag, 03. April 2022 um 19:33 Uhr Von: "Sasi Olin" <hellcp@opensuse.org> An: "Sarah Julia Kriesch" <ada.lovelace@gmx.de> Cc: "Henne Vogelsang" <hvogel@opensuse.org>, project@lists.opensuse.org, factory@lists.opensuse.org Betreff: Re: How to build a FOSS maintainer community (Was: Planning decomission of software.opensuse.org)
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.
The topic in this book is Open Leadership. Everybody can read it if you are interested for this topic. 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 P.S. Sorry, that I have specified the openSUSE Board. That should be a hint, that it should be a "must read" for the, That is a "can read" for all the others in the community.
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
Gesendet: Montag, 04. April 2022 um 10:29 Uhr Von: "Richard Brown" <rbrown@suse.de> An: Kein Empfänger Cc: project@lists.opensuse.org, factory@lists.opensuse.org Betreff: Re: How to build a FOSS maintainer community (Was: Planning decomission of software.opensuse.org)
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.
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.
Regards,
Richard
Regards, Sarah
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"
Gesendet: Montag, 04. April 2022 um 12:05 Uhr Von: "Richard Brown" <rbrown@suse.de> An: "Sarah Julia Kriesch" <ada.lovelace@gmx.de> Cc: project@lists.opensuse.org, factory@lists.opensuse.org Betreff: Re: How to build a FOSS maintainer community (Was: Planning decomission of software.opensuse.org) Thanks for your feedback, maybe the below will clear up where I'm coing from.
Thank you! It is nice, if both sides are accepting feedback.
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.
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." 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? We need exactly such people and such a situation. We had less candidates during the last election. If I am watching around in different areas, the Global Localization Team (as an example) is without any Coordinator at the moment. Who is executing the "Exponential Leadership" to make contributions to openSUSE fetching and who should be responsible for that (in your opinion)?
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.
The Board is elected by the community. The book The Open Organization is also describing, how people with reputation can grow in such roles. My own Manager (in the company) is saying: "With freedom comes responsibility" Therefore, you are receiving responsibilities, if you are contributing on a good way. Then connect that with the cite above.
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"
That is one reason, that I said "Thank you!" to you above. Best regards, Sarah
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
On Tue, 2022-03-29 at 13:59 +0200, 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.
In what sense? Financially? In terms of developer resources? Can you provide any reasoning for this strong statement? So far I thought that openSUSE, in particular Factory, is a valuable asset for SUSE in various ways.
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.
You don't attract contributors by calling out for them. You attract them by creating an interesting project, where contributing is fun and rewarding for people with a variety of skills, actually more fun and more rewarding than contributing to other projects. This doesn't happen out of the blue. If SUSE wants the project to thrive, it has to invest in it. Martin
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 -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson
On 3/30/22 02:18, Henne Vogelsang wrote:
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.
I'm not going to disagree that SUSE already does a huge amount here, it also brings a bunch of benefits for SUSE :-)
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.
On the other hand, I think this is a pretty unfair thing to aim at people such as Martin, yourself and others who already spend huge amounts of time working on the project and have to already make tough decisions about where they spend there time. There is nothing wrong with realising that you are at the limit of what you can do yourself and ask others for help. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
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. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 28.03.2022 18:29, Henne Vogelsang wrote:
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? :-)
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. Anyway, I guess it would have taken you less time to simply commit this update than merge PR if you think it is worth it, but for the sake of playing with gh ... https://github.com/openSUSE/software-o-o/pull/1167
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
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 -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson
On Tue, 2022-03-29 at 14:13 +0200, Henne Vogelsang wrote:
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.
Thank you, Henne, and I fully agree. I see that the discussion itself, raised so much interest and willingness to help that I have not seen from the community in a long time.
Henne
-- Best regards Lubos Kocman openSUSE Leap Release Manager
Hey, On 29.03.22 16:30, Andrei Borzenkov wrote:
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.
You are to humble :-) It did not work before, it works now. Additionally the cause of the problem is better known now, recorded and we can discuss it further. This is how things progress... Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson
Hey, On 17.03.22 22:05, Lubos Kocman wrote:
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.
Alright, alright, I'll take a look.... Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson
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? On 3/17/22 17:05, Lubos Kocman wrote:
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.
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. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
participants (39)
-
Andreas Schwab -
Andrei Borzenkov -
Atri Bhattacharya -
Bernd Ritter -
Bernhard M. Wiedemann -
Carlos E. R. -
Dan Čermák -
Dominik Heidler -
Emily Gonyer -
Eric Schirra -
Eric Schwarzenbach -
Henne Vogelsang -
Jan Engelhardt -
Jason Craig -
Lubos Kocman -
Ludwig Nussel -
Malcolm -
Marcel Kühlhorn -
Martin Wilck -
Martin Wilck -
Neal Gompa -
Nicolas Formichella -
Patrick Shanahan -
Per Jessen -
rbrown -
Richard Biener -
Richard Brown
-
Sarah Julia Kriesch -
Sasi Olin -
Scott Bahling -
Simon Lees -
sp1rit -
Stefan Brüns -
Stefan Seyfried -
Sy retia -
Syds Bearda -
Togan Muftuoglu -
toganm＠dinamizm.com
-
Vojtěch Zeisek