SELF: Anatomy of an (alleged) failure

Posted Jun 23, 2010 20:00 UTC (Wed) by dlang (guest, #313)
Parent article: SELF: Anatomy of an (alleged) failure

'lobbying on the kernel list' is not very productive.

it is productive to test the things that you are interested in (and especially be willing to test them in ways other than your 'normal' workload so that you can try and find ways that they break), but you also need to be willing to test alternatives proposed by kernel folks and be able to document (not just state) why what's being proposed is better.

it's especially not useful to show up from the blue strongly advocating the acceptance of any one feature and be completely silent on everything else

reiserfs4, Con's CFS, devfs, and wakelocks haven't had any lack of people pushing to get them accepted. In fact, they are all cases where the advocates went beyond being a benefit and many of them got to the point where their voices actually hurt the feature.

repeated demands to get feature X added to the kernel don't work

repeated statements that it's being shipped with distro X and therefor it should be merged don't work

continued statements that 'it works for me so it should be merged' don't work.

except for the outright demands, experience from people using a particular patch is helpful, and examples of it working well for people are useful data points, but they are not enough because there is always the potential that it's not going to work for other people or other situations. The more comprehensive the testing is the more useful the report is (i.e. desktop use only is not very helpful, especially after the first dozen or so people speak up and say it helps them)

SELF: Anatomy of an (alleged) failure

Posted Jun 24, 2010 2:02 UTC (Thu) by NicDumZ (guest, #65935) [Link]

I came here to say this. Exactly.

Lobbying a community never does good. It's annoying and just adds unnecessary noise that makes me feel like running away from the topic.
If you're unhappy with the development process, get involved, gain more importance by providing insightful reviews, and alternatives to patches that you dislike, and then people will listen.

But jumping in with "+1 I could use that" or "the review process here is awfuly broken"-type of comments is just not going to help

SELF: Anatomy of an (alleged) failure

Posted Jun 24, 2010 3:35 UTC (Thu) by vladimir (guest, #14172) [Link] (1 responses)

> repeated statements that it's being shipped with distro X and therefore it should be merged don't work

Why should this be true? After all, it's gotten heavily tested on a variety of workloads, etc., etc.

SELF: Anatomy of an (alleged) failure

Posted Jun 24, 2010 7:41 UTC (Thu) by dlang (guest, #313) [Link]

stated once, it's a datapoint that has value, stated 100 times it's nagging that does more harm than good.

in no way is it a definitive statement in any case. Every distro applies some patches that are inappropriate in and for the long term at some point, so just because they shipped it doesn't mean it's the right thing to do.

As an example of this, look at AppArmor. It's being shipped with Ubuntu, but the developers aren't leaning on that constantly, they are improving the code in response to complaints and getting closer to being merged. The fact that it is being shipped with ubuntu is one line in their multi-hundred line patch summary (in other words, it's not being ignored, but they aren't posting daily or even weekly asking for it to be applied because Ubuntu ships it).

SELF: Anatomy of an (alleged) failure

Posted Jun 24, 2010 7:12 UTC (Thu) by mingo (guest, #31122) [Link] (2 responses)

repeated statements that it's being shipped with distro X and therefor it should be merged don't work

While i agree with the gist of your posting, i'd like to insert a qualification to this statement: if a piece of out-of-tree code is in a distribution then that certainly strengthens that code, and strengthens the case for upstream inclusion as well.

Especially if a piece of out-of-tree code is included in a big Linux distribution then upstream maintainers do not ignore it. There's reasons why distributions get big, out of the pool of literally hundreds of baby distributions - and technical incompetence is certainly not amongst those reasons.

So upstream kernel maintainers definitely must not ignore cases where a distribution chooses to include a big chunk of out-of-tree code. Distribution developers are often closer to users/customers and feel the pain of user suffering more directly than upstream maintainers.

So distribution developers asking for upstream inclusion is very much material. (And if upstream is being stupid then the requests should be repeated ;-) Many of our best features were first test-driven in distributions.

On the other hand, non-developer users of those distributions asking for inclusion, especially if they lack the technical expertise to make the case for upstream inclusion (and i suspect this was the main case you meant) is certainly counter-productive.

Thanks,

Ingo

SELF: Anatomy of an (alleged) failure

Posted Jun 24, 2010 8:32 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

yes, that was part of the point I was making.

"it works for me" can be a useful posting, especially if a patch hasn't had much coverage, or you have an unusual workload/machine to test it on, but there is a huge difference between "it works for me" and "it works for me so that means that you should merge it". one "it doesn't work for me" will out shout a thousand "it works for me" posts

people 'lobbying' for something tend to not provide the testing that is so useful.

SELF: Anatomy of an (alleged) failure

Posted Jun 28, 2010 15:09 UTC (Mon) by rjw@sisk.pl (subscriber, #39252) [Link]

Well, in fact none of the examples given in the original article are about code submitted by a distribution. All of them, and also the ones from your previous comments, fall into the common category where someone, apparently from the "outside", brings us a feature (not being a device driver) complete with bells and whistles and wants us to take it. People generally don't react well to that, which is not surprising (to me at least).

Moreover, such "complete features" often do much more than is really necessary to address the particular problem their submitters had in mind when they started to work on them. In many cases this "extra stuff" makes them objectionable. In some other cases they attempt to address many different problems with one, supposedly universal, feature which confuses things. It also often happens that the feature submitters are not willing to drop anything or redesign, because of the amount of work it took them to develop their code, so the objections cause the entire feature to be rejected eventually.

Now, if you do something that people are not going to react well to and you give them good technical reasons to object to it, you shouldn't be surprised too much when it fails in the end, should you?