People like you deserve to have a toilet kernel, and then I'de love to see you saying: "hey michael, you do 24/h benchmarks and didn't say anything to us!!!"
Originally Posted by paravoid
That's what all of you complaining of Michael's work deserve.
more relevant journalism, less "PTS will write this for me and i will trow in some generic text".
yes, PTS is great in acquiring test result, but author is the one that should interpret them and their causes and make them closer to wider audience.
quality over quantity FTW
P.S. titles like this one are definitely not necessary
Why not let people do what they are good in?
Michael's extensive benchmarks are important and needs to be done, but they are also very time consuming.
So what, now it's up to him to communicate with the developers / report bugs as well? That would also take up a lot of time, which means less benchmarking.
And even if he would report the bug and pinpoint the problem people will probably be complaining why he didn't fix it yet... Come on people it isn't a one man job...
All the info needed to create a bug report is here so almost any reader could do it. So why haven't YOU done it yet? (or me for that matter).
He could cut on the drama though. Specially the headers, but that probably gets him more hits, which i guess also mean more benchmarking in the end.
Keep up the great benchmarking Michael!
Really. This discussion is old.
This was discussed over and over.... I'm disappointed of this article.
The reasons for this?
Well. You're actually doing something that is in my opinion bashing - since the discussion I pointed out above, it is clear that the merge windows are not a time for testing. If everything builds, everyones happy. When the merge window has closed, the time for squashing bugs and eliminating the most troublesome stuff has come. And when that is finished, there is normally an rc... And when there is an rc, it is time to test for regression, and trying to find out what has gone wrong.
However. It is disappointing when someone simply bashes that something has gone wrong even before there was a rc (point 1), second point is very simple: Instead of questioning the development model and the work of the developer, use your shiny perfect software not for bashing, instead if u like benchmarking this lot, do it to aid the developers.
i agree with the sentiments that the language and title in the article should be toned down, because it certainly isn't a "huge disaster" and just sounds like sensationalism.
and it should be toned down because the real point of the article gets lost with the overdramatic language. the point is that it would be better to not have large regressions be able to enter the kernel _at all_. it'd be better to weed these out before they get committed, because even if they get fixed before the stable kernel release a) they will almost certainly take longer to fix and b) the fixes are more likely to be less effective than if designed properly in the first place. this seems like a valid point based on the evidence in the article.
I think what you mean is if the kernel developers paid you to run this service they'd get this information directly rather than you writing an article on it.
Originally Posted by Michael
Errm no, I am not looking for the kernel developers to pay me. As I've said before I am happy to run such trackers for free software projects such as the kernel as long as they are being used well.
Originally Posted by FireBurn
Uh. Because it still works? Linus's development model involves massively pulling commits he likes and then spending several RC releases hammering away at bugs and regressions.
Originally Posted by Michael
Hell, you yourself have reported on this. How is this suddenly a problem for you?
Originally Posted by dyna
Thanks for the benchmarks, Michael.
Tags for this Thread