Difference between revisions of "Arch Linux Stable"

From ArchWiki
Jump to: navigation, search
(wikify some external links, use https for archlinux.org)
(38 intermediate revisions by 16 users not shown)
Line 1: Line 1:
==Arch Linux Stable Branch/Snapshot==
+
[[Category:Arch development]]
  
In reference to the discussion in [http://bbs.archlinux.org/viewtopic.php?id=41764&p=1 this] forum thread, the proposition has been put forth, initially by '''nagoola''', to provide a stable branch or snapshot of the Arch Linux distribution.  
+
{{Note|This project is no longer active. There is an alternative available at [http://www.archserver.org/ www.archserver.org]}}
===GOAL===
+
  
To provide a stable branch for Arch Linux. This project shall serve to compliment and benefit Arch, the rolling release, and the community by conforming to [[The Arch Way]] and the K.I.S.S principle. It absolutely shall not and must not fork nor divide Arch, its community, nor code. Its existence must serve to unite, benefit and strengthen Arch, or it shall cease to be useful and therefore cease to exist.
 
  
===Concept===
+
==Arch-Stable/ArchRock==
  
Why a stable branch? A general consensus has been formed, of the opinion that such a project will be advantageous in several ways:
+
In reference to the discussion in [https://bbs.archlinux.org/viewtopic.php?id=41764&p=1 this] forum thread, the proposition has been put forth, initially by '''nagoola''', to provide a stable branch or snapshot of the Arch Linux distribution.
  
1. For the stability of workstations/production machines:
+
===Aims===
Arch is of the highest quality, and the rolling release model is very strong. However, it is the hope of this project's members that a stable branch may bring the added benefit of less breakage- "when you need it to ''just work''."
+
  
2. Desktops/Personal machines:
+
Arch-Stable(ArchRock) is aimed at servers, not at desktop/workstation machines. We will provide a repository that is as stable as possible and should never break an update.
The convenience of upgrading with less breakage appeals to those who want less time fixing package breakage and more time using Arch for other, more productive tasks.
+
  
3. To widen the Arch Linux horizon by appealing to users who would benefit from Arch in a production environment, as well as offer more choice for existing users, the Arch spectrum will be broadened, quality enhanced, and reputation heightened. 
+
===Concept===
  
4.
+
We will provide a repository, which is only updated for security-updates during a release-cycle(6-12 Months). Feature updates will not be made during a release-cycle. Each release will be based on the official Arch-Repositories. We will only be providing the packages from [core] + some extra packages, which are often used by servers, like apache, php, mysql, etc.
  
 
===Definition===
 
===Definition===
  
In the context of the Arch Linux Stable Branch, 'stable' will mean: The ability to provide a smooth transition between upgrades with an absolute minimal measure of breakage, ideally, none, while still remaining compatible with the current rolling system.
+
In the context of the Arch-Stable Branch, 'stable' will mean: Packages should never crash during runtime, be bug-free and should never be broken by updates.
  
 
===Requirements===
 
===Requirements===
1. Project Leader - for delegating tasks and project direction.
 
  
2. Packagers - for choosing and handling packages to add to the snapshot repo.
+
====Staff====
  
3. Testers - for testing the stability of packages, logistics, and assistance.
+
# Project Leader - Delegate tasks and project direction.
 +
# Packagers - Choosing and handling packages to add to the snapshot repository.
 +
# Testers - Testing the stability of packages, logistics, and assistance.
 +
# Repository - Will require a server.
 +
# Programmers - Code necessary tools.
  
4. Communication between all involved.
+
====Communication====
  
5. Repository - which will require a server.
+
'''IRC''' - [http://irc.freenode.net irc.freenode.net] #archlinux-stable
  
6. (Possibly) Scripting - submit a prototype script below, which can tweak the client (user) pacman.conf to ignorepkg= ''unstablepkg''
+
'''Mailing list''' - [mailto:archlinux-stable-request@freelists.org archlinux-stable-request@freelists.org] Send e-mail with the subject 'subscribe'<br> or view the archive here: http://www.freelists.org/archives/archlinux-stable/
  
===Project Volunteers===
+
Web Site - http://arch-stable.wholebean.info/
  
The project volunteers must be dedicated and able to perform their responsibilities effectively and expeditiously. They must be capable of their assigned tasks, personable, and must keep ''each other informed'' of progress and issues as they arise.
+
====Project Volunteers====
  
 
Currently, the project has recruited these members:
 
Currently, the project has recruited these members:
  
nagoola - Project Management tasks / Communication. Also programming or package  maintenance.
+
Active:
 
+
* Nihathrael - Project Management / Programming / Documentation / Homepage / Package maintenance
ibendiben - Coming soon, yet to decide
+
* rxKaffee - Programming / Provides testing server / Package maintenance / Homepage
 
+
* sixty-four-bit - Packager
my64
+
* Basn - Packager
 
+
* AndyRTR - technical adviser, moderation / coordination if wanted/needed, maybe some packaging for core stuff
hussam
+
 
+
Nihathrael
+
 
+
Misfit138 - Wrote this page-I am above average with English. Below average at GNU/Linux.
+
 
+
(Please add/remove your name as appropriate and state briefly what you are qualified to offer the project.)
+
 
+
==Methodology==
+
 
+
Several different methods of achieving the project goal have been proposed-
+
 
+
They include:
+
 
+
1. Loosely basing the stable branch on Slackware packaging- expand to clarify, discuss.
+
 
+
2. An rsync of core and extra every xx days, using the mirror as the package source. Longer periods of time  (3-6 months) will bring unwanted issues. Once per month may be practical? Discuss.
+
 
+
3. Instead of making one stable image,  keep  every major earlier version of packages, allowing the user choose which version of a package he should install.
+
 
+
4. Loosely basing the stable branch on the Frugalware methodology. (Expand to clarify.)
+
 
+
5. No stable "release" per se, but rather, stable packages.
+
 
+
6. Incorporating scripts to tweak ignorepkg= in pacman.conf on client (user) machines, until issues (upstream, configuration and otherwise) can be resolved, or instructions on fixage is secured.
+
''Submit a script here by pasting it below.''
+
 
+
7. Package tagging system- whereby through testing and data gleaned from the Package Upgrade issues subforum, packages may be tagged as stable/unstable and appropriate action taken.
+
 
+
As it is early in the project, all are invited to discuss.
+
 
+
IRC- irc.freenode.net #archlinux-stable
+
 
+
*'''Prototype Scripts'''
+
 
+
===Growth===
+
 
+
The project must start somewhere.
+
*Scope
+
A small, manageable stable snapshot of the core repo may be the best way to begin work; adding as future manpower allows until a complete stable system is achieved.
+
 
+
===Sandbox===
+
 
+
 
+
 
+
Crouse's Notes:
+
To create a "stable" system, I currently auto-update nightly, although this could be changed to weekly to better control stability (IE: more time to find packages that break things).
+
 
+
Here is part of my auto-update script I use for my machines.... nothing earth shattering.
+
I use a cronjob that does 2 things...
+
 
+
1st downloads a pacman.conf file.  Anything that I don't want updated is put on hold
+
HoldPkg    = pacman glibc
+
Again, nothing earth shattering, but it does allow me to keep packages that are breaking things out of my systems.
+
 
+
2nd runs an automatic update script (because I'm lazy and don't want to update a dozen plus machines all the time.
+
Here is the code for that part:
+
 
+
#Pacman update and logging starts here
+
echo " " 2>&1 >> /var/log/client.UPDATELOG
+
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG
+
echo -ne "ARCH CLIENT UPDATE: "  2>&1 >> /var/log/client.UPDATELOG; echo `date +"%D %r"`  2>&1 >> /var/log/client.UPDATELOG
+
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG
+
# Uncomment here if you want pacman to automatically update this machine
+
pacman -Syu --noprogressbar --noconfirm 2>&1 >> /var/log/client.UPDATELOG
+
# If you use lilo, remember to also uncomment the next line
+
# /sbin/lilo 2>&1 >> /var/log/client.UPDATELOG
+
 
+
Sorry if this is a bit messy....... feel free to "clean-up" my wiki mess here at the end :)
+
 
+
 
+
===Release-Cycle Ideas===
+
 
+
 
+
There could be a [core-stable] repository. This repository contains all the packages the normal [core] repo contains. <br>
+
There are 3 possibilities/ideas:<br>
+
  
====Version A====
+
Inactive:
There is a [core-stable] release every ~3 months (debatable), the packages in the [core-stable] are not updated to newer versions. Of course security fixes will have to be applied and added as updates. Every new release comes with new, but stable packages and a detailed documentation with fixes to known update problems for this release.<br>
+
* nagoola - Project Idea
Benefits:<br>
+
* hussam
* Pretty much rock-solid core repository that is very unlikely to break during the 3 months it is used.<br>
+
(Please add/remove your name as appropriate and state briefly what you are qualified to offer to the project.)
Disadvantages:<br>
+
* A lot of work is required to back-port security fixes to the rather old packages.<br>
+
* Probably a huge update is required from one release to another.<br>
+
* No upstream improvements/new features are introduced during one release.<br>
+
  
====Version B====
+
===Project Status===
There is a [core-stable] repository that is continuously updated by maintainers. In order for a package to be updated, there should not be any known issues with it on the forums and IRC for about a week(debatable). Packages that are known to cause problems need to be checked and can be added if it's possible to remove the update problem with a script, that is then included in the update and automatically applied on install(Might be risky and a lot of work). Packages that can not be fixed to install correctly are kept away from updating until either a upstream fix is available and the problem disappears OR are released together will all other "problem-packages" in a ~3 month cycle, including detailed documentation on how to update the packages.<br>
+
We are currently setting up a test server for developers to use, which will not be publicly announced. If you would like to join development, please join '''#archlinux-stable''' at irc.freenode.net.<br>
Benefits:<br>
+
We are still looking for server-space that we can use to release the core-stable repository to the public. Please contact nihathrael if you would like to offer hosting.
* Stable core repository with very few/none update problems.<br>
+
Please refer to the mailing list for newest information.
* A stable repository, that is only 1 week behind the bleeding edge [core] repository. This way upstream improvements/new features are introduced shortly after release.<br>
+
* Almost no need to back-port security fixes(only for "problem-packages")<br>
+
Disadvantages:<br>
+
* Higher risk of making the stable repository unstable, by updating packages that cause unknown problems.<br>
+
* This is almost the exact same way it's done in Arch currently with the [testing] repository. So worst case is, you just shift the users form [core] to [core-stable] and [core] becomes your new [testing].
+
====Version C====
+
''NOTE: This version does not imply a [core-stable], but more a [stable] repository, also containing important software from extra(e.g. server software, window managers, office suites, browsers, media players), needed in production environments.''<br>
+
This idea is a mix of a) and b). Packages are divided into groups, like "base", "office", "servers" and "media". "base" for example(e.g containing the kernel, glibc, etc. and the window managers) does not have to be frequently updated, as the user doesn't need new features on a stable system, but only needs security fixes. So these are updated as explained under a). "servers" is rather bound to be updated frequently, as new features and performance improvements are likely to be wanted by a server-administrator. These packages are then updated by the means of b).  
+
This is rather advanced and should not be the first thing to try.<br>
+
  
All of these are only ideas and need detailed thoughts. So feel free to add/change anything you like.
 
  
 +
Last updated: [[User:Nihathrael|Nihathrael]] 16:03, 28 February 2008 (EST)
  
 +
==See Also==
  
Please feel free to add to or otherwise modify this project page and join the discussion at irc.freenode.net #archlinux-stable.
+
[[Snapshot_Release]]

Revision as of 14:52, 4 December 2012


Note: This project is no longer active. There is an alternative available at www.archserver.org


Arch-Stable/ArchRock

In reference to the discussion in this forum thread, the proposition has been put forth, initially by nagoola, to provide a stable branch or snapshot of the Arch Linux distribution.

Aims

Arch-Stable(ArchRock) is aimed at servers, not at desktop/workstation machines. We will provide a repository that is as stable as possible and should never break an update.

Concept

We will provide a repository, which is only updated for security-updates during a release-cycle(6-12 Months). Feature updates will not be made during a release-cycle. Each release will be based on the official Arch-Repositories. We will only be providing the packages from [core] + some extra packages, which are often used by servers, like apache, php, mysql, etc.

Definition

In the context of the Arch-Stable Branch, 'stable' will mean: Packages should never crash during runtime, be bug-free and should never be broken by updates.

Requirements

Staff

  1. Project Leader - Delegate tasks and project direction.
  2. Packagers - Choosing and handling packages to add to the snapshot repository.
  3. Testers - Testing the stability of packages, logistics, and assistance.
  4. Repository - Will require a server.
  5. Programmers - Code necessary tools.

Communication

IRC - irc.freenode.net #archlinux-stable

Mailing list - archlinux-stable-request@freelists.org Send e-mail with the subject 'subscribe'
or view the archive here: http://www.freelists.org/archives/archlinux-stable/

Web Site - http://arch-stable.wholebean.info/

Project Volunteers

Currently, the project has recruited these members:

Active:

  • Nihathrael - Project Management / Programming / Documentation / Homepage / Package maintenance
  • rxKaffee - Programming / Provides testing server / Package maintenance / Homepage
  • sixty-four-bit - Packager
  • Basn - Packager
  • AndyRTR - technical adviser, moderation / coordination if wanted/needed, maybe some packaging for core stuff

Inactive:

  • nagoola - Project Idea
  • hussam

(Please add/remove your name as appropriate and state briefly what you are qualified to offer to the project.)

Project Status

We are currently setting up a test server for developers to use, which will not be publicly announced. If you would like to join development, please join #archlinux-stable at irc.freenode.net.
We are still looking for server-space that we can use to release the core-stable repository to the public. Please contact nihathrael if you would like to offer hosting. Please refer to the mailing list for newest information.


Last updated: Nihathrael 16:03, 28 February 2008 (EST)

See Also

Snapshot_Release