[Ksummit-2012-discuss] [ATTEND] Process issues, device model, stable

Mark Brown broonie at sirena.org.uk
Tue Jun 19 22:35:27 UTC 2012


On Tue, Jun 19, 2012 at 02:43:31PM -0400, Steven Rostedt wrote:

> Well, code for new or unique devices is a different matter. Code that
> does not have an affect on anything else could be the exception to the
> rule.

The trouble here is that there's a strong tendency for new devices to
add new framework features, at least in the areas I work on.  The
greater the diff between the development code and what people are
actually deploying the less attractive it is to do the work to push
fixes and features out of individual drivers as it increases the
workload for getting things into products.

> Now if you are modifying core code, and perhaps just core ARM code, do
> you really want to rush it out, and risk breaking all ARM devices?

To be perfectly honest looking at the pattern of testing we get I'm not
overly concerned about the risk here.  Currently the testing is a split
between people running -next who are happy enough with the bleeding edge
and people who only start testing -rcs which serves the areas I look at
pretty well.

Some delay like the couple of weeks you're now suggesting is sensible
and I do tend to do something like that myself already, punting some
things for a release if the merge window seems too near in much the same
way Olof was describing, but I'm not sure it actually attracts
additional testers so much as give the -next people more chance to run
into issues.

> Basically, the more the code affects, the more it should be vetted
> before getting in. I have no problem with drivers for new devices
> skipping linux-next totally. As long as I do not own such device ;-)

The problem is ensuring that things actually get vetted.  Delays are
kind of a proxy for vetting but they are far fromm a perfect one and
there's a cost associated with them.  I think we're actually doing a
pretty good job right now in terms of providing integration trees at
varying stability points and the main thing we could do is to get better
coverage of those trees, especially -next.


More information about the Ksummit-2012-discuss mailing list