Who are you talking to?
A more useful metric
Posted Sep 9, 2008 21:58 UTC (Tue) by sbishop (guest, #33061)
So Spender isn't a writer; that's fine. But his comments provide enough content to justify content in return, I think.
Posted Sep 9, 2008 23:13 UTC (Tue) by ballombe (subscriber, #9523)
Instead of trolling, accuse someone else of trolling! You get
basically the same result but you have 'the moral high ground'(tm).
If you are lucky, people believe you were responding to a comment that have
been deleted (!) and you can enjoy the ensuing confusion.
Maybe I am old fashioned, but I find trolls less painful than self righteous
(this post is intended as a meta-meta-troll).
Posted Sep 9, 2008 23:50 UTC (Tue) by drag (guest, #31333)
Posted Sep 10, 2008 0:15 UTC (Wed) by nix (subscriber, #2304)
Posted Sep 10, 2008 5:01 UTC (Wed) by paulj (subscriber, #341)
He's assuming an audience for his comment, a sceptical or even hostile audience at that. It's a pretty obvious rhetorical device.
I despise myself slightly for adding to it, but do we really need to open a *second* sub-thread commenting on the style of spender's commenting? His posts are otherwise are very relevant and interesting, and the true audience here are surely intelligent enough to be able to sidestep the style issues...
Posted Sep 10, 2008 6:31 UTC (Wed) by drag (guest, #31333)
Posted Sep 10, 2008 9:05 UTC (Wed) by nix (subscriber, #2304)
- can we fix the bugs? obviously yes, but then we get accused of cover-ups unless we raise the roof over every single bug: and see past posts from Al Viro about why it's ridiculously impractical to go via vendor-sec for every such bug: if major kernel developers refuse to use it because it's such an embargoing straitjacket, then castigating people because they don't use it is a waste of time.
- can we change things so that the bugs aren't introduced so fast? Maybe, but so far no method has been proposed that doesn't have the kernel developers recoiling in horror, and if a magic development method was known that avoided all security holes and didn't utterly devastate development rates, everyone would already be using it. (e.g. formal proving of absolutely everything from the spec on down reduces security holes, but is horrible for development. Multi-person review of every change, a-la OpenBSD, does the same, but a chronic lack of reviewers makes that hard: and areas like mm are sufficiently subtle that few people are qualified to be reviewers at all.)
Going back to even/odd doesn't strike me as being likely to happen, given that that system was imploding under the much lower change load that preceded git. A more rapidly alternating .26-is-stable .27-is-unstable scheme might work, but I'm not sure what that means other than giving a formal number to the post-merge-window -rc1 kernel, and I'm not sure how *that* would help. (It might encourage people to test the -rcs, I suppose!)
Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds