Page 1 of 24 12311 ... LastLast
Results 1 to 10 of 233

Thread: One (big) reason Ubuntu's release cycle is flawed

  1. #1
    Join Date
    Jun 2008
    Beans
    44

    Proposal: Alternative release cycle for "mainstream" users (vs. existing flaws)

    The idea is simple in words, requires a slight shift in priorities, but is nonetheless profoundly relevant to the realization of desktop Linux for the mainstream. I present a somewhat novel but circumstantially compelling proposal for a revamped Ubuntu release cycle that should prove especially attractive to one of Ubuntu's most highly sought-after demographics -- the "mainstream" computer users:
    Stable base + rolling stable user software + optional system backports (kernel, modules, etc as required for new/unsupported hardware).
    Before you hit that reply button with "been there, done that", "impossible", or another misunderstanding, consider at least the very first few points:
    • Although this proposal gives some personal examples, I am advocating for my proposal on behalf of everyone, but with heavy emphasis on "mainstream" computer users, to be defined below.
    • I define "mainstream" user as the average computer user who knows little to nothing about Linux and Ubuntu, but becomes willing to try Ubuntu. They may have purchased a computer with Ubuntu (from Dell, eBay, or a friend), or had it completely set up for them by a techie/friend/enthusiast/vendor. It can also apply (but a bit more loosely) to individuals unfamiliar with linux but savvy enough to install it themselves from a CD without encountering [m]any problems.
    • This is NOT a proposal to mimic any "rolling" distro (Arch, Debian testing, etc). This is NOT a proposal for an "over-stable" distro (Debian stable). This is NOT advocating, glorifying, or supporting Windows, BSD, or any other operating system mentioned by way of comparison.
    • This is a post for Ubuntu, the developers and community (including tinkerers), on behalf of Ubuntu and mainstream computer users as previously defined (and also on behalf of developers and tinkerers as I outline later, but to a much lesser extent).
    • Although this proposal espouses certain concepts to some extent loosely resembling the release system of Windows, Mac, and PC-BSD, it in no way advocates for a similar implementation for Ubuntu on either a technical or user level, but simply that some concepts used by other operating systems can prove immensely beneficial to Ubuntu as well, without sacrificing much of anything as explained below.
    • I chose Ubuntu for the subject of my proposal because it enjoys the greatest level of user-friendliness, community, development drive, and completeness in terms of a stand-in operating system alternative/replacement for the "mainstream" defined previously. That is, it currently comes the closest.
    • Based on very extensive personal involvement with Ubuntu installations and maintenance for dozens of mainstream computer users, I strongly hold (and will attempt to prove and certainly discuss) that this proposal makes great strides toward significantly alleviating many remaining barriers to this end.
    • I elucidate the surprising and unconventional notion that many current problems with Ubuntu are actually inherited from, exacerbated, related to, or even caused by Ubuntu's biannual release cycle -- an indirect correlation that is NOT altogether-self evident.
    • By the same token, however, I do NOT attempt to blame all of Ubuntu's problems on the release cycle. The vast majority of its current issues have proximate causes that have nothing at all to do with the release cycle -- but even for some of these, their ultimate manifestations arise in no small part as an indirect result of these very cycles.
    • The proposed system will require greater overall manpower to maintain any given release. However, I contend that this manpower should be reallocated from the current "from scratch"-type biannual release (biannual Debian unstable import) in favor of redistributing this existing manpower to maintaining a long-term release, but without the evolutionary drawbacks expected from an LTS-only ("Debian stable"-type) approach under the current biannual system.
    • Under the proposed system, testing for each long-term base release is expected to be somewhat (if only "slightly") more productive, especially after a release is made (which is when the most people actually use it). This will not only promote greater initial stability due to fewer interim releases and longer developer and tester focus on each, but will also prominently feature increased stability over time in the form of point releases (much like the current LTS). This will allow for more developer effort, testing, and resource allocation within each single release, which may/will increase the overall quality of that release and will certainly free up manpower for the purposes of maintaining the proposed system.


    That out of the way, here is the proposal in earnest. I may add on or rephrase some segments as input is received and the proposal progressively fleshed out.

    • "User software" (as distinct from "system software") is defined as user-space applications such as GIMP, OpenOffice, Firefox, and many installable applications that do not directly interface with the hardware. The integral underlying components which comprise the functional framework of the system constitute "System software" by way of contrast.
    • Each of the three core points below is subject to the conditions and details expounded in the corresponding "point #" that follows.
    • Core point #1: That the base of an Ubuntu release remain stable in terms of system software, that this base be supported long term without biannual releases.
    • Core point #2: That user software be kept up to date and supplied on an adaptive "rolling" basis. This may be rudimentarily construed as a very heavy emphasis on the "backports" (a misleading term in this case) of said user software. In other words, within any given release, the latest stable versions of user software should be made available in a timely manner as stable feature releases are released upstream.
    • Core point #3: That hardware compatibility be maintained and critical hardware-related bugs fixed at the user's discretion (or automatically in critical cases, subject to the competence of the hardware detection); and that such hardware support is provided via optional "system software" backports as made available by similar technical means as they are today in LTS releases, but with the additional comprehensiveness derived from the slower release frequency and the increased manpower resultant therefrom.
    • Point #1A: This base can be technically similar to a well-tested Ubuntu LTS- or Debian-style base as evidenced in existing non-rolling distributions. This is similar to what Ubuntu already does, especially in regards to LTS releases. Benefits of a solid base are effectively self-evident, and the comparative (though still limited) popular success of distributions is ample testament to this reality.
    • Point #1B (Core release cycle): The next distribution of Ubuntu, replete with an updated stable base and attendant long term support, might viably correspond to the earliest of the following options: a certain set maximum support time, similar to the current LTS; "polished, unequivocal readiness" of the next stable base, similar to Debian; or, most novel but arguably most practical for such a proposal, that the new base simply be released once it becomes unfeasible or sufficiently impractical to warrant continued backports. This latter case occurs most obviously when most new drivers and modules are built solely for a kernel and xorg that both recently underwent sweeping architectural changes in critical areas for which backporting is impossible to an older system. This is due to second-order core interdependency webs (e.g. kernel removes EXA acceleration + new xorg no longer supports it + and all new drivers are built on UXA/Gallium3D + new libs now required by new software to take advantage of new mesa functions + new hardware came out that only uses UXA/G3D). For smaller interdepency webs, it's still a tenable proposition, of course (I've run xorg-edgers with bleeding edge kernel, intel driver, and xorg on an older Ubuntu system).
    • Point #2A (Implementation): Use majority of manpower freed up from biannual releases and repository space freed up from supporting 7+ Ubuntu versions concurrently. Create new repositories/software sources to manage software versions analogous to current system: "Software-Testing" repo houses point releases (e.g. KDE 4.6.X, LibreOffice 3.3.x) before they're pushed to the default "software-stable" repo; "Software-Upstream" houses latest stable upstream release (similar to "backports" but actually updated and exclusive to "user software"); provided enough time, even a "software-beta" repository can be set up akin to OpenSuse's myriad "testing" repositories for development/beta software, though this particular repo certainly isn't required for this proposal to be effective. Few packages truly require updated shared libs for a long time (most of the time such nominal "requirements" are an artifact of an updated build framework) and can be compiled perfectly even within the existing 'backport' guidelines, only in a more automated fashion. Select problematic software can simply be compiled with static libraries or delivered with coexisting updated ones, in which case the update manager should be made aware of the coexisting lib versions and deliver updates for both (similar to managing two xulrunner.so libraries for firefox-2 and firefox-3 simultaneously in Hardy). If the static build option is espoused instead, the build system itself should automatically poll the all linked/internal libs for security updates, rebuild all affected packages with any updated static libs, and push the package as a whole (or as a delta file) to the update-manager. Finally, to polish off the implementation, a simple UI for updating (or downgrading!) only select packages between these official repositories would complete this ideal "parallel" repository setup for the mainstream user and anyone else. This way, if a user regrets an upgrade decision (for single or multiple programs/packages), the option to downgrade to the version in another repo should exist graphically (all the way down to a "Software-Stable", the default). That is, if Joe doesn't like the new version of a relatively standalone program after enabling "software-upstream", he can open the software center (or the simple UI) and easily roll it back.
    • Point #2B (Benefits):
      • User discretion can be taken into account if a program update is undesirable for whatever reason (as implemented).
      • Manpower can be spent automatically polling for new versions of user software rather than letting software stagnate (with any existing bugs or deficiencies) or sporadically building them "on request" as the current backport guidelines specify -- this change means the "mainstream" will actually receive these updates.
      • Many examples of upstream software contain bug-fixes and feature enhancements that are critical for continued use of the software in the modern world (e.g. inter-compatibility, OpenOffice docx form support, GIMP's bezier curve model, new multimedia formats, fixed a/v decoders/players, wine feature/bugfix releases)
      • Ubuntu's acclaimed software update system will now also be more competitive with other operating systems in which software "auto-updates" to the latest versions, while retaining all the benefits of Ubuntu's software management.
      • Better solution than PPA's for interim software updates:
        • The "mainstream" may or may not be comfortable with PPA's in the first place, or fully understand the risks (I learned the hard way).
        • Retain Ubuntu's community testing, support, and patches.
        • PPA's are notoriously buggy, often ill-maintained, may be vulnerable to security holes, may break future official updates, often aren't built with Ubuntu patches, optimizations, and testing, and may be incomplete (e.g. Lucid LibreOffice PPA doesn't contain KDE integration, Firefox 'nightly' pull is unecessary DE-specific dependencies and incorrect branding/integration, vlc isn't compiled with the same optimizations as stock, making it a bit slower, etc).
        • PPA's may break distribution upgrades (upgrading to a distro featuring VLC 1.1.7 when your PPA is on 1.1.8 can mean app breakage, and xorg-edgers to a new distro's Xorg can mean distro breakage)
        • Fully supported upgrade path. Users needn't find and re-enable each PPA again (which many 'mainstream' users don't/won't/can't figure out in the first place if the system came with PPA's enabled by manufacturer/techie/other) or worry about discovering that a PPA for the upgraded distro doesn't exist due to distro changes (which could make a user lose essential functionality after the upgrade).
      • Creates uniform environment for reporting and fixing bugs.
        • One distro with only a few 'official' versions of software to support means much less "debugging noise" caused by what distro/version was used.
        • More people using the same base and software version equates to more reproducibility for users and devs alike.
        • Because one stable distro updates to the latest stable upstream versions of user software, there's much less redundancy in bug reports, and developers would have much more specific and up-to-date information, with the additional end result of software being fixed more quickly easily
        • Users don't have to wait until a new distro to report bugs with the built-in bug reporter tool. This means Ubuntu developers and trackers won't suddenly be inundated with repeated 'user software' bugs whenever they're focusing on making a new Ubuntu base (or worse, developers being forced to deal with all the bug reports that flock in immediately after every release, which require further sorting into 'upstream software bug', 'ubuntu bug', 'default configuration/environment bug', 'bug in software only relevant to use in Ubuntu'). Software will be better maintained before and after release, allowing developers to focus on the next stable base rather than wading through noise.
    • Point 3A: The optional/critical-only "system software" backports can be provided as backported wifi/sound modules, entire kernels, etc as they are today with Lucid LTS, but enjoying all the benefits of concerted developer support/attention. Updated Xorg components can be provided similar to those in the xorg-updates PPA, but able to reap the additional benefits described for "user software" in point #2B above. In terms of automating this process, the hardware detection wizard can be improved to poll the hardware and offer to safely (and reversibly!) install just the backported components necessary to support a specific piece of new hardware for which there is known issue. The polling can take place upon detection of new hardware or at install time. The setup could be quite similar to the "proprietary driver" manager with a hardware 'definitions' file that updates along with the rest of system. This program can perform recovery if an installation fails, in addition to allowing the user to backtrack if an installation fails or doesn't work as well (a sort of friendly automated 'apt-get remove linux-backports-modules-XX') simply by unchecking the appropriate backport in the GUI.
    • Point 3B ("pseudo-rolling" hardware support): Additionally, these up-to-date "system software" backports can be included with the default CD and LTS-style point releases such that a completely new computer or completely new hardware can instantly be detected, the proper required backports loaded from the CD, and the computer set up without the need for any additional download or setup. Distribution point releases can stand in for biannual releases in supporting the latest hardware from the getgo via this backports-on-CD "pseudo-rolling" method -- just as an up-to-date system of the very first (point 0') release would offer the same hardware detection and optional "system software" backports.
    • Point 3C (Benefits to this hardware approach):
      • The "mainstream" is not presented with a potentially problematic distribution upgrade (settings/proprietary-driver/PPA reset, or worst case, breakage). My extensive experience with dozens of "mainstream" Ubuntu converts, in addition to polls on these forums, indicate that the upgrade process is still significantly far from perfect, and there is a possibility of encountering problems with each distro upgrade -- with an 80% total magnified possibility of encountering difficulty after 4 upgrades -- that is, in just 2 years -- assuming a 2/3 chance each and every upgrade goes perfectly. Many users think it's just a standard system update and are unprepared for the consequences, whatever they might be, not to mention incapable of fixing what you or I might consider the simplest and most forgettable glitch. Of course, downgrading after a distro upgrade is virtually impossible at this point without use of commandlines and significant expertise.
      • Users won't be forced to resort to PPA's and/or entire distribution upgrades to get helpful (and sometimes critical) software updates; see above under Point #2b.
      • Allows the mainstream to avoid upgrade inconvenience/trouble (for the life of the machine in many cases), including the following scenarios:
        • Package breakage might occur, drivers not function properly, or the system may not boot (extreme case)
        • Some functionality might lose support after an upgrade: desktop effects not work, accelerated video not work
        • Some hardware is entirely unsupported, but the update manager (and of course the "mainstream user" who probably trusts his system/update manager!) has no way of knowing this (e.g. Poulsbo chipsets, some webcams, sound stops working on hp laptops)
        • Custom configuration, settings, and workarounds from both "mainstream" AND "seasoned" users are lost (e.g. added line to /etc/hosts to fix LibreOffice startup lag, line added to /etc/modprobe.d/alsa-base.conf to fix speakers playing on headphone insertion, fix for the hardware wifi notifier blinking on HP laptops [finally fixed in Lucid but broke again in Maverick&Natty], fix Flash audio in Firefox under Kubuntu or Flash player video performance again, fix mic problem in Google chat in the browser, etc). These are tiny breakages not noticed at first by anyone, but only become apparent in time with use -- and are dismissed in seconds by tinkerers and the savvy/dedicated/experienced. In terms of the mainstream, any tweaks these advanced users/distributors/techies/vendors painstakingly set up within a system would vanish, and they'd receive an influx of disillusioned complaints and demands for support after an upgrade that seemed at the time to have been "flawless" but again shows whatever flaws or misbehaviors that had been meticulously controlled for in the first place.
        • A sudden, near-gigabyte download of data and an entire hour (or a lot more on slower connection) of both the download and installation process every six months, in addition to the bugfix releases that swarm in for the first few weeks after release.
    • Core Benefit: Provides all of the benefits stated above and more, and avoids "Mainstream" discontent with all of the above issues related to the current release cycle (dated software until potentially risky upgrade, frequent large upgrades, insufficiently tested releases/software/PPA's, fluctuating levels of hardware support over time, bugs that come and go -- the coming part, specifically, is the major qualm after an upgrade, reset user/installer/vendor settings).

    There you have it. A proposal for a release cycle that may well solve problems the tinkerer might never have cared about (or even remembered exist), all of which nevertheless cripple the usability of Ubuntu as a serious alternative to mainstream computer users with accordingly mainstream computers and levels of computer aptitude. Ubuntu is doing a fantastic job with everything from its interface to its program selection to its hardware support (however finicky or rapidly fluctuating that support may be from one release to the next). Perhaps a good number of the remaining hurdles to large-scale adoption can be resolved, no matter how indirectly, from a careful reevaluation of the release cycle in light of the very same "mainstream" interests. With increased quality and stability may also come a reduction in the various modes of crippling fragmentation that conspire to divide users, developers, and interest groups even within the same operating system -- an entity known simply to the mainstream as Ubuntu.

    (Side note: there are many, many other arguments that have been made for longer release cycles. For instance, longer release cycles can also mean better proprietary driver support, as companies are more willing to invest the time and money into making a driver that will last longer than a few months; or from another perspective, companies already involved could potentially invest more into stabilization than rushing to support whatever new kernel and Xserver would surely redefine the playing field in those mere few months. There have also been arguments for a shorter release cycle along such lines as "synchronization with free software trends" and "increased pace of core development and creativity", but whatever conveniences such reasons would at first seem to afford such a rapid release cycle appear to be dwarfed by quality and usability concerns by the mainstream. But I digress.)
    Last edited by LifeTheHound; March 24th, 2011 at 11:01 AM. Reason: Re-worked from the ground up. Let there be no more misunderstandings!

  2. #2
    Join Date
    Jun 2010
    Location
    asoko
    Beans
    834
    Distro
    Ubuntu

    Re: One (big) reason Ubuntu's release cycle is flawed

    no, not really, but no time to expound. ultimately the op is only worried about his own situation.

  3. #3
    Join Date
    Jan 2007
    Beans
    Hidden!
    Distro
    Ubuntu Development Release

    Re: One (big) reason Ubuntu's release cycle is flawed

    Thread moved to Recurring Discussions since it isn't really a request for support.
    New to Wayland.

    Retired.

  4. #4
    Join Date
    Jun 2008
    Beans
    44

    Re: One (big) reason Ubuntu's release cycle is flawed

    Quote Originally Posted by endotherm View Post
    no, not really, but no time to expound. ultimately the op is only worried about his own situation.
    Well it hurts me, it hurts friends, it hurts everyone. Hardware support is one of the biggest qualms with desktop linux, and this is partly why-- once you get your hardware working, you have to switch distros and start over. At least if you want your software to keep up and stay relevant.

    A lot of people I know dropped linux in general because it was "too much tweaking for too many bugs across too many distros" and it was just too "high maintenence" to keep distro hopping.

    Ad hominem: attacking the person (op) instead of the problem.

  5. #5
    Join Date
    Dec 2009
    Location
    Southern Maryland
    Beans
    1,575
    Distro
    Ubuntu

    Re: One (big) reason Ubuntu's release cycle is flawed

    I get it and I see your point. So long as the kernel can support the dependency changes required for the newer software, why not update packages in the repos for applications along with the updated packages for newer versions of Ubuntu. No reason why 9.04 shouldn't have the same version of OpenOffice if it is a safe assumption that the rest of the distro can support that newer version.

    That's where I believe it could become labor intensive on the packagers. They would be facing package issues on every version of Ubuntu currently supported, which could become an exponential increase in workload. I do not know that for a fact and I wonder if that is the reason previous versions do not keep the latest and greatest of some apps....so the packagers can focus on the current distro versions with the available manpower and hours they have?

    Interesting perspective and insight went into that post and I agree it has great merit if it is something that can be supported reasonably. Being forced to tweak hardware on every upgrade so you have a few of those apps you require would be a pain. I have an HP Touchsmart and every install I have to change its sound settings manually in its modprobe file. Not a major ordeal, but not something I want to do regularly if newer app versions were available in the currently installed version.

  6. #6
    Join Date
    Sep 2010
    Location
    Tejas
    Beans
    29

    Re: One (big) reason Ubuntu's release cycle is flawed

    Well the gods and the mods know, that i'm one to complain, but in all fairness, the real problem with Ubuntu and most linux distros, is that nobody builds computers specifically for linux, they build them for Windoze.

    Yeah I know about Dell, I don't believe for a second that Dell actually built their Ubuntu offerings from scratch design with linux in mind, Dell is nothing more than a parts assembly house manned by monkeys, they don't design squat.

    And yes, I know about Lenovo...pfffft. And HP supposedly has big plans...meh...believe it when I see it, and I still won't be excited, last thing I ever want is an OEM computer ate up with garbage OEM progs and built-in spyware.

    It's amazing in the first place that linux works on any hardware, not because it's not a great system, but because here in merchant-cartel-controlled A-murr-ka it's usually SOP to systematically destroy anyone or anything that's not out to make a buck.

    So the fact that linux ever works at all on consumer desktops and laptops, is quite the testament to LT, and to all the programmers and developers that have ever labored on it's behalf.

  7. #7
    Join Date
    Jul 2009
    Location
    Dayton Ohio USA
    Beans
    1,069
    Distro
    Ubuntu 13.04 Raring Ringtail

    Re: One (big) reason Ubuntu's release cycle is flawed

    Quote Originally Posted by LifeTheHound View Post
    Well it hurts me, it hurts friends, it hurts everyone. Hardware support is one of the biggest qualms with desktop linux, and this is partly why-- once you get your hardware working, you have to switch distros and start over. At least if you want your software to keep up and stay relevant.

    A lot of people I know dropped linux in general because it was "too much tweaking for too many bugs across too many distros" and it was just too "high maintenence" to keep distro hopping.

    Ad hominem: attacking the person (op) instead of the problem.
    Why the need to update a machine that is working perfectly. I have 9.04 system that will stay that way because it is rock solid. SOLID. Yeah it's fun to tweak a new box but I always need something to depend on
    It's okay, I'm a limo driver

  8. #8
    Join Date
    Feb 2010
    Location
    Land of Confusion
    Beans
    8,359
    Distro
    Ubuntu 16.04 Xenial Xerus

    Re: One (big) reason Ubuntu's release cycle is flawed

    I think Canonical's current direction is great. The software on any release can be upgraded with a little work. Expecting Canonical to upgrade the packaging for every supported release along with all of said program's dependencies is just ridiculous.

  9. #9
    Join Date
    Nov 2008
    Location
    Here, There, Everywhere
    Beans
    1,166
    Distro
    Xubuntu

    Re: One (big) reason Ubuntu's release cycle is flawed

    Quote Originally Posted by endotherm View Post
    no, not really, but no time to expound. ultimately the op is only worried about his own situation.
    is that wrong?


    Quote Originally Posted by uRock View Post
    I think Canonical's current direction is great. The software on any release can be upgraded with a little work. Expecting Canonical to upgrade the packaging for every supported release along with all of said program's dependencies is just ridiculous.
    lol, canonical already does it.

  10. #10
    Join Date
    Feb 2010
    Location
    Land of Confusion
    Beans
    8,359
    Distro
    Ubuntu 16.04 Xenial Xerus

    Re: One (big) reason Ubuntu's release cycle is flawed

    Quote Originally Posted by Tibuda View Post
    lol, canonical already does it.
    With some apps, but not all. I was happy to see FF get upgraded from 3.0 in Jaunty.

Page 1 of 24 12311 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •