Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance

[Sasha Levin <Alexander.Levin@microsoft.com>]

On Mon, Sep 10, 2018 at 09:13:39AM -0700, James Bottomley wrote:
>On Mon, 2018-09-10 at 15:55 +0000, Sasha Levin via Ksummit-discuss
>wrote:
>> On Mon, Sep 10, 2018 at 08:47:07AM -0700, James Bottomley wrote:
>> > On Mon, 2018-09-10 at 15:38 +0000, Sasha Levin via Ksummit-discuss
>> > wrote:
>> > > On Mon, Sep 10, 2018 at 05:10:48AM -1000, Linus Torvalds wrote:
>> > > > On Mon, Sep 10, 2018 at 5:08 AM James Bottomley
>> > > > <James.Bottomley@hansenpartnership.com> wrote:
>> > > > >
>> > > > > On Mon, 2018-09-10 at 04:53 -1000, Linus Torvalds wrote:
>> > > > > >   "Live without email - possible?"
>> > > > >
>> > > > > Can I propose one small alteration to the topic:
>> > > > >
>> > > > >         "Patches without Email - Possible?"
>> > > >
>> > > > Yes, better. That's what I meant anyway.
>> > > >
>> > > > I still want the pull requests as email, and I still think
>> > > > email is often the best way to discuss things.
>> > >
>> > > Yes, email is great for discussions, but one concern I have is
>> > > that once discussions ended and a patch was merged, a lot of
>> > > those discussions are lost forever.
>> > >
>> > > It's somewhat easy to google a patch and look in lkml archives to
>> > > see some discussion as a result of the patch, but that's far from
>> > > perfect:
>> > >
>> > > 1. For different patch revisions, some discussions manage to hide
>> > > in the archives.
>> > > 2. Discussions that resulted in a patch being sent aren't linked
>> > > to the patch itself.
>> > > 3. Any discussions after the patch was merged aren't easy to
>> > > locate, specially if they're not in the same thread as the
>> > > original patch.
>> > >
>> > > This makes the lives of stable/distro folks more difficult than
>> > > it should be.
>> >
>> > I disagree on this.  I have had occasion, when identifying patches
>> > that screwed something up, to go back to the emails to try to find
>> > out who did this and why.  As long as you're used to search
>> > interfaces it's usually easy to find.  Usually they are all
>> > threaded under the patch but the worst case I've seen is when v1,
>> > v2 ... vn aren't linked by thread, but even there searching for the
>> > specific patch set (0/n) subject title works.  So I think the data
>> > is all there in multiple archives and we do have powerful enough
>> > tools to find it.
>>
>> Indeed, if *all* discussions happened in a single thread that was
>> used to submit the patch then sure - it's straightforward. However,
>> consider 2 scenarios that we encounter on a weekly basis:
>>
>> 1. We see a stable patch but not sure why/how it fixes an issue. The
>> patch itself doesn't have enough information and there was no
>> discussion after the patch was submitted. However, there was a lot of
>> discussion in a completely unrelated thread unlinked from the patch
>> submission. We can't find that because it doesn't refer to the patch
>> at all, it just describes the problem and a solution.
>
>This means the commit message was bad if it doesn't give you the
>information.  If a patch is tagged for stable you know the Maintainer
>made the decision before it was committed and they should have the
>courtesy to explain the user visible issues (or make sure the submitter
>did).  I really don't think you need to second guess the maintainer on
>this.

We don't always do it to "second guess". A more common case is us trying
to understand if we missed anything. Look at the following patch (from
last week) for example:

	https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d806afa495e2e2a1a726e26c5e44f27818e804c1

It states no functional changes, there are no related patches
before/after it, and yet it's still tagged for stable. Is it us missing
a related fix? Is it just not stable material? How do we explain it to
ourselves?

Another related reason is that I look at patches without stable tags
trying to understand whether they should go in stable or not, and then I
try to understand whether a certain patch is a fix or not.

>There is a workflow issue in that not all maintainers tag for stable,
>but I think that could be a separate topic.
>
>> 2. We pull in a patch into the stable tree, but a few days later
>> someone reports a bug and points to that patch. It's easier to solve
>> these cases by grepping through mailboxes before shipping out stable
>> releases, but it adds a considerable amount of effort.
>
>So, again, don't second guess; triage by user visible fixes.  If the
>patch doesn't really fix anything essential: revert it and notify the
>subsystem and if it does ask the relevant subsystem for help ... that
>is what they're there for.
>
>Sure, it's nice to have the historical information, but it shouldn't be
>your first port of call when you have a live subsystem and maintainer
>who should be on top of all the issues and should be more expert than
>you.

This is a bit different, in these cases I want to understand if I should
be applying an additional fix or reverting a patch from stable. The
sooner we get that information the less known buggy kernels will be
shipped out.


--
Thanks,
Sasha