Am Freitag, 7. Dezember 2012 schrieb Ingo Molnar: > * Martin Steigerwald <Martin@xxxxxxxxxxxx> wrote: > > > > The thing that people are complaining about is exactly the > > > reverse of this. It's *protecting* us from making mistakes, > > > and doesn't actually add any new interfaces in itself. > > > > > > This is why I'm so annoyed with this stupid thread. It's > > > been going on forever, and reverting that change WOULD BE > > > OBJECTIVELY A BAD IDEA. > > > > See, thats where you have a problem with "reality". > > > > It seems you cannot accept the fact that some developers > > disliked the process in which this change was pushed. [...] > > I don't think you have understood Linus's argument above. > > The "process" does not change the object technical merits of a > patch. Ever. This patch is _good_, and objectively good. No > amount of 'bad process' can make this patch bad. A patch can´t be objectively good or bad. Unlike one of you developers see yourself as a god who actually *really* knows it. Cause individual developers write patches, review patches, have oppinions about patches. Anything a subject created can´t be objective at all. Saying that one patch is *objectively* good IMO carries a message like "I know it better than you, go away" with it. There have been different oppinions about the patch quality. And that is what the review process was made for. At least so I thought. > Now, hypothetically, if this was an objectively bad patch, then > any "bad process" used to push it would add insult to injury and > it could be reason enough to flame Tytso twice as hard. I agree to Dave´s view here. If its good, why fear and bypass the review process upsetting other developers? Actually my argument is that using the review process the process can be more fluent. This way comments of other kernel developers can contribute to make this patch better than it is currently. And if in the end the subsystem maintainer wants to take a patch despite NACKs, he / she can still do it. At least thats how I understood it. But then he / shes does it openly instead of sneaking a patch in, possibly hoping other developers do not read git logs that closely. Granted the patch can still be improved and actually I do think the patch flag allocation deverses a better in source code comment about it. So I suggest: - On a next occasion Ted (or any other developer) goes through the review process again. Especially put controversial patches through the review process! - For this time discuss constructively how to make the bit reservation patch acceptable to Dave and Christoph, i.e. by adding some documentation. As I read out of it Dave and Christoph can basically agree with the bit reservation. Thus there is room for improving the patch. > But it turns out the patch was right and good, so kudos to Tytso > for cutting through the bike shed painting and politicks of > fsdevel - which "process" would have deprived us of a good > patch... I am astonished by the lack of confidence you seem to put into the review process, Ingo. Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
