On Mon, Mar 14, 2005 at 11:23:48PM -0800, Steve Langasek wrote: > 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 <[EMAIL PROTECTED]> writes: > > > > > > On Sun, Mar 13, 2005 at 10:47:15PM -0800, Thomas Bushnell BSG wrote: > > > > > > Steve Langasek <[EMAIL PROTECTED]> 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.
Ok. This clarification was missing from your original announcement though, and there are still questions on how tier-2 arches will be able to setup their own testing support. Taking snapshots from unstable is not a viable solution. I understand that the testing scripts doesn't scale well, they run once for each arch, don't they, but moving testing to per-arch archives as i proposed in my 'build tier-2 arches from testing' proposal, asks the question of how the communication between the per-arch testing setup and the tier-1 setup communicate, and also where an arch porter uploads his arch-specific fixes to. He can either upload to the tier-1 unstable, with the risk of seing the upload hold by tier-1 testing-hold-up issues and not trickling down to the per-arch testing setup, or upload to the per-arch unstable archive, with the risk of the change getting lost when a new tier-1 upgrade comes. Ideally the fix should be uploaded to both tier-1 unstable and per-arch-unstable, and a mechanism setup for holding imports from tier-1 testing until the arch-fix is included in it. Obviously this needs : 1) cooperation from the tier-1 maintainers to apply the tier-2 arch fix, and suitable workarounds for if the maintainer doesn't do its job (NMU allowed after a given set of time or if a new upload was done without fixing the arch-specfic problem without a good reason). 2) a way to workaround packages that are kept out of testing for non-tier-2 related reasons. 3) discipline on the porters part to do and follow two uploads, and maybe a third if 2) happens, thus imposing a higher workload on them than necessarily needed. I don't know, maybe building from testing is not so good an idea after all, and some building from tier-1 unstable, with a testing script whose additional criteria would be for the package to be in tier-1 testing. Altough building from tier-1 testing is the most natural idea if there is hope of tier-2 stable point release to happening. > 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. but cutting stable releases, testing and security updates just because we don't really need such a wide mirror network is way overkill. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
