On Tue, 1 May 2007 21:53:36 +0200 Maurice van der Pot <[EMAIL PROTECTED]> wrote: > > Too complicated. Bombarding the user with pointless alternatives is > > not the same as giving the user choice. > > I'm not sure why this is a reply to my message instead of the message > I replied to. They both provide more or less the same choice to the > user.
This thread is not about what's to be presented to the user. This thread is about the tests. Discussing what's to be presented to the user at this stage is premature. > > I'm also highly sceptical that the properties you listed are > > boolean. Resource hungry on an IP22 could be a walk in the park for > > an X16... > > I suppose that's possible, but if you look at it like that probably > everything can be called resource hungry on some machines. And if you > own a Blue Gene, you probably don't worry too much and enable > everything. > > Or do you mean that for instance tests involving lots of floating > point calculations are a big deal for cpus that use FP emulation? > Isn't that peanuts compared to the tests that would be called > resource hungry here? The point is, on some archs it is reasonable to expect that many users will have sixteen plus logical CPUs with frequencies measured in at least hundreds of MHz and memory measured in gigabytes, and many other users will have a single sub-hundred MHz CPU and maybe 128MBytes RAM if we're lucky. Test suites like, say, Boost's, are trivial to run on the former and impossible on the latter. > We wouldn't have to prove to anyone that a test is resource hungry. We > would just have to put each set of tests into one of two groups. If > you're not sure in which group it belongs, it probably doesn't matter > that much anyway. > > Look at merge times... everybody agrees openoffice, mozilla firefox, > gcc and qt take quite some time to emerge and that vim, bash and > iptables do not. That's the kind of distinction that would be useful. It's not that simple. You're forgetting that many archs routinely deal with systems with eight or sixteen way CPUs. If a package parallelises, it's fast on such systems. If it doesn't, it's immensely slow. > > > fex: > > Please don't abuse the English language in that manner. > > Since you took the time to highlight this apparently grave injustice > to the English language, would you please explain it to me so I can do > better next time? 'fex' isn't English, and it comes across as extremely annoying and unprofessional to many native speakers. It's worse than AOL style 'r u 2' things because 'e.g' is a similarly short and entirely correct alternative. -- Ciaran McCreesh
signature.asc
Description: PGP signature
