[Ksummit-2012-discuss] [ATTEND] linux-next and process

Brian Norris computersforpeace at gmail.com
Tue Jun 19 02:14:09 UTC 2012


On Mon, Jun 18, 2012 at 6:59 PM, Guenter Roeck <linux at roeck-us.net> wrote:
> On Mon, Jun 18, 2012 at 02:31:19PM -0700, Andrew Morton wrote:
>> On Mon, 18 Jun 2012 17:17:52 -0400 Dave Jones <davej at redhat.com> wrote:
>> > Then when Linus merges it all,
>> > we see a ton of new bugs appear that neither of us hit before.
>> > I've observed this for the last 2-3 releases, but it's probably been happening
>> > for longer.  This isn't driver specific either, it's core code that everyone runs.
>> >
>>
>> Oh my, I didn't know that.  So we have regressions going into mainline
>> which would have been detected beforehand, only they're not, because
>> code isn't getting a trial run in -next?  If so, that is a massive fail.
>>
>> It would be interesting to bisect some of these regressions, then do a
>> bit of investigation into how the offending patches managed to get into
>> mainline.  Perhaps a pattern will emerge...
>
> Someone published statistics a couple of months ago - I think it was for 3.2 or
> 3.3. My memory may be wrong, but at as far as I recall the percentage of commits
> in the commit window which did not go through -next was quite high, something
> in the range of 20 or even 30%.

How does something qualify as "in -next"? Residing for a certain time
period, with the same commit ID? If so, then some stats might be
misleading, as I know a submaintainer whose tree is in -next but is
constantly rebased and tweaked as development progresses and bugs are
fixed. Eventually, these commits make it into mainline, but their
commit ID may or may not have been present in -next simply because of
rebasing.

Brian


More information about the Ksummit-2012-discuss mailing list