On Mon, Mar 14, 2005 at 10:32:57AM +0100, Sven Luther wrote: > On Mon, Mar 14, 2005 at 12:23:12AM -0800, Steve Langasek wrote: > > On Sun, Mar 13, 2005 at 11:21:29PM -0800, Thomas Bushnell BSG wrote: > > > Steve Langasek <vorlon@debian.org> writes: > > > > On Sun, Mar 13, 2005 at 10:47:15PM -0800, Thomas Bushnell BSG wrote: > > > > > Steve Langasek <vorlon@debian.org> writes: > > > > > > The sh and hurd-i386 ports don't currently meet the SCC requirements, as > > > > > > neither has a running autobuilder or is keeping up with new packages. > > > > > It is impossible for any port under development to meet the SCC > > > > > requirements. We need a place for such ports. Where will it be? > > > > On the contrary, the amd64 port does, and is currently maintained > > > > completely outside official debian.org infrastructure. > > > The amd64 port did not always. Ports under development take time; the > > > amb64 port is at a late state in its development. I don't understand > > > why autobuilding is important to SCC; maybe if you could explain that > > > I would understand. > > The point is that the ftpmasters don't want to play host to various > > ports that *aren't* yet matured to the point of usability, where "being > > able to run a buildd" is regarded as a key element of usability in the > > port bootstrapping process. The amd64 team have certainly shown that > > it's possible to get to that point without being distributed from the > > main debian.org mirror network. > I don't really understand that point though, since the plan is to drop mirror > support for all minor arches, what does it cost to have a 3 level archive > support : > 1) tier 1 arches, fully mirrored and released. > 2) tier 2 arches, mostly those that we are dropping, maybe mirrored from > scc.debian.org in a secondary mirror network. (why not ftp.debian.org/scc > though ?). > 3) tier 3 arches, or in development arches, available on > ftp.debian.org/in-devel or something. > I don't see how having the in-devel arches be hosted on alioth instead on the > official debian ftp server would cause a problem. > Also, i don't understand why scc.debian.org is better than ftp.debian.org/scc, > really, ideally we could have /debian, /debian-scc, and /debian-devel or > something such. Is it really a physical problem fro ftp-master to held all > these roles ? What is it exactly that ftp-masters want to drop all these > arches for ? Nothing in the SCC plan implies a separate dak instance for scc.debian.org vs. ftp.debian.org. On the contrary, since there are release architectures that would not be distributed via ftp.debian.org under this plan, it is a requirement that all of the architectures in question continue to use ftp-master.debian.org for uploads and the dak instance. There is no problem for ftp-master to continue filling this role; but it already doesn't act as ftp.debian.org -- that role is filled by other machines. It seems likely that the scc.debian.org service will be on yet another machine, indeed for ease of mirroring. The minimum standards for SCC architectures exist so that the ftpmasters don't have to do a lot of setup work for a port that isn't going anywhere. Ports that are "going somewhere" should be able to meet the stated requirements fairly quickly, AFAICT. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature