[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdYTzjCxEkueFWAzgVgqe4uy1H6rby7s7c+MkmRhgoaSbQ@mail.gmail.com>
Date: Tue, 5 Mar 2019 13:01:27 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Finn Thain <fthain@...egraphics.com.au>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>,
Andreas Schwab <schwab@...ux-m68k.org>,
Arnd Bergmann <arnd@...db.de>,
Stephen N Chivers <schivers@....com.au>,
Thomas Gleixner <tglx@...utronix.de>,
Kars de Jong <jongk@...ux-m68k.org>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Michael Schmitz <schmitzmic@...il.com>,
John Stultz <john.stultz@...aro.org>,
linux-m68k <linux-m68k@...ts.linux-m68k.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 00/14] m68k: Drop arch_gettimeoffset and adopt
clocksource API
On Tue, Mar 5, 2019 at 10:55 AM Finn Thain <fthain@...egraphics.com.au> wrote:
> That leaves bvme6000, hp300, mvme147 and mvme16x. Those have not been
> tested. Here are some options for those platforms:
>
> 1) Apply the patches untested (gaining new clocksources and some API
> modernization for m68k, while fixing old bugs and potentially introducing
> new bugs).
This is what I usually do with ARM machines when I don't get any
tests or reviews after a reasonable time lap, > month for sure is
a reasonable time for users to have all opportunity in the world to
test patches.
If things break, users will report it as is custom and the author will
be expected to work with them to fix them then, we do this all the
time.
Those users who want everything tested before it gets merged should
provide resources or time for testing.
Just my €0.01
Linus Walleij
Powered by blists - more mailing lists