* Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
2013-11-04 0:10 Linux 3.12 released .. and no merge window yet .. and 4.0 plans? Linus Torvalds
@ 2013-11-04 3:11 ` Tony Luck
2013-11-04 6:25 ` Ingo Molnar
` (6 subsequent siblings)
7 siblings, 0 replies; 21+ messages in thread
From: Tony Luck @ 2013-11-04 3:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
On Sun, Nov 3, 2013 at 4:10 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> And the reason I mention "4.0" is that it would be a lovely time to do
> that. Roughly a years heads-up that "ok, after 3.19 (or whatever),
> we're doing a release with *just* fixes, and then that becomes 4.0".
>
> Comments?
Unless you are planning to kick out releases significantly faster
than you have over the past few years ... then "roughly a year"
and "3.19" don't really match up. 3.17 would be a better guess.
This means you are ignoring the Knuth-ites who think 3.14 should
be followed by 3.141, 3.1415, 3.14159 etc. :-)
What would the rules look like for a "fixes-only" release? With
no merge window of new stuff would you enforce a "nothing
except regressions" policy after -rcN (for N >=3). That might
feel odd in a fixes release to tell someone that their fix isn't
going to be taken. But we all want the fixes release to converge
quickly so we can return to "ooh shiny" stuff - so "too big,
too late" should probably still be the rule.
Perhaps all the bugs to be fixed need to be logged in
bugzilla.kernel.org with some "for 4.0" tag by the
start of this fixes window - then we'd have some bound
on the release criteria for 4.0?
-Tony
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
2013-11-04 0:10 Linux 3.12 released .. and no merge window yet .. and 4.0 plans? Linus Torvalds
2013-11-04 3:11 ` Tony Luck
@ 2013-11-04 6:25 ` Ingo Molnar
2013-11-04 19:08 ` Josh Boyer
2013-11-07 4:40 ` Greg KH
2013-11-04 17:00 ` Alexander Holler
` (5 subsequent siblings)
7 siblings, 2 replies; 21+ messages in thread
From: Ingo Molnar @ 2013-11-04 6:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> So I may be pessimistic, but I'd expect many developers would go "Let's
> hunt bugs.. Wait. Oooh, shiny" and go off doing some new feature after
> all instead. Or just take that release off.
>
> But I do wonder.. Maybe it would be possible, and I'm just unfairly
> projecting my own inner squirrel onto other kernel developers. If we
> have enough heads-up that people *know* that for one release (and
> companies/managers know that too) the only patches that get accepted are
> the kind that fix bugs, maybe people really would have sufficient
> attention span that it could work.
>
> And the reason I mention "4.0" is that it would be a lovely time to do
> that. Roughly a years heads-up that "ok, after 3.19 (or whatever), we're
> doing a release with *just* fixes, and then that becomes 4.0".
>
> Comments?
I think the biggest problem wouldn't even be the enforcement of
bugfixes-only during that 2.5 months period, or kernel developers
surviving such a long streak of boredom, but v3.19 would also probably be
a super-stressful release to maintainers, as everyone would try to cram
their feature in there. And if anything important misses that window then
it's a +5 months wait...
The other problem is that kernel developers who do development typically
fix their own bugs within a week or two. It's not developers that
typically determine the stability of a subsystem but _maintainers_, and
the primary method of stabilization is, beyond being careful when merging
a patch, is to remember/monitor breakages and not merge new feature
patches from a developer until fixable bugs are fixed by the developer.
Bugs that go on longer are usually the bugs developers cannot reproduce,
the ones where the timing and progress depends on other, external people.
For example the NUMA fixes in v3.12 took a couple of full cycles to pin
down fully. I think waiting another 2-3 months will mostly bring idle time
and diminishing returns of the long, exponentially decaying tail of
bugfixes, IMHO.
Thirdly, _users_ interested in stability can already go to the -stable
kernel, will will suck up 1 cycle worth of bugfixes out of the main flow
of changes. So users already have a stability choice of v-latest and
'v-latest - 1' - plus the 'long term' stable kernels as well.
So IMO the main steering parameter of our kernel stabilization process is
the maintainer directly above a developer, the first-hop maintainer. For
90-95% of the commits you are the second hop maintainer or higher. So
whether in 4.0 you are going to take non-fixes will not directly affect
the stabilization process and flow that is already in place, assuming that
our current stabilization process is more or less healthy. It will (or
should) essentially track what our current -stable process is.
But we already have that process in place and it's working well IMO - the
problem isn't really effort or meta-maintanence issues but lack of good
stability metrics due to lack of kerneloops.org feedback, etc.
So ... unless you think our current stabilization flow is unhealthy and/or
you'd like to perform a natural experiment to measure it, why not just do
what worked so well for v3.0 and afterwards? Keep the existing process in
place, don't upset it just due to a (comparably) silly number tweak.
Maybe ask first-hop maintainers to be extra super diligent about new
features in v4.0 by imposing an internal merge window deadline 2 weeks
before the real merge window [a fair chunk of patches hit maintainer trees
in the last 2 weeks of the development window, and those cause much of the
regressions], maybe even reject a few pulls during the merge window that
blatantly violate these pre-freeze rules, but don't hold up the
low-latency flow of steady improvements - much of which is driver work,
platform enablement work, small improvements, etc., which isn't really a
big source of real regressions for the existing installed base.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
2013-11-04 6:25 ` Ingo Molnar
@ 2013-11-04 19:08 ` Josh Boyer
2013-11-04 19:53 ` Geert Uytterhoeven
2013-11-07 4:40 ` Greg KH
1 sibling, 1 reply; 21+ messages in thread
From: Josh Boyer @ 2013-11-04 19:08 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Linus Torvalds, Linux Kernel Mailing List
On Mon, Nov 4, 2013 at 1:25 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> So I may be pessimistic, but I'd expect many developers would go "Let's
>> hunt bugs.. Wait. Oooh, shiny" and go off doing some new feature after
>> all instead. Or just take that release off.
>>
>> But I do wonder.. Maybe it would be possible, and I'm just unfairly
>> projecting my own inner squirrel onto other kernel developers. If we
>> have enough heads-up that people *know* that for one release (and
>> companies/managers know that too) the only patches that get accepted are
>> the kind that fix bugs, maybe people really would have sufficient
>> attention span that it could work.
>>
>> And the reason I mention "4.0" is that it would be a lovely time to do
>> that. Roughly a years heads-up that "ok, after 3.19 (or whatever), we're
>> doing a release with *just* fixes, and then that becomes 4.0".
>>
>> Comments?
>
> I think the biggest problem wouldn't even be the enforcement of
> bugfixes-only during that 2.5 months period, or kernel developers
> surviving such a long streak of boredom, but v3.19 would also probably be
> a super-stressful release to maintainers, as everyone would try to cram
> their feature in there. And if anything important misses that window then
> it's a +5 months wait...
I'd agree with that, but it wouldn't be limited to just the final
non-bugfix release. It would be a year-long "shove as much as we can
in" push, and I'd be fearful of doing any distro kernel based on any
one of those releases. Clearly the subsystem maintainers would still
be fighting the good fight, but I'm concerned they'd be overwhelmed
and/or burnt out by the time 4.0 came around.
> The other problem is that kernel developers who do development typically
> fix their own bugs within a week or two. It's not developers that
> typically determine the stability of a subsystem but _maintainers_, and
> the primary method of stabilization is, beyond being careful when merging
> a patch, is to remember/monitor breakages and not merge new feature
> patches from a developer until fixable bugs are fixed by the developer.
Right.
josh
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
2013-11-04 19:08 ` Josh Boyer
@ 2013-11-04 19:53 ` Geert Uytterhoeven
0 siblings, 0 replies; 21+ messages in thread
From: Geert Uytterhoeven @ 2013-11-04 19:53 UTC (permalink / raw)
To: Josh Boyer; +Cc: Ingo Molnar, Linus Torvalds, Linux Kernel Mailing List
On Mon, Nov 4, 2013 at 8:08 PM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>> So I may be pessimistic, but I'd expect many developers would go "Let's
>>> hunt bugs.. Wait. Oooh, shiny" and go off doing some new feature after
>>> all instead. Or just take that release off.
>>>
>>> But I do wonder.. Maybe it would be possible, and I'm just unfairly
>>> projecting my own inner squirrel onto other kernel developers. If we
>>> have enough heads-up that people *know* that for one release (and
>>> companies/managers know that too) the only patches that get accepted are
>>> the kind that fix bugs, maybe people really would have sufficient
>>> attention span that it could work.
>>>
>>> And the reason I mention "4.0" is that it would be a lovely time to do
>>> that. Roughly a years heads-up that "ok, after 3.19 (or whatever), we're
>>> doing a release with *just* fixes, and then that becomes 4.0".
>>>
>>> Comments?
>>
>> I think the biggest problem wouldn't even be the enforcement of
>> bugfixes-only during that 2.5 months period, or kernel developers
>> surviving such a long streak of boredom, but v3.19 would also probably be
>> a super-stressful release to maintainers, as everyone would try to cram
>> their feature in there. And if anything important misses that window then
>> it's a +5 months wait...
>
> I'd agree with that, but it wouldn't be limited to just the final
> non-bugfix release. It would be a year-long "shove as much as we can
> in" push, and I'd be fearful of doing any distro kernel based on any
> one of those releases. Clearly the subsystem maintainers would still
> be fighting the good fight, but I'm concerned they'd be overwhelmed
> and/or burnt out by the time 4.0 came around.
I'm afraid to avoid that, you have to do the bug-fixing release *now*,
without early warning...
Yes, it screws all short-term planning, but it relieves the stress from all
maintainters, and puts the stress/blame on a single person, of which we
all know he can handle it and say "no".
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
2013-11-04 6:25 ` Ingo Molnar
2013-11-04 19:08 ` Josh Boyer
@ 2013-11-07 4:40 ` Greg KH
2013-11-07 9:01 ` Ingo Molnar
1 sibling, 1 reply; 21+ messages in thread
From: Greg KH @ 2013-11-07 4:40 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Linus Torvalds, Linux Kernel Mailing List
On Mon, Nov 04, 2013 at 07:25:40AM +0100, Ingo Molnar wrote:
>
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> > So I may be pessimistic, but I'd expect many developers would go "Let's
> > hunt bugs.. Wait. Oooh, shiny" and go off doing some new feature after
> > all instead. Or just take that release off.
> >
> > But I do wonder.. Maybe it would be possible, and I'm just unfairly
> > projecting my own inner squirrel onto other kernel developers. If we
> > have enough heads-up that people *know* that for one release (and
> > companies/managers know that too) the only patches that get accepted are
> > the kind that fix bugs, maybe people really would have sufficient
> > attention span that it could work.
> >
> > And the reason I mention "4.0" is that it would be a lovely time to do
> > that. Roughly a years heads-up that "ok, after 3.19 (or whatever), we're
> > doing a release with *just* fixes, and then that becomes 4.0".
> >
> > Comments?
>
> I think the biggest problem wouldn't even be the enforcement of
> bugfixes-only during that 2.5 months period, or kernel developers
> surviving such a long streak of boredom, but v3.19 would also probably be
> a super-stressful release to maintainers, as everyone would try to cram
> their feature in there. And if anything important misses that window then
> it's a +5 months wait...
I second this statement. The presure that people will be trying to cram
stuff into the "bugfix-only-release" - 1 will be huge, I see it today
when people are trying to guess as to what the next longterm-stable
kernel is going to be and they throw thing in that are half-baked just
because they know then can "fix it up" later with "bugfixes".
Maintainers have a hard enough time handling patches from developers,
trying to sift them into a "bugfix for this release" and "new
feature/option for next release" bucket, all the time having to educate
the developers that the merge window is for the maintainers, it does not
mean it is time for developers to send new subsystems / drivers /
features in after a 3.x-final release is done by you and expect it to
get reviewed and merged before 3.x-rc1 comes out.
> Bugs that go on longer are usually the bugs developers cannot reproduce,
> the ones where the timing and progress depends on other, external people.
> For example the NUMA fixes in v3.12 took a couple of full cycles to pin
> down fully. I think waiting another 2-3 months will mostly bring idle time
> and diminishing returns of the long, exponentially decaying tail of
> bugfixes, IMHO.
>
> Thirdly, _users_ interested in stability can already go to the -stable
> kernel, will will suck up 1 cycle worth of bugfixes out of the main flow
> of changes. So users already have a stability choice of v-latest and
> 'v-latest - 1' - plus the 'long term' stable kernels as well.
I think (but I'm probably biased here), that the -stable releases are
doing this pretty well. The fact that we had 4,000 bugfixes added to
the 3.0-stable kernel is a testament to the fact that developers and
users are paying more attention to the stable kernel releases, and are
asking for things to be included there that they hadn't been before.
It's taken 8 years to educate people about this process, and still,
maintainers don't do this today, as was evident in my kernel summit talk
about the stable tree. I think pushing those maintainers to start
tagging things for stable releases will benefit everyone much more than
having a "bugfix only" release.
> So ... unless you think our current stabilization flow is unhealthy and/or
> you'd like to perform a natural experiment to measure it, why not just do
> what worked so well for v3.0 and afterwards? Keep the existing process in
> place, don't upset it just due to a (comparably) silly number tweak.
I agree.
> Maybe ask first-hop maintainers to be extra super diligent about new
> features in v4.0 by imposing an internal merge window deadline 2 weeks
> before the real merge window [a fair chunk of patches hit maintainer trees
> in the last 2 weeks of the development window, and those cause much of the
> regressions], maybe even reject a few pulls during the merge window that
> blatantly violate these pre-freeze rules, but don't hold up the
> low-latency flow of steady improvements - much of which is driver work,
> platform enablement work, small improvements, etc., which isn't really a
> big source of real regressions for the existing installed base.
A 2 week merge window deadline would help out a lot with a number of
some of the bugs we get during the -rc cycle, but there's always going
to be issues found with wider testing, so I'm not quite sure that will
help out all that much in the end.
Anyway, I think this might be tougher than expected, and put more work
on the maintainers who are going to have to queue up stuff for 3 extra
months in their trees, because it's not like things are just going to
not come in to us because Linus isn't taking them at the moment.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
2013-11-07 4:40 ` Greg KH
@ 2013-11-07 9:01 ` Ingo Molnar
0 siblings, 0 replies; 21+ messages in thread
From: Ingo Molnar @ 2013-11-07 9:01 UTC (permalink / raw)
To: Greg KH; +Cc: Linus Torvalds, Linux Kernel Mailing List, Andrew Morton
* Greg KH <gregkh@linuxfoundation.org> wrote:
> > Thirdly, _users_ interested in stability can already go to the -stable
> > kernel, will will suck up 1 cycle worth of bugfixes out of the main
> > flow of changes. So users already have a stability choice of v-latest
> > and 'v-latest - 1' - plus the 'long term' stable kernels as well.
>
> I think (but I'm probably biased here), that the -stable releases are
> doing this pretty well. [...]
I do think it's pretty healthy. (I just have no idea how you manage the
firehose of patches! :-)
The biggest weak spot I see is the lack of unbiased kernel stability
metrics. bugzillas are self-selecting and suffer from the squeakiest whell
problem. Distros are conservative and under-staffed, so there's
significant lag there.
What would help a lot would be the revival of kerneloops.org.
Would people object to a mainline kernel opt-in kernel crash reporting
feature that would send a single UDP packet to a special port on
kernel.org on a kernel crash, sending a crash signature, a backtrace, a
kernel version string or so, a /dev/random generated system UUID, etc.?
A _lot_ of useful information can be squeezed into a 1.4k packet, and the
format would obviously be human readable but space-optimized.
The upstream kernel crash reporting feature is off by default but distros
could turn it on and would allow users to opt-in via a nice GUI question
on install or first-bootup. (It would also be a fundamentally distro
neutral reporting facility, with immediate, very quick feedback to kernel
developers.)
[ This crash reporting facility would utilize the netconsole
infrastructure to be able to send the crash-report packet from deep
inside just about any kernel context, and and would thus work better
than current oops gathering methods that all rely on user-space still
functioning when the crash happens. Users could query the crashes
reported for their UUIDs on kernel.org and could provide further
feedback if they want to. ]
> > Maybe ask first-hop maintainers to be extra super diligent about new
> > features in v4.0 by imposing an internal merge window deadline 2 weeks
> > before the real merge window [a fair chunk of patches hit maintainer
> > trees in the last 2 weeks of the development window, and those cause
> > much of the regressions], maybe even reject a few pulls during the
> > merge window that blatantly violate these pre-freeze rules, but don't
> > hold up the low-latency flow of steady improvements - much of which is
> > driver work, platform enablement work, small improvements, etc., which
> > isn't really a big source of real regressions for the existing
> > installed base.
>
> A 2 week merge window deadline would help out a lot with a number of
> some of the bugs we get during the -rc cycle, but there's always going
> to be issues found with wider testing, so I'm not quite sure that will
> help out all that much in the end.
I think we already had such a change in the recent past: Linus started
enforcing "no development during the merge window!" in ernest.
That step, combined with linux-next testing, made the merge window a _lot_
less painful over the last 1-2 years, eliminating much of the risk that
comes with pushing well intentioned but barely tested bits upstream.
So you are probably right that extending that by 1-2 weeks would probably
bring diminishing returns, because the "no development during the merge
window" policy already eliminates the worst offenders.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
2013-11-04 0:10 Linux 3.12 released .. and no merge window yet .. and 4.0 plans? Linus Torvalds
2013-11-04 3:11 ` Tony Luck
2013-11-04 6:25 ` Ingo Molnar
@ 2013-11-04 17:00 ` Alexander Holler
2013-11-04 19:49 ` Geert Uytterhoeven
2013-11-04 20:05 ` Olof Johansson
` (4 subsequent siblings)
7 siblings, 1 reply; 21+ messages in thread
From: Alexander Holler @ 2013-11-04 17:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
Am 04.11.2013 01:10, schrieb Linus Torvalds:
(...)
> Onto a totally different topic: we're getting to release numbers where
> I have to take off my socks to count that high again. I'm ok with
> 3.<low teens>, but I don't want us to get to the kinds of crazy
> numbers we had in the 2.x series, so at some point we're going to cut
> over from 3.x to 4.x, just to keep the numbers small and easy to
> remember. We're not there yet, but I would actually prefer to not go
> into the twenties, so I can see it happening in a year or so, and
> we'll have 4.0 follow 3.19 or something like that.
>
> Now, it's just a number (since we've long since given up on
> feature-related releases), and it's at least a year away, so why do I
> even mention it at all?
(...)
> Comments?
You could go towards the lovely number Pi (π):
3.12
3.13
3.14
3.141
3.1415
3.14159
3.141592
3.1415926
(...)
4.0
That would
- not be crazy numbers,
- make some math loving people happy,
- make people remembering that number,
- be a test for broken version number parsers,
- not as boring as usual version numbers,
- be in good tradition (e.g. TeX),
- make some maintainers hate me for that suggestion, ;)
- ...
Regards,
Alexander Holler
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
2013-11-04 17:00 ` Alexander Holler
@ 2013-11-04 19:49 ` Geert Uytterhoeven
2013-11-04 20:16 ` Alexander Holler
2013-11-04 23:02 ` Alexander Holler
0 siblings, 2 replies; 21+ messages in thread
From: Geert Uytterhoeven @ 2013-11-04 19:49 UTC (permalink / raw)
To: Alexander Holler; +Cc: Linus Torvalds, Linux Kernel Mailing List
On Mon, Nov 4, 2013 at 6:00 PM, Alexander Holler <holler@ahsoftware.de> wrote:
> 3.14
> 3.141
> 3.1415
> 3.14159
> 3.141592
> 3.1415926
> (...)
> 4.0
Since when does \pi converge to 4.0?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
2013-11-04 19:49 ` Geert Uytterhoeven
@ 2013-11-04 20:16 ` Alexander Holler
2013-11-04 23:02 ` Alexander Holler
1 sibling, 0 replies; 21+ messages in thread
From: Alexander Holler @ 2013-11-04 20:16 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linus Torvalds, Linux Kernel Mailing List
Am 04.11.2013 20:49, schrieb Geert Uytterhoeven:
> On Mon, Nov 4, 2013 at 6:00 PM, Alexander Holler <holler@ahsoftware.de> wrote:
>> 3.14
>> 3.141
>> 3.1415
>> 3.14159
>> 3.141592
>> 3.1415926
>> (...)
>> 4.0
>
> Since when does \pi converge to 4.0?
The attention span of most people is usually limited, so they won't
follow very long. Besides that people have a problem with very long
numbers. So an end is needed.
But extending that scheme to the stable series might be interesting too,
producing stable kernels
3.14.1
3.14.15
...
and
3.141.5
3.141.59
...
That would lead to an interesting looking kernel.org page before
switching to 4.0. And I assume it would make many people very happy when
the kernel finally switches to 4.0.
Regards,
Alexander Holler
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
2013-11-04 19:49 ` Geert Uytterhoeven
2013-11-04 20:16 ` Alexander Holler
@ 2013-11-04 23:02 ` Alexander Holler
2013-11-06 13:42 ` Keith Curtis
1 sibling, 1 reply; 21+ messages in thread
From: Alexander Holler @ 2013-11-04 23:02 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linus Torvalds, Linux Kernel Mailing List
Am 04.11.2013 20:49, schrieb Geert Uytterhoeven:
> On Mon, Nov 4, 2013 at 6:00 PM, Alexander Holler <holler@ahsoftware.de> wrote:
>> 3.14
>> 3.141
>> 3.1415
>> 3.14159
>> 3.141592
>> 3.1415926
>> (...)
>> 4.0
>
> Since when does \pi converge to 4.0?
Since 3.12 > 3.9. ;)
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
2013-11-04 23:02 ` Alexander Holler
@ 2013-11-06 13:42 ` Keith Curtis
2013-11-07 10:17 ` Alexander Holler
0 siblings, 1 reply; 21+ messages in thread
From: Keith Curtis @ 2013-11-06 13:42 UTC (permalink / raw)
To: linux-kernel, Linus Torvalds
I don't know if you all should spend time working only on bugs, but I
believe more time should be spent on the bug *list*. There are many
users patiently waiting for the kernel to work for their computer. The
pleas for help can be read in the bug database. The data can be used
to determine the selective places in the code that need more
brainpower. Send in the cavalry! Some have been waiting for years. I'm
running into 9 kernel / X bugs on my new Lenovo Yoga 2 with 3.11.6. An
unprioritized buglist also discourages people from entering new, valid
ones. As the issue list gets in better shape, things will become a bit
more relaxed. Quality metrics around bug count and age can be useful.
Regards,
-Keith
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
2013-11-06 13:42 ` Keith Curtis
@ 2013-11-07 10:17 ` Alexander Holler
2013-11-15 1:11 ` Keith Curtis
0 siblings, 1 reply; 21+ messages in thread
From: Alexander Holler @ 2013-11-07 10:17 UTC (permalink / raw)
To: Keith Curtis, linux-kernel, Linus Torvalds
Am 06.11.2013 14:42, schrieb Keith Curtis:
> I don't know if you all should spend time working only on bugs, but I
> believe more time should be spent on the bug *list*. There are many
> users patiently waiting for the kernel to work for their computer. The
> pleas for help can be read in the bug database. The data can be used
> to determine the selective places in the code that need more
> brainpower. Send in the cavalry! Some have been waiting for years. I'm
> running into 9 kernel / X bugs on my new Lenovo Yoga 2 with 3.11.6. An
> unprioritized buglist also discourages people from entering new, valid
> ones. As the issue list gets in better shape, things will become a bit
> more relaxed. Quality metrics around bug count and age can be useful.
The problem with many bugs is, that workarounds don't get accepted.
So the situation sometimes is that there is a driver which isn't that
perfect and when you try to fix something, the patch is refused because
it is as imperfect as the whole driver (even if the patch would cure
some problems).
So the only fix which won't be refused is a rewrite of the driver which
often just isn't what people are willing to do.
Regards,
Alexander Holler
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
2013-11-07 10:17 ` Alexander Holler
@ 2013-11-15 1:11 ` Keith Curtis
0 siblings, 0 replies; 21+ messages in thread
From: Keith Curtis @ 2013-11-15 1:11 UTC (permalink / raw)
To: Alexander Holler; +Cc: linux-kernel, Linus Torvalds
On Thu, Nov 7, 2013 at 5:17 AM, Alexander Holler <holler@ahsoftware.de> wrote:
> Am 06.11.2013 14:42, schrieb Keith Curtis:
>
>> I don't know if you all should spend time working only on bugs, but I
>> believe more time should be spent on the bug *list*. There are many
>> users patiently waiting for the kernel to work for their computer. The
>> pleas for help can be read in the bug database. The data can be used
>> to determine the selective places in the code that need more
>> brainpower. Send in the cavalry! Some have been waiting for years. I'm
>> running into 9 kernel / X bugs on my new Lenovo Yoga 2 with 3.11.6. An
>> unprioritized buglist also discourages people from entering new, valid
>> ones. As the issue list gets in better shape, things will become a bit
>> more relaxed. Quality metrics around bug count and age can be useful.
>
>
> The problem with many bugs is, that workarounds don't get accepted.
>
> So the situation sometimes is that there is a driver which isn't that
> perfect and when you try to fix something, the patch is refused because it
> is as imperfect as the whole driver (even if the patch would cure some
> problems).
> So the only fix which won't be refused is a rewrite of the driver which
> often just isn't what people are willing to do.
>
> Regards,
>
> Alexander Holler
>
I think this explains some of the bugs, but not many. I think a better
explanation is that there aren't metrics tracked by anyone, some
important drivers are understaffed / abandoned, and some people don't
care about their bug count. Of course, in the housing construction
business, and other fields, if you don't do a conscientious job on
your punch list, you'd get fired. Bug count goals are a great
mechanism, better than flame-mails, of increasing the quality of a
product.
I just wrote a review of an Arch install on a Lenovo Yoga 2. I post a
link to those who may find it interesting:
http://keithcu.com/wordpress/?p=3270 but in general, I'm making the
kernel points I care about here so you might just find it rambling /
duplicative ;-)
Reviving the kerneloops service is a good idea but it isn't a great
quality metric on its own because it only catches a small fraction of
the problems users run into. Kerneloops problems could be
de-duplicated and then entered into bugzilla. Another good service
might be where you can upload your logs, and they get analyzed and
bugs reported. I see confusing and worrying errors filling up my SDD
(75MB / day.) I've fixed it via a tweak to journald.conf, but there
shouldn't be so much given that the hardware is brand-new and not
broken.
It is friendly on LKML given how busy everyone is, and partially that
is because any frustrated users of desktop Linux are inspired by it,
and therefore polite and don't nag. But the user-facing customer
service isn't super great right now so consider yourself lucky! I read
a line that a good way to judge an airline is by what happens *after*
they lose your luggage. By that standard Linux Airways needs to
improve a bit more somehow.
The battle between testers and developers goes almost as far back as
the one between the sexes, and werewolves vs vampires. Currently, the
users are beating the good guys. Send in the cavalry.
Regards,
-Keith
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
2013-11-04 0:10 Linux 3.12 released .. and no merge window yet .. and 4.0 plans? Linus Torvalds
` (2 preceding siblings ...)
2013-11-04 17:00 ` Alexander Holler
@ 2013-11-04 20:05 ` Olof Johansson
2013-11-04 20:12 ` Hans de Bruin
` (3 subsequent siblings)
7 siblings, 0 replies; 21+ messages in thread
From: Olof Johansson @ 2013-11-04 20:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
On Sun, Nov 3, 2013 at 4:10 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> The reason I mention it is because I've been mulling over something
> Dirk Hohndel said during LinuxCon EU and the kernel summit. He asked
> at the Q&A session whether we could do a release with just stability
> and bug-fixes, and I pooh-poohed it because I didn't see most of us
> having the attention span required for that
> (cough*cough*moronic*woodland creature*cough*cough).
>
> So I may be pessimistic, but I'd expect many developers would go
> "Let's hunt bugs.. Wait. Oooh, shiny" and go off doing some new
> feature after all instead. Or just take that release off.
>
> But I do wonder.. Maybe it would be possible, and I'm just unfairly
> projecting my own inner squirrel onto other kernel developers. If we
> have enough heads-up that people *know* that for one release (and
> companies/managers know that too) the only patches that get accepted
> are the kind that fix bugs, maybe people really would have sufficient
> attention span that it could work.
>
> And the reason I mention "4.0" is that it would be a lovely time to do
> that. Roughly a years heads-up that "ok, after 3.19 (or whatever),
> we're doing a release with *just* fixes, and then that becomes 4.0".
>
> Comments?
Ingo has some very good points. I think this might be worth doing in
some form or other, but if it's worth a full release cycle is less
certain to me:
Essentially we already do this for every release, where the last
couple of weeks are strictly bugfixes only. While it's not what you're
proposing, the end result sounds to me more like a "forced" extension
of the -rc cycle by several weeks to let more of those fixes come in.
If you're doing a 3.20/4.0 that is bugfixes only, then why release
3.19 at all? If the only difference between the two is said fixes,
we'd be better off just holding on until the latter is released. Which
again comes back to in practice extending the release by several more
weeks of late -rcs.
The only benefit I can think of to make a 3.19 release is to pick up
more users, if some of them avoid -rcs but do use full releases
shortly after they are tagged. I don't know how common that is though.
-Olof
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
2013-11-04 0:10 Linux 3.12 released .. and no merge window yet .. and 4.0 plans? Linus Torvalds
` (3 preceding siblings ...)
2013-11-04 20:05 ` Olof Johansson
@ 2013-11-04 20:12 ` Hans de Bruin
2013-11-04 21:46 ` Linux 3.12 released " Jan Engelhardt
` (2 subsequent siblings)
7 siblings, 0 replies; 21+ messages in thread
From: Hans de Bruin @ 2013-11-04 20:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
On 11/04/2013 01:10 AM, Linus Torvalds wrote:
>
...
>
> Anyway..
>
> Onto a totally different topic: we're getting to release numbers where
> I have to take off my socks to count that high again. I'm ok with
> 3.<low teens>, but I don't want us to get to the kinds of crazy
> numbers we had in the 2.x series, so at some point we're going to cut
> over from 3.x to 4.x, just to keep the numbers small and easy to
> remember. We're not there yet, but I would actually prefer to not go
> into the twenties, so I can see it happening in a year or so, and
> we'll have 4.0 follow 3.19 or something like that.
>
> Now, it's just a number (since we've long since given up on
> feature-related releases), and it's at least a year away, so why do I
> even mention it at all?
>
> The reason I mention it is because I've been mulling over something
> Dirk Hohndel said during LinuxCon EU and the kernel summit. He asked
> at the Q&A session whether we could do a release with just stability
> and bug-fixes, and I pooh-poohed it because I didn't see most of us
> having the attention span required for that
> (cough*cough*moronic*woodland creature*cough*cough).
I would not trust 4.0 as a bug free and stable kernel. Now 4.0.99 I
would trust. Almost that is. because some developer would have asked the
4.0.y maintainer to commit his one day old 4.x bugfix to the 4.0.y tree
before lots of people would have tested it.
The 4.0 would only force a stable kernel maintainer to choose that
kernel as his next stable tree. If he does not 4.0 has no meaning at all.
The 4.0 also does not solve another problem. Since the regression team
stopped tracking bugs nobody really knows how many bugs have been
forgotten or ignored. There needs to be some sort of feedback-loop to
force people to fix problems before they invent new ones. I do not think
a bug-fix round once every 20 releases will accomplice that
--
Hans
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Linux 3.12 released .. and 4.0 plans?
2013-11-04 0:10 Linux 3.12 released .. and no merge window yet .. and 4.0 plans? Linus Torvalds
` (4 preceding siblings ...)
2013-11-04 20:12 ` Hans de Bruin
@ 2013-11-04 21:46 ` Jan Engelhardt
2013-11-05 5:06 ` Aldo Iljazi
2013-11-05 5:08 ` Alexander Holler
2013-11-04 21:57 ` Linux 3.12 released .. and no merge window yet " One Thousand Gnomes
2013-11-10 4:13 ` Alexandre Oliva
7 siblings, 2 replies; 21+ messages in thread
From: Jan Engelhardt @ 2013-11-04 21:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
On Monday 2013-11-04 01:10, Linus Torvalds wrote:
>
>Onto a totally different topic: we're getting to release numbers where
>I have to take off my socks to count that high again. I'm ok with
>3.<low teens> [...] [4.0 "ok, after 3.19 (or whatever),"]
What would you do when the major number becomes such an unpleasant
highteen number? (That will be in ~64 years if you wrap after x.19.)
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Linux 3.12 released .. and 4.0 plans?
2013-11-04 21:46 ` Linux 3.12 released " Jan Engelhardt
@ 2013-11-05 5:06 ` Aldo Iljazi
2013-11-05 5:08 ` Alexander Holler
1 sibling, 0 replies; 21+ messages in thread
From: Aldo Iljazi @ 2013-11-05 5:06 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Linus Torvalds, Linux Kernel Mailing List
Jan Engelhardt wrote:
>
> On Monday 2013-11-04 01:10, Linus Torvalds wrote:
> >
> >Onto a totally different topic: we're getting to release numbers where
> >I have to take off my socks to count that high again. I'm ok with
> >3.<low teens> [...] [4.0 "ok, after 3.19 (or whatever),"]
>
> What would you do when the major number becomes such an unpleasant
> highteen number? (That will be in ~64 years if you wrap after x.19.)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
I guess renaming the kernel would be an option. (Linus would be ~106
years old by the way.)
--
Aldo Iljazi
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Linux 3.12 released .. and 4.0 plans?
2013-11-04 21:46 ` Linux 3.12 released " Jan Engelhardt
2013-11-05 5:06 ` Aldo Iljazi
@ 2013-11-05 5:08 ` Alexander Holler
1 sibling, 0 replies; 21+ messages in thread
From: Alexander Holler @ 2013-11-05 5:08 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Linus Torvalds, Linux Kernel Mailing List
Am 04.11.2013 22:46, schrieb Jan Engelhardt:
>
> On Monday 2013-11-04 01:10, Linus Torvalds wrote:
>>
>> Onto a totally different topic: we're getting to release numbers where
>> I have to take off my socks to count that high again. I'm ok with
>> 3.<low teens> [...] [4.0 "ok, after 3.19 (or whatever),"]
>
> What would you do when the major number becomes such an unpleasant
> highteen number? (That will be in ~64 years if you wrap after x.19.)
Changing the counting base and going hex would offer some more years. So
after 9.19 he could switch to a.0 instead of 10.0. Or just call it then
LinuxNG and start with 1.0 again.
But to add something serious to the discussion too, I don't see a reason
why to make a bugfix-only version.
There should be no need to spend a version number for a bugfix only time.
E.g. just insert a bugfix-only time (handled like times at -rc7) before
a merge window for a new version. That would give people the possibility
to get their bugfix-patches into mainline in order to get them into the
stable series without the need to spend a version number.
Regards,
Alexander Holler
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
2013-11-04 0:10 Linux 3.12 released .. and no merge window yet .. and 4.0 plans? Linus Torvalds
` (5 preceding siblings ...)
2013-11-04 21:46 ` Linux 3.12 released " Jan Engelhardt
@ 2013-11-04 21:57 ` One Thousand Gnomes
2013-11-10 4:13 ` Alexandre Oliva
7 siblings, 0 replies; 21+ messages in thread
From: One Thousand Gnomes @ 2013-11-04 21:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
> The reason I mention it is because I've been mulling over something
> Dirk Hohndel said during LinuxCon EU and the kernel summit. He asked
> at the Q&A session whether we could do a release with just stability
> and bug-fixes, and I pooh-poohed it because I didn't see most of us
> having the attention span required for that
> (cough*cough*moronic*woodland creature*cough*cough).
I'm slightly back, so it's time to get the oar out ;)
I think there are two problems
1. It takes a lot of time to identify the stability fixes you need so
simply doesn't fit the release cycle.
2. You often need them in the unstable release to work out if they are
the right solution.
We have several "stable-ish" trees of 3.x.y format.
> So I may be pessimistic, but I'd expect many developers would go
> "Let's hunt bugs.. Wait. Oooh, shiny" and go off doing some new
> feature after all instead. Or just take that release off.
A look at some of the bug data shows that is all too true, and also that
despite the NSA fiasco and the like we have an awful lot of open,
probably real hits in coverity and the like which are effectively widely
available to the bad guys to analyse too.
> But I do wonder.. Maybe it would be possible, and I'm just unfairly
> projecting my own inner squirrel onto other kernel developers. If we
> have enough heads-up that people *know* that for one release (and
> companies/managers know that too) the only patches that get accepted
> are the kind that fix bugs, maybe people really would have sufficient
> attention span that it could work.
That ought to be happening every release. Every maintainer should be
asking "is my tree full of shit that needs cleaning up" and prioritising
it, including pushing back on developers to find a good balance between
fixing and new stuff.
> And the reason I mention "4.0" is that it would be a lovely time to do
> that. Roughly a years heads-up that "ok, after 3.19 (or whatever),
> we're doing a release with *just* fixes, and then that becomes 4.0".
It would be a good time as you went towards it to ask "what code is
buggy, problematic and simply not being maintained", and chuck it. It's
in the git history so if someone cares in the future they can ressurect
it but the tree has a lot of crap in it that slows down other work and
simply doesn't matter to anyone. (and if it does them rm -rf is a great
way to create new maintainers)
It might be very instructive to find the set of devices and archs that are
- not looking maintained
- not shipped by any vendor anyone has ever heard of
- or shipped by every vendor but no users show up in their collected data
Alan
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
2013-11-04 0:10 Linux 3.12 released .. and no merge window yet .. and 4.0 plans? Linus Torvalds
` (6 preceding siblings ...)
2013-11-04 21:57 ` Linux 3.12 released .. and no merge window yet " One Thousand Gnomes
@ 2013-11-10 4:13 ` Alexandre Oliva
7 siblings, 0 replies; 21+ messages in thread
From: Alexandre Oliva @ 2013-11-10 4:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
On Nov 3, 2013, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> we'll have 4.0 follow 3.19 or something like that.
> we could do a release with just stability and bug-fixes
> the reason I mention "4.0" is that it would be a lovely time to do
> that.
That sounds backwards. .0s are known for instability and major new
features that justify the major version number bump. A fixes-only
release would make more sense as a last breath of the 3.* series, before
(or even after?) 4.0 comes out.
One way this might work is with a shorter release cycle after 3.19, with
a fixes-only merge window, which would lead to a shorter stabilization
cycle than usual, a rock-solid 3.20 release at the end of that cycle,
during which new features would presumably have piled up for longer than
usual, so as to make for more new features in the subsequent merge
window, which would then justify a bump to 4.0.
The shorter cycle towards 3.20, which would make the 2 cycles towards
4.0 shorter than two usual cycles, may help relieve some of the pressure
to get features into 3.19, since the merge window for 4.0 won't be that
far off.
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
^ permalink raw reply [flat|nested] 21+ messages in thread