Hi Greg, On Tue, Mar 15, 2005 at 02:10:47PM -0500, Greg Folkert wrote: > > > BTW, I am not sure this is really a good way to measure the use of an > > > architecture, mainly because users could use a local mirror if they have > > > a lot of machines of the same architecture. How about using popcon *in > > > addition* to that?
> > This isn't being used to measure the use of the architecture; it's being > > used to measure the *download frequency* for the architecture, which is > > precisely the criterion that should be used in deciding how to structure > > the mirror network. > Okay, I have to comment here, seeing that I personally have at two > separate locations, two complete mirrors, that I use nearly everyday. > They only update when a change in the archive is detected. That means > *MY* $PRETTY_BIG_NUMBER of usages of my own mirrors in each locale will > mean nothing. I do my own mirror(s) so as to reduce the load on the > Debian network. I actually scaled back what I use, now only having 5 > arches I support, SPARC(and UltraSPARC), Alpha, HPPA-RISC, PowerPC and > x86(Intel and otherwise). I dropped IA64 a while ago and will pickup > X86_AMD64 when it become part of Sid Proper. > How would you address the fact the bulk of my usage is not even seen by > your network. Hrm, in what sense is this something that needs to be "addressed" at all? If you use an internal mirror for your heavy internal usage, then surely you, as a user, don't need a diverse network of full public mirrors -- you just need one, solid mirror to download from, don't you? It makes perfect sense to me that if i386(+amd64) represents 10x as many downloads as all other archs combined, and the other archs combined represent 10x as much disk space needed as i386(+amd64), it's to our advantage to split the two so that we can benefit from mirror operators with either high bandwidth and little disk space (i386) or lots of disk space but less bandwidth (SCC). > > > >architecture requirements: > > > I would add as for the core set architecture: > > > - there must be a developer-accessible debian.org machine for the > > > architecture. > > > > This gets a little tricky for non-RC architectures, because if it's not > > already (or currently) a released architecture, we have no stable distro > > that can be installed on it, which means we have no security support for > > it; without security support, DSA isn't willing to maintain it, which > > means they probably aren't going to want to put a "debian.org" name on > > it, either -- and they certainly won't want to give it privileged access > > to LDAP. > > > > You could say that "there must be a developer-accessible machine for the > > architecture" without specifying "debian.org"; but I'm not sure that we > > should *require* this, either. Particularly for ports that are waning > > and are not expected to become RC architectures in the future, I think > > porters should be free to decide whether to spend the effort on > > maintaining such a machine since its absence only hurts that port, not > > the release. > I am currently in the process of acquiring rotated out of production > machines for 3 of the 5 architectures I support. I make a run to the > right-coast of the US once every 2 months and pickup sometimes 10 - 4-16 > processor machines with disk and typically a dozen of GB of memory and > gaggles of disk. I rebuild/recondition most of these machines and > distribute them to NPOs that need this kind of horsepower but can't > afford current stuff or even used stuff from those same suppliers. I put > Debian on them and this makes a huge investment in the long term health > of these Orgs. > If these machines are no longer fully supported by Debian... how can I > continue to do this. What does "fully supported" mean to you? What are the use cases for these machines? Which aspects of stable are required by these users? > How much is the difference between Debian running on "Humidifier in the > Basement" reputation, and a "We release more often than Ubuntu" > reputation? > But, serious, how much do you think Debian will be hurt with: > Compare these: > 1. Debian the "Universal OS" > 2. Debian the "Almost-Sorta-Kinda-used-to-be Universal OS" > 3. "Old as fossilized dinosaur poo, and as stable, but runs on > everything including the humidifier in the basement" > 4. "Very recent, since it doesn't really support NON-big 4 > processors anyway, so why not run Fedora Core" > Personally, I like 1 and 3. They are the 2nd and 3rd most important > technical reasons I chose Debian. 1st technical reason is the Debian's > maintainability. Please oh please let us not change my mind for me. I'm assuming your humidifier isn't connected to the public Internet, and doesn't need ongoing security support...? We're also constantly hearing from users who are using Debian in settings where they *would* benefit from security support, but are running testing or unstable because woody's fossilization factor is too high for them. How would you suggest that we balance these users' needs for a more frequent stable release, against the needs of users like yourself who need broader arch coverage? > > I'd much rather work towards a consensus. > Me, too. How about we have a CORE of Debian mirror infrastructure or > Base Install only for Stable, Testing, Unstable. > Then either on the same machine(s) or not, a separate mirror > infrastructure for anything beyond that. IOW, any packages that are not > included in the Base install. Including main, contrib and non-free for > Stable, Testing, Unstable and Experimental. Where as the Experimental is > only on the secondaries mainly for major changes testing anyhow. I really don't understand what problem you're trying to solve here. Mirroring is not the problem that causes release delays. > This is a very feasible, well thought out and scalable option. Heck, we > could release "Base-Install" and let the Buildd(s) for all the arches on > the secondaries catch up. If it's useful at all to do a stable release of just the "base-install", then we should question whether it makes sense to build the rest of the archive for these archs. But the first question is probably, what would be included in this base install? > This gives us five benefits: > 1. We will not have be worried about Stable being to OLD. It always > lets us have faster upgrade cycles to the Stable Base-install. > The Applications would follow shortly. Once the Stable > Application buildds get updated, they'll start churning out the > updated applications. I'm not willing to manage two-part releases; and there's no infrastructure in place to allow it. > 2. It allows nearly any number of architectures to be supported by > Debian. As long as they have a buildd to keep up with stable it > should be a no-brain-er. Um, one of the fundamental reasons we're looking at this question is because of the difficulty in ensuring, on an ongoing basis, that it is *possible* to build the packages in stable across all architectures (whether for toolchain reasons, or for reasons of hardware scarcity). I think your design really reduces to a restatement of the question, "why do we ask all of our architectures to build all of the packages?" I think this is a very pertinent question, and perhaps this discussion will lead us to an understanding of whether, and for which architectures, we should be asking for this. -- Steve Langasek postmodern programmer
signature.asc
Description: Digital signature
