Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 10 Sep 2018 18:23:49 +0200 (CEST)
From:   Thomas Gleixner <tglx@linutronix.de>
To:     =?ISO-8859-15?Q?Ville_Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>
cc:     LKML <linux-kernel@vger.kernel.org>,
        Dou Liyang <douly.fnst@cn.fujitsu.com>,
        Pavel Tatashin <pasha.tatashin@microsoft.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH] Revert "x86/tsc: Consolidate init code"
In-Reply-To: <20180910140710.GR5565@intel.com>
Message-ID: <alpine.DEB.2.21.1809101816320.1419@nanos.tec.linutronix.de>
References: <20180910121925.27682-1-ville.syrjala@linux.intel.com> <alpine.DEB.2.21.1809101443290.1292@nanos.tec.linutronix.de> <20180910140710.GR5565@intel.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1878809270-1536596630=:1419"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1878809270-1536596630=:1419
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT

On Mon, 10 Sep 2018, Ville Syrj?l? wrote:
> On Mon, Sep 10, 2018 at 02:48:45PM +0200, Thomas Gleixner wrote:
> > On Mon, 10 Sep 2018, Ville Syrjala wrote:
> > I asked for that before and I really do not understand why you do not even
> > make an attempt to report an issue first and allow the developers to work
> > with you to figure out what exactly is the problem. All you do is to send
> > an revert patch with a changelog which describes symptoms and probably
> > breaks more than it cures. Not really helpful, really.
> 
> You're reading way too much into this. The revert is just a point to
> start the conversion. I've found that it's the best way to get the
> attention of the relevant developers. Other kind of regression
> reports have an unfortunate habit of disappearing into /dev/null.

1) My workflow makes things tagged as BUG and REGRESSION urgent
   automatically while [PATCH] just is queued to the normal pile of
   backlog, i.e. at the end. It just sprang into my eyes by chance, but in
   general you might just get the contrary of what you are looking for.

2) A proper bug report with proper information (it's documented what should
   be provided), is way more worth than a patch with a mostly useless
   change log, which forces me to ask for the proper information instead of
   having it right away.

Thanks,

	tglx


--8323329-1878809270-1536596630=:1419--