Linux 3.12 released .. and no merge window yet .. and 4.0 plans?

Linux 3.12 released .. and no merge window yet .. and 4.0 plans?

[Linus Torvalds]

I was vacillating whether to do an rc8 or just cut the final 3.12, but
since the biggest reason to *not* do a final release was not so much
the state of the code, as simply the fact that I'll be traveling with
very bad internet connection next week, I didn't really want to delay
the release. Sure, we had a number of driver reverts, and there was an
annoying auto-NUMA memory corruption fix series, but none of it was
really worth delaying 3.12 for.

But the fact that I'm going to be (effectively) off-line next week
means that I'm *not* opening the merge window for 3.13 yet - since I
won't have the bandwidth to really do merges anyway.

That doesn't mean that you can't send me pull request for the merge
window early, of course - maintainers can *always* send their pull
requests early rather than late, if they have everything lined up and
ready. But if you have some feature that still wants polishing, you
basically get a free week to do that.

So the two-week merge window for 3.13 will start a week from now. You
have an extra week. But that also means that I will be doubly
disappointed in anybody who then leaves their merge request until the
*end* of that two-week merge window.

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).

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?

                    Linus

---

Alex Deucher (3):
      drm/radeon: use sw CTS/N values for audio on DCE4+
      drm/radeon: disable bapm on KB
      drm/radeon/dpm: fix incompatible casting on big endian

Andrey Moiseev (1):
      Input: i8042 - i8042_flush fix for a full 8042 buffer

Arnaldo Carvalho de Melo (1):
      perf tools: Fix up /proc/PID/maps parsing

Baruch Siach (1):
      xtensa: don't use alternate signal stack on threads

Bastien Nocera (1):
      Input: wacom - export battery scope

Chen LinX (1):
      mm/pagewalk.c: fix walk_page_range() access of wrong PTEs

Dan Carpenter (6):
      uml: check length in exitcode_proc_write()
      staging: ozwpan: prevent overflow in oz_cdev_write()
      aacraid: missing capable() check in compat ioctl
      staging: wlags49_h2: buffer overflow setting station name
      Staging: bcm: info leak in ioctl
      Staging: sb105x: info leak in mp_get_count()

Daniel Vetter (1):
      drm/i915: Fix the PPT fdi lane bifurcate state handling on ivb

David Herrmann (2):
      Input: move name/timer init to input_alloc_dev()
      drm: allow DRM_IOCTL_VERSION on render-nodes

Deng-Cheng Zhu (1):
      MIPS: Perf: Fix 74K cache map

Dinh Nguyen (1):
      clk: socfpga: Fix incorrect sdmmc clock name

Greg KH (1):
      USB: Maintainers change for usb serial drivers

Greg Kroah-Hartman (12):
      Revert "USB: pl2303: distinguish between original and cloned HX chips"
      Revert "pl2303: improve the chip type detection/distinction"
      Revert "pl2303: improve the chip type information output on startup"
      Revert "pl2303: simplify the else-if contruct for type_1 chips
in pl2303_startup()"
      Revert "usb: pl2303: add two comments concerning the supported
baud rates with HX chips"
      Revert "usb: pl2303: also use the divisor based baud rate
encoding method for baud rates < 115200 with HX chips"
      Revert "usb: pl2303: increase the allowed baud rate range for
the divisor based encoding method"
      Revert "usb: pl2303: move the two baud rate encoding methods to
separate functions"
      Revert "usb: pl2303: remove 500000 baud from the list of
standard baud rates"
      Revert "usb: pl2303: do not round to the next nearest standard
baud rate for the divisor based baud rate encoding method"
      Revert "usb: pl2303: fix+improve the divsor based baud rate
encoding method"
      Revert "USB: pl2303: restrict the divisor based baud rate
encoding method to the "HX" chip type"

Greg Thelen (3):
      percpu: fix this_cpu_sub() subtrahend casting for unsigneds
      memcg: use __this_cpu_sub() to dec stats to avoid incorrect
subtrahend casting
      memcg: remove incorrect underflow check

James Bottomley (4):
      [SCSI] Revert "sg: push file descriptor list locking down to
per-device locking"
      [SCSI] Revert "sg: checking sdp->detached isn't protected when open"
      [SCSI] Revert "sg: no need sg_open_exclusive_lock"
      [SCSI] Revert "sg: use rwsem to solve race during exclusive open"

Jani Nikula (1):
      drm/i915/dp: workaround BIOS eDP bpp clamping issue

Jason Gerecke (2):
      Input: wacom - add support for ISDv4 0x10F sensor
      Input: wacom - add support for ISDv4 0x10E sensor

Jiri Olsa (3):
      perf hists: Add color overhead for stdio output buffer
      perf record: Split -g and --call-graph
      perf top: Split -G and --call-graph

Johannes Weiner (3):
      mm: memcg: use proper memcg in limit bypass
      mm: memcg: lockdep annotation for memcg OOM lock
      mm: memcg: fix test for child groups

Jonathan Austin (1):
      clk: fixup argument order when setting VCO parameters

Joseph Schuchart (1):
      perf script python: Fix mem leak due to missing Py_DECREFs on dict entries

Linus Torvalds (5):
      Kconfig: make KOBJECT_RELEASE debugging require timer debugging
      Fix a few incorrectly checked [io_]remap_pfn_range() calls
      i915: fix compiler warning
      vfs: decrapify dput(), fix cache behavior under normal load
      Linux 3.12

Linus Walleij (1):
      clk: nomadik: set all timers to use 2.4 MHz TIMCLK

Markos Chandras (1):
      MIPS: malta: Fix GIC interrupt offsets

Mathias Krause (1):
      ipc, msg: forbid negative values for "msg{max,mnb,mni}"

Max Filippov (1):
      xtensa: fix fast_syscall_spill_registers_fixup

Mel Gorman (6):
      mm: numa: Do not account for a hinting fault if we raced
      mm: Wait for THP migrations to complete during NUMA hinting faults
      mm: Prevent parallel splits during THP migration
      mm: numa: Sanitize task_numa_fault() callsites
      mm: Close races between THP migration and PMD numa clearing
      mm: Account for a THP NUMA hinting update as one PTE update

Mika Westerberg (1):
      Revert "ACPI / hotplug / PCI: Avoid doing too much for spurious notifies"

Mike Dunn (1):
      Input: pxa27x_keypad - fix NULL pointer dereference

Ming Lei (2):
      lib/scatterlist.c: don't flush_kernel_dcache_page on slab page
      scripts/kallsyms: filter symbols not in kernel address space

Nicolas Ferre (1):
      tty/serial: at91: fix uart/usart selection for older products

Paolo Bonzini (1):
      KVM: use a more sensible error number when debugfs directory
creation fails

Peter Zijlstra (2):
      perf: Fix perf ring buffer memory ordering
      perf/x86: Fix NMI measurements

Rafael J. Wysocki (2):
      Revert "epoll: use freezable blocking call"
      Revert "select: use freezable blocking call"

Rob Pearce (1):
      drm/i915: No LVDS hardware on Intel D410PT and D425KT

Russell King (2):
      mm: list_lru: fix almost infinite loop causing effective livelock
      ALSA: fix oops in snd_pcm_info() caused by ASoC DPCM

Simon Guinot (1):
      clk: armada-370: fix tclk frequencies

Takashi Iwai (7):
      ALSA: hda - Fix unbalanced runtime PM refcount after S3/S4
      ALSA: hda - Add missing initial vmaster hook at build_controls callback
      ALSA: hda - Fix silent headphone on Thinkpads with AD1984A codec
      ASoC: dapm: Fix source list debugfs outputs
      ASoC: dapm: Return -ENOMEM in snd_soc_dapm_new_dai_widgets()
      ALSA: hda - Add a fixup for ASUS N76VZ
      ASoC: wm_hubs: Add missing break in hp_supply_event()

Thomas Meyer (1):
      xtensa: Cocci spatch "noderef"

Tim Gardner (2):
      Input: cm109 - convert high volume dev_err() to dev_err_ratelimited()
      KVM: Fix modprobe failure for kvm_intel/kvm_amd

Ville Syrjälä (2):
      drm/i915: Add support for pipe_bpp readout
      drm/i915: Add HSW CRT output readout support

Vineet Gupta (1):
      ARC: Incorrect mm reference used in vmalloc fault handler

Wei Yongjun (1):
      MIPS: ralink: fix return value check in rt_timer_probe()

Yunkang Tang (1):
      Input: ALPS - add support for model found on Dell XT2

Zhouyi Zhou (1):
      perf tools: Fixup mmap event consumption

Алексей Крамаренко (1):
      USB: serial: ftdi_sio: add id for Z3X Box device

Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?

[Tony Luck]

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

Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?

[Ingo Molnar]

* 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

Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?

[Alexander Holler]

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

Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?

[Josh Boyer]

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

Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?

[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?

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

Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?

[Geert Uytterhoeven]

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

Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?

[Olof Johansson]

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

Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?

[Hans de Bruin]

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

Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?

[Alexander Holler]

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

Re: Linux 3.12 released .. and 4.0 plans?

[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.)

Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?

[One Thousand Gnomes]

> 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

Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?

[Alexander Holler]

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. ;)

Re: Linux 3.12 released .. and 4.0 plans?

[Aldo Iljazi]

 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

Re: Linux 3.12 released .. and 4.0 plans?

[Alexander Holler]

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

Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?

[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.

Regards,

-Keith

Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?

[Greg KH]

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

Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?

[Ingo Molnar]

* 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

Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?

[Alexander Holler]

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

Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?

[Alexandre Oliva]

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

Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?

[Keith Curtis]

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