On Sun, 06 May 2007 22:33:55 +0200 Jakub Moc <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh napsal(a): > > On Sun, 6 May 2007 16:00:56 -0400 > > Dan Meltzer <[EMAIL PROTECTED]> wrote: > >>> Er, making elog logged by default would not solve the "requires an > >>> explicit read" problem. Making elog require an explicit read would > >>> be far too annoying because most elog notices are noise. We've > >>> been over this already. > >> Not if one filters it properly. ELOG_CLASSES="warn error" sounds > >> like a sane default to me. > > > > So you want users to have to explicitly acknowledge all ewarn > > notices? Now *that*'s a way of making the system useless by > > overusing it. > > Why would you acknowledge them? They are a different feature (plus, > seriously no mail gets automagically marked as read, if you use the > mail elog feature e.g. Maybe you should actually try to use the stuff > before recycling your 'our experience shows' and 'elog sucks' > scratched record once again.)
Maybe you should reread the context I've quoted. Dan is proposing making elog require explicit acknowledgements. > Plus, why's this thread been hijacked again for the paludis upgrade > stuff that doesn't need any news at all and that's been committed in > breach of GLEP42 itself?! Because some people won't stop looking for any available excuse to rant about anything that has or can be made to have 'paludis' in it, and they don't bother to read the rest of the discussion before they do so. > - drop this "users like it" and "experience has shown" stuff. > Experience based on 4 news items is no experience at all; experience > based on one-package overlay is irrelevant wrt a repository with > thousands of ebuilds; and "users like it" may be nice for one package > overlay, and a genuine PITA for a tree with thousands of ebuilds at > the same time. Repeating it doesn't go anywhere, nor will it make any > of your point more valid. And yet it's infinitely more experience than anyone else has at this point. When there's a better collection of data available we'll use that instead. -- Ciaran McCreesh
signature.asc
Description: PGP signature
