:: Home :: Computing :: Downloads :: Scooter :: Links :: Music :: Nonsense :: Mail :: |
---|
Nachdem das Release von Woody zum Schluss etwas länger als vorherzusehen war auf sich warten gelassen hat, habe ich hier 'mal die Endphase des Releases anhand von eMails aus "debian-devel-announce" und "debian-announce" dokumentiert.
Und immer im Hinterkopf behalten:
Ein neues Debian Release ist dann fertig, wenn es fertig ist.
To: debian-devel-announce@lists.debian.org Subject: [2002-04-06] Release Status Update From: Anthony Towns <aj@azure.humbug.org.au> Date: Sat, 6 Apr 2002 22:24:34 +1000 Mail-copies-to: nobody Mail-followup-to: debian-devel-announce@lists.debian.org Organisation: Lacking User-agent: Mutt/1.3.28i Hello again, Over the past few weeks most of the following packages have been removed from the upcoming release due to bugs and such [0]. acroread libqt3-psql mercury antlr libsnmp-ruby msyslog cgiemail lire orbit-mt chdrv lmbench pfaedit devel-protocols logtrend-complexalarm popularity-contest dnrd logtrend-consolidation pptp-linux efingerd logtrend-doc qtella eiffelfox logtrend-ftpagent radiusd-freeradius galeon logtrend-httpagent rie galeon-beta logtrend-linuxagent sather garchiver logtrend-mailbridge scilab gnotepad+-help logtrend-snmpagent syslog-common honyaku-el logtrend-storageserver ttthreeparser ilisp logtrend-visuapache velocity infinity logtrend-visuengine werken.xpath kernel-patch-mppe makeme xmix kvdr masqmail xtell lclint mc-foo These packages will get a brief chance to be reconsidered in the next few days, but don't bet too heavily on them making it. From this point on, packages that are still in testing that have serious, grave or critical bugs that get removed probably won't get any second chances. In that vein, I'm becoming increasingly confident in woody's release readiness. So, to go out on a limb: Debian 3.0 (codenamed woody) will release on May 1st, 2002. Actually, as always, it'll release when it's ready: if we find that the software doesn't meet our expectations on April 30th, you'll find me on the ground writhing in pain with leaves, bark and wood all over the place[1]. Disclaimers aside, the things we've got left to finish of are these: * Boot-floppies need to be built for sparc and alpha * The people preparing release notes need to finish them off * The people preparing CD images need to make sure they're in a state where they can be told "go" and come up with reliable, final images for all eleven architectures a few hours later * apache needs to have its outstanding packaging bugs fixed * gimp1.2 needs to be fixed on alpha, even with the new pdl * hppa's db2/loader problem needs to be fixed * gs-common's license issues need to be resolved * mozilla's -fPIC problem needs to be fixed * Uploads need to be done for the following packages whose woody versions have security problems: exim-tls icecast-server libax25 lockvc nscd phpgroupware xfree86 * A bunch of archive maintenance tasks need to be finished off (giving the packages listed at the start of this mail a second chance to get released, some further touchups with the crypto in main transition, etc) All these things will be well and truly finished by the 20th (two weeks away), and should be finished early next week. For those of you who're working on packages that are crucial for release but don't have the testing<->unstable buffer to protect us from bugs you introduce (in particular CD and boot-floppies people) please be _incredibly_ conservative in _everything_ you do. If you can't prove beyond any _possible_ question that what you're doing won't break things that currently work, _do not change them_. No matter how much better it might be for how many people. Cheers, aj (woody release manager) [0] Note: this reflects bugs in the Debian packages of this software; they may be Debian specific problems, or problems that've been fixed by the upstream authors. This caveat was brought to you by the Society for the Prevention of Irate Letters from Upstream Maintainers, and is being displayed with recycled photons. [1] I'm going out on a limb, remember. -- Anthony Towns <ajt@debian.org> Woody Release Manager
To: debian-devel-announce@lists.debian.org Subject: [2002-04-30] Release Status Update From: Anthony Towns <aj@azure.humbug.org.au> Date: Tue, 30 Apr 2002 19:04:06 +1000 Mail-copies-to: nobody Mail-followup-to: debian-devel-announce@lists.debian.org Organisation: Lacking User-agent: Mutt/1.3.28i Hello world, So, it's April 30th (for most of the planet, anyway), which probably means folks are beginning to get mildly curious about whether woody'll actually be ready for release tomorrow. The answer is a definite "kind-of". Which is to say, "no". On the upside, woody itself is ready to be released. The only outstanding changes that need to be made are the standard security fixes that need to be made throughout the lifetime of stable anyway. Unfortunately, that's exactly where we've dropped the ball: the security team presently don't have the resources to handle security advisories for woody [0]. While there has been a plan in place for roughly a year on how to handle this ("rbuilder", for those playing along at home), it hasn't been successfully rolled out across more than a handful of the architectures we wish to support, and it further doesn't seem like trying to rush it now will be particularly effective. As such, an alternate arrangement, involving some moderately significant changes to the existing autobuilder system are being made, which should become active over the next week or so. Naturally, we will not be making the woody release until we have a viable mechanism for making timely security updates. On the technical side of things, the only other significant problem we're having is that we have so far been unable to produce fully successful builds of CD images for alpha and sparc. This is being worked on, but may mean that sparc and alpha CD images will be unavailable at release time. The other signficant issue that's come up is a poor sense of timing on behalf of a fair number of people. To take two fairly straightforward examples: a few days before the expected release is not the time to file eighty or ninety release-critical bugs about issues that have been being tracked outside the BTS in a satisfactory manner for months; similarly, it's far from ideal to have delayed the fix for the nscd bug (which has been open for over a month and requires a new upload of the glibc package to fix) until the very last day before release. These aren't isolated examples: there's been significant amounts of "QA" work (for example, checking buildability for binary-all packages; checking for packages that modify conffiles) that has only been started _after_ the time when it's reasonable to try doing anything about it, and there've been significant numbers of uploads rushed in at the last minute for problems that could've been resolved either by the maintainer or by NMU weeks or months ago. These are two sides of the same coin, really: fixes need to be done early rather than late so that they can be tested and, if necessarily, fixed further, and problems need to be found even earlier so that there's time to fix the problem right. It might be better late than never, but really the difference isn't all that noticible. Hopefully people will be able to use the forthcoming suffering as an incentive to get this done right next time. So, the final automatic run of the testing scripts was today, and will be reflected in the next mirror pulse. From this point, we'll have manually approved security updates to some packages, and very little else, until release. Requests from the maintainer to remove packages that are unreleasable may be considered. Requests from the maintainter for an update to a package will generally be considered a request to remove the package. Cheers, aj (woody release manager) [0] Issuing an advisory and fixed .debs for the six architectures that released with Debian 2.2 (potato) already takes, essentially, an entire night with the current tools; doing likewise for the eleven architectures that will release with woody will take more time than the security team are able to commit; doing it with woody's eleven architectures _and_ potato's six architectures for a few months so that people have time to evaluate woody before being forced to upgrade to it is completely out of the question. -- Anthony Towns <ajt@debian.org> Woody Release Manager
To: debian-devel-announce@lists.debian.org Subject: about the release status From: Josip Rodin <joy@debian.org> Date: Thu, 30 May 2002 22:02:58 +0200 Mail-followup-to: debian-devel@lists.debian.org Sender: Josip Rodin <joy@gkvk.hr> User-agent: Mutt/1.3.28i Hi, This note is primarily meant to alleviate the concerns about woody being released. Please read on if you care about the release. To reiterate the main point from the April 30th mail by Anthony Towns, the release of woody is being held back because there is no systematic way to build packages in security advisories on all architectures included in woody. To elaborate on this, the current situation is that when a security advisory is to be done for a package that is in woody, the security team people would need to go running around searching for eleven machines where they can build the new package. For some architectures, it's not hard to do this, but for some other, it's much harder to find a suitable machine. Bear in mind that these are, in fact, _security_-sensitive packages, so you can't just build them on J. Random Hacker's machine and distribute them worldwide. So, the ftpmaster team started doing changes to the buildd system and the archive maintenance scripts. These changes did get done in the first week of May as expected, but we haven't released woody yet because the overall testing and implementation on all buildds is still not complete. Rest assured that this will get done, as the guys really are working on it. Several buildds are already testing the new scheme. It's merely not certain when this will be finished. We can only ask you to be patient. :-) If anyone wishes to see the code changes in detail, CVS trees are available at: :pserver:anonymous@cvs.debian.org:/cvs/dak module dak :pserver:anon@cvs.linux-m68k.org:/CVS module wanna-build The first tree is also available via http://cvs.debian.org/dak/?cvsroot=dak You can observe the times between your uploads and when the buildds get to them via http://buildd.debian.org/ In the meantime, woody has been frozen. We have accumulated some more RC bugs, and the software has become that much older. Work continues on the unstable distribution, which is clear for uploading as always. It will be possible to propagate the newly fixed packages into woody, too, there is no need to worry about that. Whether woody will be unfrozen and test-cycled again, or include the patched packages in a point release, we are not sure, but the release-critical problems that aren't fixed will eventually be fixed. -- Thank you for your patience. Josip Rodin <joy@debian.org>
To: debian-devel-announce@lists.debian.org Subject: The New Security Build Infrastructure From: Anthony Towns <aj@azure.humbug.org.au> Date: Sat, 8 Jun 2002 18:26:46 +1000 Mail-copies-to: nobody Mail-followup-to: debian-devel-announce@lists.debian.org Organisation: Lacking User-agent: Mutt/1.3.28i Hello world, So, there's probably a whole bunch of people out there who're interested in the form new security infrastructure will take. If you're not, feel free to skip this message. Historically, which is to say, currently, the security.debian.org archive has been managed pretty manually: a member of the security team will patch a program with a security bug and test it; then ssh to machines of each different architecture in the stable release and build the new source there; then, once this is done everywhere, prepare an advisory including the md5sums of all the newly built packages; then move the packages into the appropriate place on security.debian.org; then run dpkg-scanpackages and dpkg-scansources; and, finally, sign and send out the advisory. (The above is the general idea aiui, anyway. I'm sure if anyone cares the security team can correct the details) This has a whole bunch of problems: since almost everything's done by hand, it's easy to forget to do something or to make mistakes, and this has occasionally resulted in broken security updates or confusing advisories. Additionally, it takes a lot of time and care, which can delay updates, and certainly makes the job a lot harder than it might otherwise be. But the real problem is it doesn't scale well: the ever growing number of packages alone gives the security team an ever increasing amount of work to do, with woody having twice the number of ports as potato we've made every single security update require twice as much effort from the security team, and that's just too much. Well, that's the problem statement anyway: managing security updates, and especially getting them built, needs to be much easier. So, what's the solution? For a fair while (at least a few months that I've been aware of), the security team were attempting to get "rbuilder" [0] installed on machines of each architecture so that they could use that to build security updates, but for various reasons didn't have much success. As such, in early to mid April, the buck was passed, although it wasn't for a couple of weeks after that that we figured out who it could reasonably be passed to. The new buildd infrastructure consists of two components that've been on the agenda for a while now: (1) Converting security.debian.org to be run by katie (2) Modifiying the central wanna-build infrastructure to do "Accepted-Autobuilding" For the former, the thought is that it's a waste to have all this neat software for managing Debian archives, and then not use it for our security archive -- but until now, nothing's been actually done, since making it happen requires some significant changes to both the security archive itself (poolising it amongst other things), and to generalise the katie code itself. Meanwhile, the latter is a nifty idea that the archive changes for crypto-in-main have allowed: since packages are checked (for signatures and such) within about fifteen minutes of them being uploaded, there's no longer any reason to have the autobuilders wait until the daily archive run before trying to build them. So it's basically a matter of setting up the buildds' sources.list to point to a new url [0], and add newly accepted packages to the wanna-build database, and -- presto chango! -- packages get automatically built thirty minutes or an hour or so after they're uploaded! As it happens, there're a bunch of little complications beyond this, to the point where the current setup is the third reimplementation of the above basic description in the past month or so, but you get the idea. While the above makes for a good answer to the scalability problems the security team are facing -- the archive code and the autobuilders already cope with much larger numbers of packages than the security team produce -- there are a number of additional difficulties in trying to manage security uploads that have to be taken into account. The major difference is that security updates frequently shouldn't be made public as soon as they're ready; in some cases they only need to wait until they can be tested further or an advisory written, in others they need to wait for a week or more to avoid publicising the flaw until all vendors have had a reasonable chance to fix it. This is pretty much in direct opposition to the way normal uploads work: we want those to be publically available as soon as possible. And, of course, there's an additional problem here in that in order to do accepted autobuilding, packages need to be made available to the autobuilders as early as possible, which is well before thay should be made available to the wider public. So! How does it all work? Here's the general idea: a) Someone finds a security problem. b) Someone fixes the problem, and makes an upload to security.debian.org's incoming. That is to say, a package is uploaded to: security.debian.org:/org/security.debian.org/queue/unchecked (aka ftp://security.debian.org/pub/SecurityUploadQueue) Its changelog needs to point it at "stable-security" or "testing-security" in place of the usual "unstable". It should be signed in the usual manner. It should, obviously, be tested fairly thoroughly. Anyone can do this, but presumably it'll usually be a member of the security team. If you're _not_ a member of the security team, you should definitely contact them before doing this. Further, while anyone can upload files here, only the security team can see what people have uploaded. c) The upload gets checked and processed by "jennifer" and moved into queue/accepted, and the buildds are notified. Files in here can be accessed by the security team and (somewhat indirectly) by the buildds. d) Security-enabled buildds pick up the source package (prioritized over normal builds), build it, and send the logs to the security team. e) The security team reply to the logs, and the newly built packages are uploaded to queue/unchecked, where they're processed by jennifer, and moved into queue/accepted. f) When the security team are happy with the source package (ie, that it's been correctly built for all applicable architectures and that it fixes the security hole and doesn't introduce new problems of its own) they run a script (viz, "amber") which: * installs the package into the security archive * updates the Packages, Sources and Release files in the usual way * sets up a template advisory that the security team can finish off * (optionally) forwards the packages to the appropriate proposed-updates so that it can be included in the real archive ASAP And that's pretty much it. All of the above has been implemented and tested in one way or another, although some of this hasn't been in entirely realistic conditions yet. It does, though, seem pretty safe to say that any further changes that'll be needed will be small bugfixes rather than redesigns or rewrites. katie for security.debian.org has been setup on satie.debian.org [1] and basically works, and the buildd changes are being live tested on the alpha, i386, powerpc and sparc autobuilders. Credit for the katie implementation work go to James Troup, for the buildd changes, Ryan Murray, and for all the -devel and other flamewars, yours truly. ;) What you can expect next is for the security infrastructure to move over to satie permanently and into the hands of the security team, and an update on all the other things that affect woody which have come up over the past month and a bit. It's possible that some of these changes will let us handle security updates in better ways in future (I'm hopeful it'll let us does security updates for testing in a more timely manner, eg), but that probably won't become clear until the security team's had more of a chance to get comfortable with it all. Cheers, aj (woody release manager) [0] http://incoming.debian.org/buildd/, as it happens. These are IP/password restricted and shouldn't be used except by autobuilders. If you want to poke around just for curiousity's sake, auric:/org/incoming.debian.org/ is one place to start. [1] Also accessible via a reference to this project's codename, "security by obscurity", as obscurity.debian.org. -- Anthony Towns <ajt@debian.org>
To: debian-devel-announce@lists.debian.org Subject: [2002-06-11] Release Status Update From: Anthony Towns <aj@azure.humbug.org.au> Date: Tue, 11 Jun 2002 01:14:44 +1000 Mail-copies-to: nobody Mail-followup-to: debian-devel-announce@lists.debian.org Organisation: Lacking User-agent: Mutt/1.3.28i Hello world, You should probably read all of this message, or at least skim the first sentence of each paragraph to make sure you don't miss anything. Oh, and if it's not the 11th yet where you are, obviously you shouldn't read this message. So, presumably everyone who's reading this has already seen the previous message, which indicated the security infrastructure work we were waiting on is getting close to done. For those of you who hadn't, consider yourself updated. First, I should emphasise that security stuff is *not* yet finished. That most of the remaining work should be bug fixes and a matter of installing previously tested software on different machines doesn't mean there's no work left to be done. We're not going to be releasing in the next few hours. We're also not entirely done developing woody. In the previous update, I indicated that I thought woody was ready to be released. We're now in the fairly fortunate position of being able to review any problems that have come up with woody in the month after I made that statement and see how accurate, or not, it was. So, the easiest first step in such a review is to see what changes have actually been made to woody since May 1. They are: * a new boot-floppies upload (3.0.23-2002-05-21), particularly for sparc (which couldn't produce bootable CDs with previous b-f builds), and ia64 (which needed a new kernel version) * removed packages: (mostly stuff that was requested to be removed from unstable that isn't depended on by anything in woody) atm chess kernel-image-2.2.20-udma100-ext3-i386 [zlib bug] kernel-source-2.4.12 kernel-source-2.4.13 libpgsql libticables2 libticalcs2 linkchecker-ssl mkinitrd-cd mmix-src [broken, 145534] modules-scyld-source-0.0 tom wmspaceweather [147284] xshogi * binary-only updates to packages on particular architectures to bring them in sync: cl-imho/ia64 clanbomber/mipsel clanlib0/mips,mipsel dossizola/arm effectv/ia64 eglade/hppa electricsheep/m68k fakeroot/mipsel flightgear/mips,mipsel ginac/m68k kernel-patch-2.4.17-mips/mips,mipsel libqt3-psql/arm lsh-utils/ia64 lvm-common/arm,hppa,ia64,m68k,mips,s390 mm/hppa mpqc/m68k mrproject/arm muse/arm,hppa netsaint-plugins/arm netsaint-plugins/arm openafs-krb5/ia64 palo/arm r-base/mips raidtools/mips scribe/m68k star/alpha * updated packages (source and binaries across all applicable architectures): abiword [various minor bugs, update to be > version 1.00] apache [security issues] arch [security issues] base-config [looping problem] bind9 [9.2.1-1 CERT] brltty [broken init script] cweb [145534] dhcp3 [security, 3.0.1rc9-1 CERT CA-2002-12] dns-browse [security, 147654] dpkg [enable force-overwrite by default] ecartis [security, argv buffer overflow, bugtraq, 147064] eterm [security, 0.9.2-0pre2002042903 bug# 141374] ethereal [security, 0.9.4-1 ethereal advisory enpa-sa-00004] evolution [security, 1.0.3-3 bug# 145903] gaim [security, 0.57 buffer overflow in TOC protocol plugin] gal [needed by evolution] gdk-pixbuf [needed by gaim and evolution] glibc [nscd security issue] libnss-lwres [crypto-in-main] lukemftp [security, 1.5-7 bug# 146148] lvm10 [new lvm systems] lvm10 [twice! "downgrade" from 1.1 to 1.0] mnogosearch [security, 3.1.19-3 bug# 146720] mutt [crypto-in-main, 145770] orbit [needed by abiword] psycopg [crypto-in-main] qpopper [security, 4.0.4-2 bug# 144974] rblcheck [145769] snoopy [147169] squirrelmail [security, 1:1.2.6-1 bug# 144496] trafstats [security, 0.4.19-4 bug# 145361] webmin [security, 0.94-5 buffer overflow 147599] A few of these are real problems: the problem with the sparc boot-floppies and dpkg are relatively serious issues for release and weren't discovered, let alone fixed, until after May. Likewise, the lvm and base-config problems aren't really things we would have liked to have had to deal with after commiting to a release. There're also a handful of belated crypto-in-main related changes, that should've (and in most cases could've) been accepted into woody before May 1. Of the remainder, there are four or five packages that've been updated or removed at the request of the maintainer that we could've lived with pretty easily as they were, and a whole host of security updates, that we generally have to live with maintaining post release anyway. As far as this goes, it seems fairly reasonable so far. Woody is certainly a long way off perfect, but it seems to be standing up fairly well, after a month's scrutiny. So. From this point on, security updates should be done entirely through the security team. They (via the new security software) will make uploads both to security.debian.org and to the appropriate proposed-updates directory. If you have a security problem in your package, make sure they're informed about it. They'll give you any further instructions about exactly what they'd like you to do from there. Security updates processed before release will be included in the release. Otherwise, over the next week or so, I'd like to encourage people to do their own poking around at woody to see if my opinion strikes you as accurate. Are there any major issues that desperately need to be addressed before we release? If you find some, you should do the following: * Discuss it with some other developers to make sure you're not freaking out over nothing. We've got 15,000 open bugs that'll all make some of our users (or some of us) miserable one way or another, and we simply can't do anything about the vast majority of them for woody. Is the problem you found particularly special, or is it just something we need to fix before th enext release? * Make sure it's fixable. If there's no bug report filed, file one, and include a full explanation. If there's no patch in the bug report, work out what the problem is and fix it. If it hasn't been fixed in unstable yet, contact the maintainer and make sure it is fixed in unstable. Do an NMU if the maintainer's not able to fix it. * Send an email to me pointing to the bug report and making sure it's clear why this problem needs to be fixed in woody. There's a special email address for this, viz: ajt-woody-sucks@debian.org which should get you a much better response than such mails to me have been getting over the past month. Be clear, and concise, but include all the details. You may wish to begin your emails "Woody sucks because...". Once you've done that, you should get a reply indicating whether it really is worth fixing, or not. * If it is worth fixing, you'll then need to prepare a "backport" to testing. This means preparing a new version of the package with a different version number (it needs to be a lower version number than the package in unstable to ensure upgrades behave sensibly) and uploading it to "testing" instead of "unstable" (or "frozen" or "woody-proposed-updates"). Presuming we're stay in good shape for a week or so, and can solve any problems that're found, we'll be looking to release shortly after that. In the meantime, since we have woody-proposed-updates operational, and won't be accepting further promotion of packages from unstable to testing, there's no need to be particularly wary about uploading new stuff to unstable. So, have at it. Cheers, aj (woody release manager) -- Anthony Towns <ajt@debian.org>
From: Martin Schulze <joey@infodrom.org> Subject: Debian GNU/Linux 3.0 released Date: Fri, 19 Jul 2002 23:59:59 +0200 To: Debian Announcements <debian-announce@lists.debian.org> User-Agent: Mutt/1.4i ------------------------------------------------------------------------ The Debian Project http://www.debian.org/ Debian GNU/Linux 3.0 released press@debian.org July 19th, 2002 http://www.debian.org/News/2002/20020719 ------------------------------------------------------------------------ The Debian Project is pleased to announce the release of Debian GNU/Linux version 3.0. Debian GNU/Linux is a free operating system, which now supports a total of eleven processor architectures, includes KDE and GNOME desktop environments, features cryptographic software, is compatible with the FHS v2.2 and supports software developed for the LSB. With the addition of the IA-64 (ia64), HP PA-RISC (hppa), MIPS (mips, mipsel), and S/390 (s390) architectures, Debian GNU/Linux now supports a total of eleven architectures. It now runs on computers ranging from palmtops to supercomputers, and nearly everything in between, including the latest generation of 64 bit machines. This is the first version of Debian that features cryptographic software integrated into the main distribution. OpenSSH and GNU Privacy Guard are included in the default installation, and strong encryption is now present in web browsers and web servers, databases, and so forth. Further integration of cryptographic software is planned for future releases. For the first time, Debian comes with the K Desktop Environment 2.2 (KDE). The GNOME desktop environment is upgraded to version 1.4, and X itself is upgraded to the much improved XFree86 4.1. With the addition of several full-featured free graphical web browsers in the form of Mozilla, Galeon, and Konqueror, Debian's desktop offerings have radically improved. This version of Debian supports the 2.2 and 2.4 releases of the Linux kernel. Along with better support for a greater variety of new hardware (such as USB) and significant improvements in usability and stability, the 2.4 kernel provides support for the ext3 and reiserfs journaling filesystems. Debian GNU/Linux 3.0 features a more streamlined and polished installation, which is translated into numerous languages. The task system has been revamped and made more flexible. The debconf tool makes configuration of the system easier and more user friendly. Debian GNU/Linux can be installed from CD, or from the network and a few floppies. It can be downloaded now, and will soon be available on CD-ROM from numerous vendors <http://www.debian.org/CD/>. Upgrades to Debian GNU/Linux 3.0 from earlier releases are automatically handled by the apt package management tool. As always, Debian GNU/Linux systems can be upgraded painlessly, in place, without any forced downtime. For detailed instructions about installing and upgrading Debian GNU/Linux, please see the release notes <http://www.debian.org/releases/woody/releasenotes>. This is the first release of Debian that is compatible with version 2.2 of the Filesystem Hierarchy Standard (FHS). Debian GNU/Linux now also supports software developed for the Linux Standard Base (LSB), though it is not yet LSB certified. Current Debian users may be interested to know that this release of Debian supports build dependencies, to aid in building packages from source, and apt pinning, to ease partial upgrades to our testing or unstable branch. This release of Debian features aptitude as an alternative for the venerable dselect program, which will make it easier to select packages. About four thousand new software packages were added to the distribution in Debian GNU/Linux 3.0. About Debian ------------ Debian GNU/Linux is a free operating system, developed by nearly a thousand volunteers from all over the world who collaborate via the Internet. Debian's dedication to Free Software, its non-profit nature, and its open development model make it unique among GNU/Linux distributions. The Debian project's key strengths are its volunteer base, its dedication to the Debian Social Contract, and its commitment to provide the best operating system possible. Debian 3.0 is another important step in that direction. Contact Information ------------------- For further information, please visit the Debian web pages at <http://www.debian.org/> or send mail to <press@debian.org>. -- To UNSUBSCRIBE, email to debian-announce-request@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
To: debian-devel-announce@lists.debian.org Subject: [2002-07-20] Release Status Update From: Anthony Towns <ajt@debian.org> Date: Sat, 20 Jul 2002 08:09:16 +1000 Mail-copies-to: nobody Mail-followup-to: debian-devel-announce@lists.debian.org Organisation: Lacking Sender: Anthony Towns <aj@azure.humbug.org.au> User-agent: Mutt/1.3.28i Hello world, First, the big news: it's my mum's birthday today. Happy birthday mum! Second, for those who haven't already noticed: ajt@auric:/org/ftp.debian.org/ftp/dists$ ls -l testing stable Debian3.0r0 lrwxrwxrwx 1 troup debadmin 5 Jul 19 14:41 Debian3.0r0 -> woody lrwxrwxrwx 1 troup debadmin 5 Jul 19 14:40 stable -> woody lrwxrwxrwx 1 troup debadmin 5 Jul 19 14:43 testing -> sarge Third, for those of you who aren't used to leaping to conclusions based on the output of a couple of obscurely named commands, this means the new testing distribution is codenamed "sarge" [0], and that "woody" is released -- the Debian GNU/Linux stable distribution is now at version 3.0. This revision began development when the "potato" entered it's code freeze, around two and a half years ago. It includes KDE, a new version of Gnome, Mozilla 1.0, and lots of other stuff that's already been covered in the real announcement and the release notes. If you've missed the real announcement, it's at: http://www.debian.org/News/2002/20020719 Fourth, we've got a new tool for generating CDs, called "jigdo". It lets you download most of the CD from your local Debian mirror -- which is likely to be faster or cheaper or both. See http://cdimage.debian.org/ for some details. Note that regular .iso images won't be made available for a couple of days, so if you want to be a really early adopter Jigdo is the only way to go. To find your local mirror, look at http://ftp.debian.org/README.mirrors.html Note that by the time you read this, some mirrors won't have updated yet. If you feel the need to update immediately enough to edit your /etc/apt/sources.list to point at an updated mirror, I'd *strongly* encourage you to include woody from your closest mirror as the first line in your sources.list. If you do that, any debs that're up to date on the local mirror will be fetched from there which will also be faster and cheaper for everyone concerned. Fifth, it seems to be the season for security updates. So make sure you've got deb http://security.debian.org/ stable/updates main or similar in your sources.list. So, that just leaves all the gossip! Sweet. (If you're a suit with a business imperative to obtain reassurance in regard to the enterprise suitability of Debian -- don't read on :) The traditional round of thanks, then. Over two or so years of trying to get woody released, there's a fair number of people who've done useful things: heck, that much time is enough for people to discover Debian, join it, do a bunch of useful things, get bored with it, and quit. I'm going to be lame and not even try to cover most people. You can get some vague idea of who the people who've gotten Debian from 2.2 to 3.0 by looking at http://www.debian.org/intro/organization http://www.debian.org/devel/people but it's only a vague idea at best. These releases don't happen without all the folks who work on our 9000 or so packages, our porters, our CD developers, our QA team, our security team, our installer developers, our bug reporters, etc, etc. And all that excludes the other two ends that make Debian what it is: all the people upstream who develop software we package, and all the people who actually use it. Apparently there are one or two people in both groups. But you can't have a round of thanks by saying "there are too many people to thank", coz that's just lame. So I'm going to restrict my focus to the release task itself, and thus I get to mainly thank James Troup and Ryan Murray. Without James' efforts over the past two years, the archive software wouldn't be anywhere near capable of managing all the packages we have (around 10000 all up, multiplied by 13 architectures (11 released, one unreleased and source)) nor the complexities of the way we've tried to handle this release (aka "testing"). Without Ryan's efforts we were struggling to keep our packages remotely consistent across a handful of architectures, with them, we're keeping almost a dozen highly varied architectures almost perfectly synced with twice as many packages. Normally I'd expect to be running through a list of people like the port maintainers or the boot-floppy hackers or the CD people here, but in a shocking turn of events, they all pretty much took care of themselves. People like Adam Di Carlo and Philip Hands can get a token mention anyway, though. Check the changelogs for the full details. Thanks, y'all. Thanks also to Jonathan Oxer, who fell for my blatant attempt at extortion in my previous update [1]: he's now the official organiser of the Debian mini-conference at linux.conf.au 2003 in Perth. So, if you're into Debian enough to be reading this mail, and you're planning on being in the Southern Hemisphere next January, you know what you should do. There's actually been some criticism of my use of the woody release to blackmail someone into hosting the mini-conf -- a number of people have indicated that I should've demanded money too. Well, fortunately there's still time to remedy such problems. And there'd better be, because there's a much more serious issue that's come to light: a certain past policy has almost certainly unfairly biassed some of the more accurate IT polling organisations [2] against the new release. As such, you should feel free to send a buck or two to "The Release Manager's Beer Fund" via PayPal to ajt-woody-rocks@debian.org [3]. Your return on investment is guaranteed! So, that about does it. Last time around I had a couple of bits about what went wrong with the release just gone, and some of the things that we'll be working on for the next one, but they're complicated enough to warrant a separate email sometime in the next week or so. Hrm. So, what else could cause some more chaos? I know! IRC PARTY IN #debian ON irc.openprojects.net NOW!!!!! Have fun. :) Cheers, aj [0] sarge is named after the green toy soldier, continuing the theme of using codenames based on characters in the animated movie _Toy Story_. [1] http://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200207/msg00005.html [2] http://srom.zgp.org/ [3] PayPal's at www.paypal.com. I've no idea how it works. Or if it works. If you're overly excited by all this "release" stuff, and feel an urge to send even *more* than pocket change, look at: http://www.spi-inc.org/donations instead. That'll ensure your money is properly accounted for and isn't randomly wasted. -- Anthony Towns Debian Release Mananger
Zurück zur Main-Site |