On 7/11/22 22:19, Robert Schweikert wrote:
On 7/11/22 06:43, Johannes Meixner wrote:
Hello,
<snip>
With our current "all integrated into a whole" method (i.e. with our current "one size fits all" mindset) we (both openSUSE and SUSE) are rather restricted what we can provide to our users and customers.
With new additional "isolated self contained parts" methods we are less restricted what we can provide to our users and customers.
I do not understand what could be wrong in general with more possibilities versus "one size fits all".
In principal there is nothing wrong with more choice. But more choice also means more work.
We understand the work required by the current model, after all it's been practiced for a long time. I don't think there is a generally good understanding of the work required for a new model the builds on basic isolation. In addition this is not an either or choice. If a middle path is pursuit then there have to be some guidelines as to which use cases are better handled with integration vs. isolation. And of course with integration work still needed the question is how much integration work should be done?
Do we build Python stacks for 3.8, 3.9, 3.10, 3.11? How many modules in how many versions of those modules? If none of this is provided by the "base" then those that build things higher up the stack have to take more ownership of their dependencies as they do today. Will that work? Are people willing to do that? Is it worth it for the reward of shipping 1 containment across multiple distros?
There are many questions to be answered....
For SUSE to be interested in this idea I think that its reasonable to presume that SUSE is interested in shipping and maintaining more then one python stack as an example. So its probably reasonable to presume that there will be atleast one python stack provided most likely more then one but certainly once you start to get to the 4 or 5 mark its of less benefit. So I suspect the question for people higher up the stack will be which stack do I choose rather then how much more extra work is it for me. So I think the interesting questions are more in terms of lifecycle, if you kinda look at SLE-15 for what did and didn't work and what people actually want maybe we can get some ideas but also i'm just guessing. There is obviously a group of SUSE customers who value it not changing so you might say that using SLE-15 timelines as the example for 15 GA and SP1 we just have python 3.6 and we are committed to maintaining it for the full 10 year lifecycle because some customers want to pay for it. But then in SP2 we say introduce python 3.8 and support it for a shorter period until the end of say SP5 and at the same time we introduce 3.10 or 3.11 with SP5 to give people who want newer python a period to work with. In my mind thats probably a minimum you'd want to start with (without hearing any actual internal discussions on the topic). But obviously you could take my suggestion and add more take the latest for each SP for example or you could support newer versions for more or less service packs. So I think this is more where the discussion is happening rather then the question of will there be any supported python stack at all. -- 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