Rob OpenSuSE wrote:
2009/1/1 James Tremblay aka SLEducator
: Rob OpenSuSE wrote:
Rather than get hung up on version numbers, and having large scale changes in every release. I presume releases as they stand now, are going to be broken! 10.3 had almost a year, yet was just as bad as 11.1 for me, and with one very problematic kernel update shortly after initial release. So longer release cycle in my view does nothing to improve release quality.
Therefore, I'm presuming it'll always be better to make a stability release 11.1.1 (in effect) which is 11.1 done acceptably right for most users. It sucks if the install ISO's don't get updated, leaving many boxes with boot problems.
I'm confused , it's sounds to me that you are advocating for all users to remain on the same release platforms\schedule. If they choose to avoid the "dev" levels they would have to know which is which.
As many users, who have commented on 11.1 in forum or on the opensuse mail list, as well as "Release Cycle" survey, are asking for more quality, I think some change is desirable. Similarly I'd be happier to buy a box set, if it had decent release notes, and disks that would actually work, and enable getting to the state of the art, rather than a prematurely frozen ISO, which had to be shipped "As Is" thanks to calendar pressures and release politics.
Thus I've been making a case for rapid follow up releases, actually
the real thing, with what now passes for a main release, being a short term product, that however via online update, will be the "solid" version.
As the version numbers for SUSE have long been meaningless, and no indicator of underlying changes to the distro, nor to quality, I'd be happy to have USTS (Ultra-Short-Term-Support) versions given a minor number, rather than the more honestly meaningful, 11.1.0 and 11.1.1.
One attractive feature to me, of your first post, was that the "Solid" release, could be tied into SLE with a predictable version number. It would seem desirable to me, for openSUSE to lead into SLE in some manner, with OS 12 and SLE 12 sharing core versions of things. Having releases move via live update in small steps, and switch paths onto the LTS of SLE on subscription model would superficially at least appear attractive.
Hopefully now it is clearer the assumptions I've been using, when responding.
Maybe I need to be clearer, If the system was that "11 boxed" (aka SLE 12) and openSUSE12.0 where the same ISO (with branding and repo changes)and If I wanted to test, I could install with the 12 iso which had "factory-update" as a repo , then 12.1 could be an update\add-on\upgrade, the same for 12.2, etc, at whatever schedule. "Factory" could be the "devs" repo and provide 12.0.x, etc , until 12.1. I'm suggesting three layers of community; 1 dev, 1 tester , 1 "Joe Plumber". Joe, doesn't have to think much , he goes straight for "boxed" and can stay there until "13 boxed"(or "12 boxed" if he really wants an upgrade), otherwise grab 12.x iso and work with us.
Whilst I'm sympathetic to issues with the reality of supporting SLE in long term (there's a reason I have all the updates from SuSE 8.2 on disk still); I'm not sure it's an issue that openSUSE can solve directly.
What I do see, is that focussing on key major versions, which become inputs to SLE, increase the user base for software used by SLE and would hopefully improve quality, and economies of scale and focus would act to relieve that issue.
Personally I doubt that, building or finding rpm's that would work, is really difficult initially at least, surely it is the implications of LTS for a huge number of packages, where upstream loses interest, that makes only subsets of repositories feasible.
if 11 boxed\SLE12\openSUSE 12 shared all the same code, SLE could have GNUCash indefinitely by having the OBS build SLE packages by default and then make them available in a subscription repo like the NLD9 stuff was or at opensuse so that Novell wouldn't have to support them. My idea tries to get the openSUSE\SLE team to work less and produce more. If we remove the need to provide security patches for the "tester" layer , while always working on the next "boxed",every month could be an "upgrade" release to the testers i.e. 12.0.1-12.0.6. They could then spend time adding security updates to the original installation package code for the end of the month upgrade to testers. (eliminate delta patching at the tester level). In the end 12.3.6 or 9 could be optimized for "12 boxed". Boxed and SLE would get the same security updates as long as boxed was live and then SLE could fork. -- James Tremblay openSIS Product Specialist http://www.os4ed.com CNE 3,4,5 MCSE w2k CLE in training Registered Linux user #440182 http://en.opensuse.org/education -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org