こんにちは，上川です． それとなく翻訳(気合いで意訳)してみました． # 長いのと眠いので挫折気味です． > Hello all, やぁ，みなさん > > As promised earlier on -project[0], after the release team/ftpmaster > team meeting-of-minds last weekend, we have some news to share with the > rest of the project. -projectでお約束していたように，先週末のリリースチームとFTPMASTERの秘密会議が終了しましたので そこで決定した事項をお知らせします． > First, the news for sarge. As mentioned in the last release team > update[1], deploying the testing-security queues has been held up > pending some infrastructure enhancements, without which > ftp-master.debian.org cannot handle the load of the added wanna-build > queues for testing-security. This week, Andreas Barth and Ryan Murray > have been applying the finishing touches to allow the needed upgrade of > ftp-master.debian.org's openssh to a version that supports connection > caching, which is needed before the current ftp-master host will scale > to handle the addition of testing-security queues. Once this happens, > the testing-security configuration should itself be completed for all > architectures in quick succession, with the result that testing-security > and testing-proposed-updates will be fully operational in the space of > two weeks. sargeについては，前回のリリースアップデートで出たように，testing-security キューの実装には インフラの改良が必要でした．それが無いと，ftp-master.debian.orgがtesting-securityの wanna-buildのキューの負荷に耐え切れなくなります． 今週andreas barthと Ryan Murrayはftp-master.debian.orgのopensshのバージョンを あたらしいものにするのに必要なみがきをかけました． opensshの新しいバージョンはコネクションキャッシングを実装するのに必要です． コネクションキャッシングができることがtesting-securityのキューの追加分スケールするのに必要です． これが実現したら，testing-securityの設定はすぐにすべてのアーキテクチャ用にできるでしょう． 結果として，2週間で完全動作するようなtesting-proposed-updatesとtesting-securityが 実装できるはずです． > This means that we are now (at long last) in the final stretch for > sarge's release, and we will be freezing soon once we know that d-i RC3 > is golden. While this does not yet give us a timeline with fixed dates > for the freeze and the release, this is noteworthy enough in itself that > we wanted to share the news immediately. これはつまり，とうとうsargeのリリースが近いということです．d-i RC3がまともにうごくということがわかったら フリーズを開始します． これはフリーズとリリースの日程を完全には決定したということにはなってないですが，とりあえずニュースに してしまうだけの意味はあるでしょう． > This also means that it's time again to ask maintainers to cut back on > uploads of new upstream versions of software, *particularly* of > libraries. This hasn't been mentioned in recent release team updates, > since it's not very realistic to insist on no new upstream versions for > six months without a complete freeze; but as we get close to the freeze > it's particularly important to limit churn of library packages, since > they tend to delay packages that depend on them -- as has bitten us > several times recently. If you believe a library needs updating for > sarge, please talk to the release team (debian-release@lists.debian.org) > before uploading. これはメンテナに新しいupstreamバージョンのパッケージをアップロードするのをできるだけさけてほしいと 依頼する時期がきたということでもあります． 特に共有ライブラリ． この件については最近のリリースアップデートには記述がありませんでしたが，それは６か月間 新しいバージョンをアップロードするな，とフリーズもしないで要求することが非現実的だったからです． ただ，フリーズが近くなって来ましたので，共有ライブラリパッケージの変更を制限することが重要です． ライブラリパッケージへの変更はそれに依存するパッケージをおくらせることが多く， 最近でもなんどもいたい目にあっているからです． もしライブラリをsargeむけに更新する必要があるというのであれば，アップロード前に リリースチームと相談してください > The much larger consequence of this meeting, however, has been the > crafting of a prospective release plan for etch. The release team and > the ftpmasters are mutually agreed that it is not sustainable to > continue making coordinated releases for as many architectures as sarge > currently contains, let alone for as many new proposed architectures as > are waiting in the wings. The reality is that keeping eleven > architectures in a releasable state has been a major source of work for > the release team, the d-i team, and the kernel team over the past year; > not to mention the time spent by the DSA/buildd admins and the security > team. It's also not clear how much benefit there is from doing stable > releases for all of these architectures, because they aren't necessarily > useful to the communities surrounding those ports. このミーティングにより発生したより大きな結論は，etchのリリースプランでした． リリースチームとftpmasterはsargeのように多くのアーキテクチャをもっているリリースを 継続することは不可能である，ということについて同意しました． ましてや，今追加を待っているアーキテクチャを追加することなど無理です． 現実問題，１１アーキテクチャをリリース可能な状態に維持することはリリースチーム，d-iチーム， カーネルチームにとって多くの労力を必要として来ました． DSA/buildd admin，セキュリティーチームの負荷も無視できません． また，特にstableリリースを全アーキテクチャにする事に関しても疑問が出ています． stableリリースが存在していることで，そのアーキテクチャのユーザに利便を提供してるわけではないのではないか と思われるからです． > Therefore, we're planning on not releasing most of the minor architectures > starting with etch. They will be released with sarge, with all that > implies (including security support until sarge is archived), but they > would no longer be included in testing. よって，われわれは，マイナーなアーキテクチャのほとんどをetch以降リリースしない予定を考えています． sargeではリリースされます．セキュリティーアップデートもします． しかし，今後，それらのアーキテクチャはtestingには含まれない事になります． > This is a very large step, and while we've discussed it fairly thoroughly > and think we've got most of the bugs worked out, we'd appreciate hearing > any comments you might have. これは大きなステップです． この実装については，深く議論して，ほとんどのバグも解決しましたが， コメントください． > This change has superseded the previous SCC (second-class citizen > architecture) plan that had already been proposed to reduce the amount of > data Debian mirrors are required to carry; prior to the release of sarge, > the ftpmasters plan to bring scc.debian.org on-line and begin making > non-release-candidate architectures available from scc.debian.org for > unstable. この変更は前回のSCC案(second-class citizen architecture)の後継です． SCC案は，ミラーの負荷を下げ，sargeのリリース前にftpmasterたちはscc.debian.orgを 稼働させ，リリース対象でないアーキテクチャのunstable distributionを scc.debian.orgから提供するように変更を加える予定です． > Note that this plan makes no changes to the set of supported release > architectures for sarge, but will take effect for testing and unstable > immediately after sarge's release with the result that testing will > contain a greatly reduced set of architectures, according to the > following objective criteria: この計画はsargeでサポートするアーキテクチャがなにかということについては変更は加えませんが， testing と unstableに関してはsargeをリリースした直後に影響が出ます． testingは下記の項目を満たすアーキテクチャのみから構成されることになります． > - it must first be part of (or at the very least, meet the criteria for) > scc.debian.org (see below) - 後程定義するscc.debian.orgのメンバである要件を満たしている必要があります． > > - the release architecture must be publicly available to buy new - アーキテクチャが新品で一般的に買える必要があります． > > - the release architecture must have N+1 buildds where N is the number > required to keep up with the volume of uploaded packages - そのアーキテクチャにはN+1のbuilddが存在していることが必要です． Nはアップロードされたパッケージのビルドにおいつくために必要な台数． > > - the value of N above must not be > 2 - N の数は 2 以上であってはいけない > > - the release architecture must have successfully compiled 98% of the > archive's source (excluding architecture-specific packages) - アーカイブにあるソースの98%をコンパイルできている必要があります． (arch 独自のパッケージは例外) > - the release architecture must have a working, tested installer - 動作する，テストされたインストーラがある必要があります． > > - the Security Team must be willing to provide long-term support for > the architecture - Security Teamが長期的なサポートしたいと思う必要があります > - the Debian System Administrators (DSA) must be willing to support > debian.org machine(s) of that architecture - Debian System administrators がdebian.orgマシンをサポートしたいと思う必要があります． > - the Release Team can veto the architecture's inclusion if they have > overwhelming concerns regarding the architecture's impact on the > release quality or the release cycle length - Release Teamはリリースの品質，もしくはリリースサイクルに多大な影響を与えると考える場合には， アーキテクチャの追加を拒否することができます． > - there must be a developer-accessible debian.org machine for the > architecture. - デベロッパ向けのdebian.orgマシンが一台は存在している必要があります． > We project that applying these rules for etch will reduce the set of > candidate architectures from 11 to approximately 4 (i386, powerpc, ia64 > and amd64 -- which will be added after sarge's release when mirror space > is freed up by moving the other architectures to scc.debian.org). > This will drastically reduce the architecture coordination required in > testing, giving us a more limber release process and (it is hoped) a > much shorter release cycle on the order of 12-18 months. これらの法則を適用すると，etchのアーキテクチャを11から4(i386, powerpc, ia64, amd64 -- sargeをリリースしてからミラーのスペースがscc.debian.orgに移動したことによって 空いてから追加)に減らすことになると予想しています． これはアーキテクチャ関連の雑務を大幅に減らし，リリースプロセスの負荷を軽減し， 12-18か月のより短いリリースサイクルを実現できる，と考えています． > Architectures that are no longer being considered for stable releases > are not going to be left out in the cold. The SCC infrastructure is > intended as a long-term option for these other architectures, and the > ftpmasters also intend to provide porter teams with the option of > releasing periodic (or not-so-periodic) per-architecture snapshots of > unstable. stableリリースに含まれないことになったアーキテクチャはほうっておかれているわけではありません． SCCインフラは今後の長期的な観点で，他のアーキテクチャに適用されます． また，ftpmasterとしては，移植チームが定期的な(もしくは不定期な)アーキテクチャ別のunstableの スナップショットをリリースできるようにしてあげる予定です． > Also, since the original purpose of the SCC proposal was to reduce the size > of the archive that mirrors had to carry, the list of release candidate > architectures will be further split, with only the most popular ones > distributed via ftp.debian.org itself. The criterion for being distributed > from ftp.debian.org (and its mirrors) is roughly: 当初のSCCの目標としては，ミラーが扱うアーカイブサイズを減らすことだったので， リリース候補のアーキテクチャはさらに分割されます． もっとも利用の多いもののみがftp.debian.org自身から配布されることになります． ftp.debian.orgで配布される条件はおおまかには： > - there must be a sufficient user base to justify inclusion on all > mirrors, defined as 10% of downloads over a sampled set of mirrors - すべてのミラーで配布するだけのユーザベースがあること，定義としては，ミラーからの ダウンロード数情報(一部のミラーをサンプルとする)に基づいて，10%以上であること． > To be eligible for inclusion in the archive at all, even in the > (unstable-only) SCC archive, ftpmasters have specified the following > architecture requirements: SCCアーカイブ(unstableのみ)に入るためには，ftpmasterは下記の要件を決定しました． > - the architecture must be freely usable (i.e., without NDAs) - アーキテクチャは自由につかえること(NDAがいらないこと) > - the architecture must be able to run a buildd 24/7 sustained > (without crashing) - builddがクラッシュしないで安定して連続稼働すること > - the architecture must have an actual, running, working buildd - 実働しているbuilddがあること > > - the port must include basic unix functionality, e.g resolving > DNS names and firewalling - UNIXの基本的な動作をすること．DNSのリゾルブや，ファイアウォール機能など． > > - binary packages must be built from the unmodified Debian source > (required, among other reasons, for license compliance) - バイナリパッケージは改変していないDebian のソースからビルドできていること． (ライセンスに準拠するために必要) > - binaries for the proposed architecture must have been built and signed > by official Debian developers - そのアーキテクチャのバイナリが，official debian developerによってビルドされ署名されていること． > - the architecture must have successfully compiled 50% of the archive's > source (excluding architecture-specific packages) - アーキテクチャはソースの50%をコンパイルできていること． > - 5 developers who will use or work on the port must send in > signed requests for its addition - 5人のデベロッパが利用，もしくはポートに参加するという署名した要望が追加には必要． > - the port must demonstrate that they have at least 50 users - 50人以上のユーザがあることを証明できること > These objective requirements would be applied both to the other eight > architectures being released with sarge that are not currently regarded > as candidates for release with etch, and also to any porter requests > asking for new architectures to be added to the archive. これらの要求はetchのリリース対象とみなされていない８のアーキテクチャについて適用されます． そしてまた，新しいアーキテクチャを希望する移植チームに関しても適用します． > > This plan has been signed off on by: > > Steve Langasek (Release Manager) > Colin Watson (Release Manager) > Andreas Barth (Release Assistant) > Joey Hess (Release Assistant) > Frank Lichtenheld (Release Assistant) > > James Troup (ftpmaster) > Ryan Murray (ftpmaster) > Anthony Towns (ftpmaster) > > The following people in Debian leadership roles have also expressed their > support: > > Andreas Schuldei (DPL candidate) > Angus Lees (DPL candidate) > Branden Robinson (DPL candidate) > Jonathan Walther (DPL candidate) > > Again, if you've got any questions, comments or concerns, please raise them > on -devel so we can take them into account before putting this plan into > effect. > > > Further plans for etch > ---------------------- etchについてのその他の計画について --------------------------- > > After the release of sarge, the release team will stop tracking the > day-to-day status of RC bugs in testing for a while. NMUs for broken > packages will be minimal; instead, our RC bug handling will mostly be > limited to the usual aggressive removal of broken packages from testing. > This will also be a key time for the QA team to focus on deeper quality > issues and methods for a change, instead of on individual > release-critical bugs. sargeをリリースしたあと，リリースチームはtestingのRCバグの状況の追跡を しばらくやめます．NMUは最小限になります． testingからのパッケージの削除が中心になります． QAチームとしては，それぞれのRCバグに対応するのではなく， より深い品質の問題や，変化のための方法を検討するのに良い時期です． > Meanwhile, much of the release team's energy will be focused on > coordinating the many major changes that are sure to hit the archive > shortly after sarge's release. We already know of a number of major > package changes coming up: gcc 4.0, python 2.4, xorg-x11 6.8.2, apt 0.6. > If you are planning any other transitions that will affect a lot of > packages, please let us know in advance. We will need to complete the > larger transitions as fast as possible, to get testing back into a > nearly releasable state quickly again after the release. 当面は，リリースチームの力はsargeのリリース後にアーカイブに行う変更に集中します． いくつかの変更がもうすぐ来るということは知っています： gcc 4.0, python 2.4, xorg-x11 6.8.2, apt 0.6． もし他の影響の大きい移行計画をかんがえているのであれば，リリースチームに事前に連絡してください． より大きな移行をできるだけはやく終了して，testingをsargeのリリース後に できるだけ早い時期にまたリリースできる状況までもっていきたいためです． > It's also not too early to begin staging complex transitions for etch in > experimental, particularly those transitions that will take a while to > debug. etchでの複雑な移行計画をexperimentalで開始するのにはもう早すぎるということはありません． > Post-sarge, we also know that with the new social contract, all > documentation needs to adhere to the DFSG. The biggest impact of this > change is that documentation that is licensed only under the current > version of the GNU Free Documentation License (GFDL) needs to be made > available under a license that meets the requirements of the DFSG, or > else be moved to non-free. Some maintainers have already opted to move > their GFDL documentation to non-free for sarge, but the vast remainder > will need to be dealt with soon after sarge's release to keep us on > track for etch. sarge以降では，あたらしいsocial contractがあるため，すべてのドキュメントはDFSGに従う 必要があります． この変更の最大の影響は，GFDLの現在のバージョンでライセンスされたドキュメントは DFSGに従ったライセンスの元で提供されるか，non-freeにいくか，ということになっています． 一部のメンテナはすでにドキュメントをnon-freeに移動していますが， 多くはsargeのリリース後に対応する必要があります． > Otherwise, it's business as usual for the sarge release. Please bear in > mind previous release team updates [1][2] when preparing package uploads > to unstable; and if you have any questions, please ask the release team > before uploading. これ以外については，あいかわらずです． > > Cheers, じゃねー． > -- > Steve Langasek [vorlon@debian.org] > Debian Release Team > > [0] http://lists.debian.org/debian-project/2005/03/msg00015.html > [1] http://lists.debian.org/debian-devel-announce/2005/02/msg00010.html > [2] http://lists.debian.org/debian-devel-announce/2004/11/msg00003.html > [2 Digital signature <application/pgp-signature (7bit)>] > -- 上川 純一 Junichi Uekawa, Debian Developer 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 http://www.netfort.gr.jp/~dancer/
Attachment:
pgpyTxk0EEKng.pgp
Description: PGP signature