[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debian-devel:16220] Re: Bits (Nybbles?) from the Vancouver release team meeting




こんにちは,上川です.

それとなく翻訳(気合いで意訳)してみました.
# 長いのと眠いので挫折気味です.



> 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バージョンのパッケージをアップロードするのをできるだけさけてほしいと
依頼する時期がきたということでもあります.
特に共有ライブラリ.
この件については最近のリリースアップデートには記述がありませんでしたが,それは6か月間
新しいバージョンをアップロードするな,とフリーズもしないで要求することが非現実的だったからです.
ただ,フリーズが近くなって来ましたので,共有ライブラリパッケージの変更を制限することが重要です.
ライブラリパッケージへの変更はそれに依存するパッケージをおくらせることが多く,
最近でもなんどもいたい目にあっているからです.
もしライブラリを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のように多くのアーキテクチャをもっているリリースを
継続することは不可能である,ということについて同意しました.
ましてや,今追加を待っているアーキテクチャを追加することなど無理です.

現実問題,11アーキテクチャをリリース可能な状態に維持することはリリースチーム,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のリリース対象とみなされていない8のアーキテクチャについて適用されます.
そしてまた,新しいアーキテクチャを希望する移植チームに関しても適用します.

> 
> 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