On Mon, Mar 14, 2005 at 05:09:02PM -0800, Steve Langasek wrote: > On Mon, Mar 14, 2005 at 04:38:35PM -0800, Thomas Bushnell BSG wrote: > > Steve Langasek <[EMAIL PROTECTED]> writes: > > > > The inclusion of ia64 in the release count is a projection, based on > > > where I believe things are today. Nothing the release team is doing > > > ensures that ia64 is going to be a viable port, a year from now when > > > we're trying to release etch; and nothing says that one or more of the > > > other ports won't be in a position to meet those criteria and get added > > > to the release list. > > > How can they be, since they will be off in another archive? You can't > > decide now to put an arch in scc and at the same time say you won't > > know whether it's in tier1 or tier2 until etch is close to release. > > Please re-read the proposal. Not all the architectures proposed for > release with etch are architectures that have enough download share to > justify keeping them on the primary mirror network; these are > *separate*, if heirarchically related, requirements.
I think one of the things that disturbs me with this is the lep from the previous plane of selective arch mirroring, to dropping anything but x86 from the main archive as seems outlined by the announcement. I really don't understand why we can't have everything on our main archive (on ftp-master or whatever), and then from there do some clever trick to mirror the arches depending on workload or whatever, with a small set of all-tier mirrors, and most mirrors for going for a reduced set of architectures, with ftp.<arch>.debian.org DNS resolving to a revolving list of mirrors handling the arch or whatever. So, could you clarify what this plan has as consequence for the developer, the upload queue, the place where packages are stored ? And explain how you got from the "let's diminish bandwidth requirements of our mirrors by not mirroring some arches" to the "let's kick most arches out of our archive to a second-class archive left to fend for itself" that was announced. > Releasing archs via scc.debian.org (and mirror network) is not an > obstacle, because scc.debian.org vs. ftp.debian.org is a *mirroring* > convenience only. The uploads still all go through > ftp-master.debian.org, which is where the release action happens. Ok, that clarifies the above, and is more in touch with what was previously planned. But why didn't you clearly state that in the announcement ? And will mirrors be able to decide which arch they want to mirror ? or will the set of arches be imposed by debian ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
