Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://wiki.ubuntu.com/TimeBasedReleases below:

TimeBasedReleases - Ubuntu Wiki

Ubuntu releases on a time based cycle, rather than a feature driven one. Sometimes this can generate confusion, especially when people ask for a new feature to be added. Here are some answers to some common questions regarding how Ubuntu's releases and should answer why your feature request was just put off or turned down.

• There are a variety of strategies for deciding when to release a new version of a piece of software, and different projects may employ different techniques. Ubuntu plans in advance to release on a certain date, and the preceding development effort is aimed at producing a high-quality release on this prearranged date.

  See Ubuntu releases as well as the Releases page for a list of Ubuntu releases and their schedules.

  The Ubuntu release process was heavily influenced by the release process used by the GNOME project. As an analogy, consider a play being produced in a theatre. While things may go wrong during production, even (perhaps especially) on the night, tickets have been sold and there is a very high cost to backing out: "the show must go on".

• Ubuntu releases are challenging because they represent an aggregation of the work of thousands of independent software projects. We feel that a time-based release process enables us to provide our users with the best balance of the latest software, tight integration, and excellent overall quality.

• The relevant deadline is the FeatureFreeze for that release. At that time, development of the feature should be substantially complete, such that the remainder of the release cycle is available for testing and fixing bugs. FeatureFreeze is generally months before the final release, in order to allow for widespread user testing, feedback and bug reports, and for developers to respond to this feedback before preparing the final release. Some guidelines for whether a feature is ready at feature freeze include:

  • Present: new features should, in general, be uploaded to the development branch well in advance of FeatureFreeze. It is important for Ubuntu features to be developed openly and visibly.

  • Testable: all major functionality should be present in a basic form, sufficient for testing. It is expected to have bugs, but no new functionality should be necessary after FeatureFreeze in order to complete the feature.

  • Integrated: basic integration should be complete. For example, if the feature requires a certain package to be installed by default, the relevant seed and metapackage changes should have taken place. Any relevant external infrastructure should be in place.

• Yes, exceptions may be granted on a case-by-case basis according to the process described at FreezeExceptionProcess.

• Send email to the release team with your request. Be sure to include a plan for how your feature will be completed, including a summary of the work which remains to be done and a specific and realistic deadline by which it will be completed.

• These decisions will be based on a risk/benefit analysis incorporating various criteria, but some guidelines include:
  • The potential impact on the distribution as a whole, especially the testing process
  • The development plan's pragmatism and chances for success
  • The priority of the feature for the current release
  • The amount of testing that the feature is likely to receive during its shortened test cycle

• But there are still several days (weeks, etc.) remaining before the release!

  • The process of preparing an Ubuntu release requires several weeks in itself, to build CD images for all of the derivatives, for all supported platforms, and test them. Your feature needs to be implemented and well tested before this process even begins. Don't wait! This is why the release schedule is published well in advance, to help you plan your participation.

• But it's very important!

  • The overall quality and punctuality of an Ubuntu release are more important than any single feature, and a high-quality feature is superior to a hastily-added one, even if it arrives in a later release. Free software developers are passionate about their work, and it is easy to get carried away by a particular feature, losing sight of the greater goals of Ubuntu. Pause, breathe, and consider whether it is more important to get it now or to get it right.

• But it works fine for me! What's the big deal?

  • Testing is hard! Many bugs only manifest themselves under certain circumstances, and these take time to discover. For example, your feature may malfunction only if the user is using a different language than you are, or in the live CD environment, or in a different desktop environment (GNOME/KDE/XFCE), or on a fresh install, or when certain other packages are installed, or on a certain hardware platform...there are many relevant variables. Ubuntu users are a diverse bunch, and given the chance, history shows that they will test new features thoroughly simply by using and experimenting with their systems. You should take advantage of the adventurous spirit of users who track the development branch, and give them a chance to help you test.

• OK, I understand. How can I do better for the next release?

  • Plan in advance! FeatureSpecifications explains how.

We only update packages for specific types of changes:

• Fixes for security vulnerabilities
• Other high-impact bug fixes, for example those which cause data loss
• Very conservative, unintrusive bug fixes with substantial benefit and very low risk

CategoryProcess

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.5