On 2023-04-25 22:23, Robert Schweikert via openSUSE Factory wrote:
Hi,
On 4/24/23 08:33, Richard Brown wrote:
Lubos' suggestion in particular really will require broad support from lots of groups within the community, including
- Maintenance - QA - All the teams behind the Desktop stacks wanting to be included (KDE, GNOME, et al) - And possibly most devel project maintainers, depending on details like the cadence of forking from Tumbleweed, they could find themselves needing to maintain versions in this openSUSE ALP "old Leap" for some years (I'd estimate upto 5), and not be able to benefit from SUSE's work in this area as they did with SLE+Leap because ALP will likely often most such things containerised.
Therefore it would be really nice if people from the above groups, either individually or with one person speaking for the whole teams, could speak up and let us all know how they feel about this proposal, so we can get a better feeling about how viable it may be.
Well ultimately I think we just have to see what itches people want to scratch when the time comes. Unlike in the corporate setting where things are driven by customer asks, and as was pointed out in this thread, that's not how it works in the community.
Said a different way, developers will join projects that build ontop of/from ALP or projects that avoid ALP if they have an itch to scratch. Then we'll see which projects build momentum from a dev perspective and we'll see which projects gather users.
I do not disagree, but your views highlight an inherent tension between grand-plans like the one shared by Lubos and the reality of the "itches people scratch" model. There's a lot of work that needs to be done to create an environment where people can just dive in and scratch their itches. With Lubos and Dominiques team we have a good chunk of that - we can trust they are going to Release Manage whatever the community decides to build. But who's going to handle maintenance updates? We're going to have a lot more packages that aren't co-maintained by SUSE with this grand-plan, so who's gonna do that work? Will we have enough people to do manage the maintenance process like Leap/old openSUSE, or do we need to think of a newer process that fits with the people we do have to do it? What about QA? Lubos' grand-plan calls for a product as broad as Leap, so I assume we need testing as broad as we have for Leap. But we won't have an overlap with what SUSE are doing for ALP QA. So who's going to do that work? Or do we change what/how we do QA to fits with the people we have to do it? Hence my general call for feedback here.. I'm pointing out that Lubos' suggestion, while clearly appealing for our userbase, has some pretty obvious itches that will need to be scratched to make the concept viable. I'm trying to get a feeling as to whether we have those scratchers at the ready, waiting in the wings, or at least somewhat interested in the concept. Else we need to adjust the plan into something viable for what we've got, so we can keep offering platforms for any ol contributor to roll up and scratch whatever itches they like. I think it would be bad to just accept Lubos' idea as golden and go charging forward, setting everyone's expectations higher than we have any reasonable chance of achieving. Speaking from experience, it can be a bloody mess disentangling a project once it's led into such a hole :) So please, folk, especially Maintenance, QA, Desktop packagers and devel project contributors (especially of core componants), please speak up. We need to know what you think of this :) -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman