[Ksummit-discuss] [MAINTAINERS SUMMIT] Bug-introducing patches

[Geert Uytterhoeven]

Hi Daniel,

On Fri, Sep 7, 2018 at 11:07 AM Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> On Fri, Sep 7, 2018 at 10:40 AM, Geert Uytterhoeven
> <geert at linux-m68k.org> wrote:
> > On Fri, Sep 7, 2018 at 4:45 AM Steven Rostedt <rostedt at goodmis.org> wrote:
> >> Another issue about having fixes sit in linux-next for some time after
> >> -rc5, is that by that time, linux-next is filled with new development
> >> code waiting for the next merge window. A subtle fix for a bug that
> >> wasn't caught by linux-next in the first place (how else would that bug
> >> still be around by rc5?) is highly likely not to catch a bug with the
> >> fix to that subtle bug.
> >
> > Or the issue may never show up in linux-next at all.
> >
> > With strict by-subsystem merge policies, splitting a complicated patch set
> > by subsystem and scheduling it for inclusion across multiple kernel
> > versions can be challenging.  If anything slightly related is applied
> > independently, or due to a scheduling oversight or merge window miss, this
> > may lead to a regression in mainline that is never present in linux-next,
> > and usually only detected late, leading to a fix after -rc5.
>
> Aside: I'm still baffled at how much soc people split up their work.
> As you point out, testing becomes a game of luck, because integration
> happens only in the merge window for real.

SoC maintainers usually still have their own integration branches. E.g.
for Renesas ARM SoCs we have renesas-devel (DTS and drivers/soc/
integration) and renesas-drivers (renesas-devel + various subsystem
for-next branches).

> Anything I'm involved in I'm insisting on a proper topic branch that
> everyone pulls in, to make sure that we can test the full interactions
> when we actually feature-freeze before the merge window. Usually that
> means baking the merge into the drm side, because we do a lot more
> testing than others (e.g. upstream intel audio validation is done
> through the drm trees too - it doesn't work that great because it's
> post-merge only for sound).

We used to have topic branches for e.g. clock definitions, to be included
by both driver and DTS, but these days we start with a few hardcoded clock
numbers in the DTS, and replace them by symbols in the next release.
Less need for setup and communication for shared topic branches.

The original issue I described above usually doesn't show up for new
development, but for converting from e.g. old board code to new DT-based
code. In se, that should disappear, eventually ;-)

For new development, all pieces go in separately in maintainers trees
(clocks, pinctrl, DT bindings, drivers, DTS, ...), and start becoming
operational when all pieces have fallen together. That's one nice
property of DT ;-)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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