Re: Rethinking stable updates policy
John Goerzen wrote: > Hello, > > The Debian stable distribution has been a thorn in our side for a long > time. We tend to go a long time between releases, which means that > stable grows less and less useful as time goes on. We also have a > strict policy on what is allowed into stable. > > This policy has many merits, especially for those running Debian on > production servers. On the other hand, it has many problems. One is > that current Debian stable can't be installed on many current systems > due to weak SATA controller support. > > I think it's time we reopen the discussion on what stable means and what > it should mean. > > To start with, [1] says that a package is only uploaded to stable when > it meets one of these criteria: > > * it fixes a truly critical functionality problem > > * the package becomes uninstallable > > * a released architecture lacks the package > > I am mainly interested in #1. I think we need to take a more expansive > view of what constitutes a functionality problem, perhaps replacing > "truly critical" with "serious". > > Examples of things that should happen in stable, but haven't been > happening reliably: > > * Kernel updates with more broad hardware support This requires new kernel packages, new utilities and a new installer. It a hell of an effort to get this done. Just look at what it takes to update these in stable with "only" security updates. Expecting this to become easier with new kernel versions included is a little bit off the reality. Feel free to try to get a new kernel via backports.org and watch how many other packages creep in. It would be good, though, especially in order to have some support for hardware that has entered the market after the last Debian release, if there would be an outside repository for updated kernel and installer packages. However, nobody considered this important enough yet. (Hint! Hint!) > * Infrastructure updates such as ClamAV and Spamassassin We already have this in form of the volatile archive. That's exactly what volatile is for and why it has been started. For these packages it works quite well. > * Security and other important Firefox updates I'm sure you only forgot that we do have security updates for Mozilla and friends (thanks to the great work of Alexander Sack, can't say that often enough). Anyway, you want to see new versions, which is fine. However, this also requires new dependencies since newer versions tend to require newer libraries. Also there are a lot of translation and plugin packages that would have to be updated as well - and the software would behave differently. That's nothing for a *stable* Debian release. However, thanks to nobse there is the backports repository which is perfectly suited for such an effort. Not sure if anybody bothered to backport Mozilla and friends yet, though. (I guess not. Hint! Hint!) > Now, we need also to make sure that stable stays stable, and should be > introducing additional guidelines to accompany this: > > * No major architectural changes in packages (don't upgrade >spamassassin from v2 to v3, but it may be OK to introduce a new >spamassassin v3 package). Or, no XF86 -> XOrg transition, >but perhaps a new XF86 point release with more HW support could work This should not happen *in* the stable distribution since it would become a floating target instead. The cases you mentioned have already happened outside of the stable release, i.e. in the backports archive, iirc. > * Updates must undergo testing, ideally with peer review For this we don't have the infrastructure with regards to stable, and it's also not possible to update stable just again because we noticed that Firefox creashes 50% of the time. Backports is much easier to handle for this and should be used. > * Updates must be drop-in compatible with the released stable -- >no config file incompatibilies or new debconf prompts, no new library >so versions or deps on libraries not in stable, etc. This rejects packages like the kernel or Mozilla and friends already. > It is important to maintain stable as stable for existing server > installs, but still keep it useful for new deployments. I think we can > achieve the latter without compromising the former, in a little better > way that we have done to date. It's also important for desktop installations that shouldn't change every other day. Regards, Joey -- Have you ever noticed that "General Public Licence" contains the word "Pub"? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
Il giorno ven, 25/08/2006 alle 16.45 -0500, John Goerzen ha scritto: > * Updates must undergo testing, ideally with peer review This could be impossible if stable and testing distributions are binary-incompatible (ie. using different versions of glibc), just like sarge and etch are in this moment. Anyway, I mostly agree with your proposal, even if some of the points you raised can be achieved using volatile. -- Fabio Tranchitella <[EMAIL PROTECTED]>.''`. Proud Debian GNU/Linux developer, admin and user.: :' : `. `'` http://people.debian.org/~kobold/ `- _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Re: Rethinking stable updates policy
On Fri, Aug 25, 2006 at 04:45:31PM -0500, John Goerzen wrote: > I think it's time we reopen the discussion on what stable means and what > it should mean. > > To start with, [1] says that a package is only uploaded to stable when > it meets one of these criteria: > > * it fixes a truly critical functionality problem > > * the package becomes uninstallable > > * a released architecture lacks the package I would love to have "the new package for stable eases future update" as this would allow to fix stable issues which would otherwise cause future grief to fix. For example, a more allowing policy would allow exim 3 to warn against new installations and in turn motivate people to update to exim3 before they take the etch plunge. > Examples of things that should happen in stable, but haven't been > happening reliably: > > * Kernel updates with more broad hardware support > > * Infrastructure updates such as ClamAV and Spamassassin > > * Security and other important Firefox updates I think we have volatile for this, allowing people to choose whether they need absolute stability or new infrastructure. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Rethinking stable updates policy
Hello, The Debian stable distribution has been a thorn in our side for a long time. We tend to go a long time between releases, which means that stable grows less and less useful as time goes on. We also have a strict policy on what is allowed into stable. This policy has many merits, especially for those running Debian on production servers. On the other hand, it has many problems. One is that current Debian stable can't be installed on many current systems due to weak SATA controller support. I think it's time we reopen the discussion on what stable means and what it should mean. To start with, [1] says that a package is only uploaded to stable when it meets one of these criteria: * it fixes a truly critical functionality problem * the package becomes uninstallable * a released architecture lacks the package I am mainly interested in #1. I think we need to take a more expansive view of what constitutes a functionality problem, perhaps replacing "truly critical" with "serious". Examples of things that should happen in stable, but haven't been happening reliably: * Kernel updates with more broad hardware support * Infrastructure updates such as ClamAV and Spamassassin * Security and other important Firefox updates Now, we need also to make sure that stable stays stable, and should be introducing additional guidelines to accompany this: * No major architectural changes in packages (don't upgrade spamassassin from v2 to v3, but it may be OK to introduce a new spamassassin v3 package). Or, no XF86 -> XOrg transition, but perhaps a new XF86 point release with more HW support could work * Updates must meet an important userbase need * Updates must undergo testing, ideally with peer review * Updates must be drop-in compatible with the released stable -- no config file incompatibilies or new debconf prompts, no new library so versions or deps on libraries not in stable, etc. It is important to maintain stable as stable for existing server installs, but still keep it useful for new deployments. I think we can achieve the latter without compromising the former, in a little better way that we have done to date. [1] http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-upload-stable -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones
Alexander Wirt schrieb am Freitag, den 25. August 2006: > Don Armstrong schrieb am Donnerstag, den 24. August 2006: > > > I'd like to propose the following option to the current GR process. > I second this proposal. I have to say a few mores word to it. It would be fully ok for me if we release etch with this non-free firmware, but this problem should be adressed with etch+1. Alex signature.asc Description: Digital signature
Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones
On Thu, Aug 24, 2006 at 11:51:51PM -0700, Don Armstrong wrote: > I'd like to propose the following option to the current GR process. I like your proposal too. As for D, maybe we could word it a bit differently, as it will be a arduous task, with little success chances in the general case. Maybe we can arrive to some kind of agreement with manufacturer to have them free the source of their firmwares after some time or something. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones
I second this proposal. On Thu, Aug 24, 2006 at 11:51:51PM -0700, Don Armstrong wrote: > I'd like to propose the following option to the current GR process. > > As I will (starting late sunday PDT) be away for a week and a few days > at Burning Man,[i] I will be unable to appropriately respond to > corrections and suggested amendments during that time. However, I will > do so immediately at my return. > > > == > > The Free Software movement is about enabling users to modify the works > that they use on their computer; about giving users the same > information that copyright holders and upstream developers have. As > such, a critical part of the Free Software movement is the > availability of source (that is, the form of the work that a copyright > holder or developer would use to actually modify the work) to users. > This makes sure that users are not held hostage by the whims (or lack > of interest or financial incentive) of upstreams and copyright > holders. > > Different types of works have different forms of source. For some > works, the preferred form for modification may not actually be > digitally transferable.[1] For others, the form that originally was > preferred may have been destroyed at some point in time, and is no > longer available to anyone. However, to the greatest extent > possible,[2] the availability of source code to users is a critical > aspect of having the freedom to modify the software that is running > upon ones computer. > > Recognizing this, the Debian Project: > > A. Reaffirms that programmatic works distributed in the Debian > system (IE, in main) must be 100% Free Software, regardless of > whether the work is designed to run on the CPU, a subsidiary > processing unit, or by some other form of execution. That is, > works must include the form that the copyright holder or upstream > developer would actually use for modification. > > B. Strongly recommends that all non-programmatic works distribute > the form that the copyright holder or upstream developer would > actually use for modification. Such forms need not be distributed > in the orig.tar.gz (unless required by license) but should be > made available on upstream websites and/or using Debian project > resources. > > C. Reaffirms its continued support of users whose hardware (or > software) requires works which are not freely licensed or whose > source is not available by making such works available in > non-free and providing project resources to the extent that > Debian is capable of doing so. > > D. Requests that vendors of hardware, even those whose firmware is > not loaded by the operating system, provide the prefered form for > modification so that purchasers of their hardware are can > exercise their freedom to modify the functioning of their > hardware. > > > 1: Consider film negatives, or magnetic tape in the case of audio >recordings. > > 2: Here it must be emphasized that we refer to "technically possible" >or "possible for some party" as opposed to "legally possible for >Debian". We also assume digital distribution, and do not attempt to >require the distribution of physical objects. > > === > > > Obvious points for discussion: > > 1. I would really like to be able to commit to some form of >installation support for users who need to be able to use non-free >firmware to install their system; some more work is needed in d-i >land, though to make sure that this is separated out and that it's >trivial to have a Free system, and know that what you're >installing/using/distributing is Free Software. > > 2. Distributing the huge source forms for non-programmatic works is >going to be a problem. I don't think they're needed in the >orig.tar.gz, because that would needlessly bloat the archive, and >it's probably not required unless the works are copylefted. >However, we should make an effort to encourage upstreams to make >them available and likewise make them available to our users. [Even >if it's just in people.debian.org/~you/ or similar and mentioned in >the copyright file, it'd be a good step.] > > 3. If there is substantial objection to D, I will probably remove it; >however firmware, whether we happen to distribute it or not, is a >hazard to user's freedom to modify the functioning of their >computers. > > 4. Finally, if in the context of the release of etch, we need to >compromise our ideals and accept programmatic works without source, >we should do so by specifically exempting them from DFSG 2 for the >purpose of releasing etch by a GR which needs to meet the 3:1 >requirement instead of attempting to define ourselves into such a >position, especially when source c
Re: Proposal: The DFSG do not require source code for data, including firmware
[Matthew Garrett] > The biggest area which is likely to bite us is with network cards, > though we'll probably lose some degree of SCSI support as well. Fortunately, at least with SCSI, users have a choice. They can buy Adaptec or LSI 53c* and they get _truly free_ firmware (in the case of Adaptec, the kernel includes firmware source and a matching assembler; for LSI, the firmware is augmented with byte-code "scripts" apparently assembled by the driver at runtime). Perhaps coincidentally, between aic7xxx, aic79xx and sym53c8xx_2, the most popular commodify SCSI chips are covered. (Well, there's the megaraid family, but those don't _appear_ to need to load firmware at runtime either.) Incidentally, the aic7xxx / aic79xx drivers in particular are a great thing to point out to people who are inclined to be lenient toward vendors on the theory that it is inherently not practical for them to ship open source firmware for their devices. Adaptec figured out how to do this a _long_ time ago: $Id: aic7xxx.reg,v 1.4 1997/06/27 19:38:39 gibbs Exp $ $Id: aic7xxx.seq,v 1.77 1998/06/28 02:58:57 gibbs Exp $ signature.asc Description: Digital signature
Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones
Hello, I second this proposal independently of the presence of the D clause, although I prefer it being not removed. Don Armstrong <[EMAIL PROTECTED]> writes: > I'd like to propose the following option to the current GR process. > > As I will (starting late sunday PDT) be away for a week and a few days > at Burning Man,[i] I will be unable to appropriately respond to > corrections and suggested amendments during that time. However, I will > do so immediately at my return. > > > == > > The Free Software movement is about enabling users to modify the works > that they use on their computer; about giving users the same > information that copyright holders and upstream developers have. As > such, a critical part of the Free Software movement is the > availability of source (that is, the form of the work that a copyright > holder or developer would use to actually modify the work) to users. > This makes sure that users are not held hostage by the whims (or lack > of interest or financial incentive) of upstreams and copyright > holders. > > Different types of works have different forms of source. For some > works, the preferred form for modification may not actually be > digitally transferable.[1] For others, the form that originally was > preferred may have been destroyed at some point in time, and is no > longer available to anyone. However, to the greatest extent > possible,[2] the availability of source code to users is a critical > aspect of having the freedom to modify the software that is running > upon ones computer. > > Recognizing this, the Debian Project: > > A. Reaffirms that programmatic works distributed in the Debian > system (IE, in main) must be 100% Free Software, regardless of > whether the work is designed to run on the CPU, a subsidiary > processing unit, or by some other form of execution. That is, > works must include the form that the copyright holder or upstream > developer would actually use for modification. > > B. Strongly recommends that all non-programmatic works distribute > the form that the copyright holder or upstream developer would > actually use for modification. Such forms need not be distributed > in the orig.tar.gz (unless required by license) but should be > made available on upstream websites and/or using Debian project > resources. > > C. Reaffirms its continued support of users whose hardware (or > software) requires works which are not freely licensed or whose > source is not available by making such works available in > non-free and providing project resources to the extent that > Debian is capable of doing so. > > D. Requests that vendors of hardware, even those whose firmware is > not loaded by the operating system, provide the prefered form for > modification so that purchasers of their hardware are can > exercise their freedom to modify the functioning of their > hardware. > > > 1: Consider film negatives, or magnetic tape in the case of audio >recordings. > > 2: Here it must be emphasized that we refer to "technically possible" >or "possible for some party" as opposed to "legally possible for >Debian". We also assume digital distribution, and do not attempt to >require the distribution of physical objects. > > === > > > Obvious points for discussion: > > 1. I would really like to be able to commit to some form of >installation support for users who need to be able to use non-free >firmware to install their system; some more work is needed in d-i >land, though to make sure that this is separated out and that it's >trivial to have a Free system, and know that what you're >installing/using/distributing is Free Software. > > 2. Distributing the huge source forms for non-programmatic works is >going to be a problem. I don't think they're needed in the >orig.tar.gz, because that would needlessly bloat the archive, and >it's probably not required unless the works are copylefted. >However, we should make an effort to encourage upstreams to make >them available and likewise make them available to our users. [Even >if it's just in people.debian.org/~you/ or similar and mentioned in >the copyright file, it'd be a good step.] > > 3. If there is substantial objection to D, I will probably remove it; >however firmware, whether we happen to distribute it or not, is a >hazard to user's freedom to modify the functioning of their >computers. > > 4. Finally, if in the context of the release of etch, we need to >compromise our ideals and accept programmatic works without source, >we should do so by specifically exempting them from DFSG 2 for the >purpose of releasing etch by a GR which needs to meet the 3:1 >requirement instead of attempting to define ourselv
Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones
Don Armstrong schrieb am Donnerstag, den 24. August 2006: > I'd like to propose the following option to the current GR process. I second this proposal. > > As I will (starting late sunday PDT) be away for a week and a few days > at Burning Man,[i] I will be unable to appropriately respond to > corrections and suggested amendments during that time. However, I will > do so immediately at my return. > > > == > > The Free Software movement is about enabling users to modify the works > that they use on their computer; about giving users the same > information that copyright holders and upstream developers have. As > such, a critical part of the Free Software movement is the > availability of source (that is, the form of the work that a copyright > holder or developer would use to actually modify the work) to users. > This makes sure that users are not held hostage by the whims (or lack > of interest or financial incentive) of upstreams and copyright > holders. > > Different types of works have different forms of source. For some > works, the preferred form for modification may not actually be > digitally transferable.[1] For others, the form that originally was > preferred may have been destroyed at some point in time, and is no > longer available to anyone. However, to the greatest extent > possible,[2] the availability of source code to users is a critical > aspect of having the freedom to modify the software that is running > upon ones computer. > > Recognizing this, the Debian Project: > > A. Reaffirms that programmatic works distributed in the Debian > system (IE, in main) must be 100% Free Software, regardless of > whether the work is designed to run on the CPU, a subsidiary > processing unit, or by some other form of execution. That is, > works must include the form that the copyright holder or upstream > developer would actually use for modification. > > B. Strongly recommends that all non-programmatic works distribute > the form that the copyright holder or upstream developer would > actually use for modification. Such forms need not be distributed > in the orig.tar.gz (unless required by license) but should be > made available on upstream websites and/or using Debian project > resources. > > C. Reaffirms its continued support of users whose hardware (or > software) requires works which are not freely licensed or whose > source is not available by making such works available in > non-free and providing project resources to the extent that > Debian is capable of doing so. > > D. Requests that vendors of hardware, even those whose firmware is > not loaded by the operating system, provide the prefered form for > modification so that purchasers of their hardware are can > exercise their freedom to modify the functioning of their > hardware. > > > 1: Consider film negatives, or magnetic tape in the case of audio >recordings. > > 2: Here it must be emphasized that we refer to "technically possible" >or "possible for some party" as opposed to "legally possible for >Debian". We also assume digital distribution, and do not attempt to >require the distribution of physical objects. > > === > > > Obvious points for discussion: > > 1. I would really like to be able to commit to some form of >installation support for users who need to be able to use non-free >firmware to install their system; some more work is needed in d-i >land, though to make sure that this is separated out and that it's >trivial to have a Free system, and know that what you're >installing/using/distributing is Free Software. > > 2. Distributing the huge source forms for non-programmatic works is >going to be a problem. I don't think they're needed in the >orig.tar.gz, because that would needlessly bloat the archive, and >it's probably not required unless the works are copylefted. >However, we should make an effort to encourage upstreams to make >them available and likewise make them available to our users. [Even >if it's just in people.debian.org/~you/ or similar and mentioned in >the copyright file, it'd be a good step.] > > 3. If there is substantial objection to D, I will probably remove it; >however firmware, whether we happen to distribute it or not, is a >hazard to user's freedom to modify the functioning of their >computers. > > 4. Finally, if in the context of the release of etch, we need to >compromise our ideals and accept programmatic works without source, >we should do so by specifically exempting them from DFSG 2 for the >purpose of releasing etch by a GR which needs to meet the 3:1 >requirement instead of attempting to define ourselves into such a >position, especially when source code
Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones
On Thu, 24 Aug 2006, Don Armstrong wrote: > D. Requests that vendors of hardware, even those whose firmware is > not loaded by the operating system, provide the prefered form for > modification so that purchasers of their hardware are can This should read 'hardware can exercise'; I had 'are able' here originally and didn't complete its deletion. > exercise their freedom to modify the functioning of their > hardware. Don Armstrong -- America was far better suited to be the World's Movie Star. The world's tequila-addled pro-league bowler. The world's acerbic bi-polar stand-up comedian. Anything but a somber and tedious nation of socially responsible centurions. -- Bruce Sterling, _Distraction_ p122 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones
Le ven 25 août 2006 08:51, Don Armstrong a écrit : I second that proposition > = > > The Free Software movement is about enabling users to modify the > works that they use on their computer; about giving users the same > information that copyright holders and upstream developers have. As > such, a critical part of the Free Software movement is the > availability of source (that is, the form of the work that a > copyright holder or developer would use to actually modify the work) > to users. This makes sure that users are not held hostage by the > whims (or lack of interest or financial incentive) of upstreams and > copyright holders. > > Different types of works have different forms of source. For some > works, the preferred form for modification may not actually be > digitally transferable.[1] For others, the form that originally was > preferred may have been destroyed at some point in time, and is no > longer available to anyone. However, to the greatest extent > possible,[2] the availability of source code to users is a critical > aspect of having the freedom to modify the software that is running > upon ones computer. > > Recognizing this, the Debian Project: > > A. Reaffirms that programmatic works distributed in the Debian > system (IE, in main) must be 100% Free Software, regardless of > whether the work is designed to run on the CPU, a subsidiary > processing unit, or by some other form of execution. That is, > works must include the form that the copyright holder or upstream > developer would actually use for modification. > > B. Strongly recommends that all non-programmatic works distribute > the form that the copyright holder or upstream developer would > actually use for modification. Such forms need not be distributed > in the orig.tar.gz (unless required by license) but should be > made available on upstream websites and/or using Debian project > resources. > > C. Reaffirms its continued support of users whose hardware (or > software) requires works which are not freely licensed or whose > source is not available by making such works available in > non-free and providing project resources to the extent that > Debian is capable of doing so. > > D. Requests that vendors of hardware, even those whose firmware is > not loaded by the operating system, provide the prefered form for > modification so that purchasers of their hardware are can > exercise their freedom to modify the functioning of their > hardware. > > > 1: Consider film negatives, or magnetic tape in the case of audio >recordings. > > 2: Here it must be emphasized that we refer to "technically possible" >or "possible for some party" as opposed to "legally possible for >Debian". We also assume digital distribution, and do not attempt to >require the distribution of physical objects. > > = > > > Obvious points for discussion: > […] > 3. If there is substantial objection to D, I will probably remove it; >however firmware, whether we happen to distribute it or not, is a >hazard to user's freedom to modify the functioning of their >computers. I've none, but would second a proposal without it as well if that's needed. > 4. Finally, if in the context of the release of etch, we need to >compromise our ideals and accept programmatic works without source, >we should do so by specifically exempting them from DFSG 2 for the >purpose of releasing etch by a GR which needs to meet the 3:1 >requirement instead of attempting to define ourselves into such a >position, especially when source code is clearly a desirable thing >to have from our users and our perspective. and I also feel that's needed. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpTnPTeJeByX.pgp Description: PGP signature
