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

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

[Daniel Vetter]

Hi all,

I've read Laura's recent blog post on community management in the
linux kernel and want to pick it up:

https://www.labbott.name/blog/2018/09/04/kernel-community-management/

I think for pratical reasons (the linux kernel is huge) focusing on
subsystems is more useful, at least in the short term. Much easier to
experiment with new things in smaller groups. That's why I added
"subsystem governance". If there's enough interest on specific topics
we could schedule some BOF sessions, otherwise just hallway track with
interested parties.

Specific topics I'm interested in:
- New experiments in group maintainership, and sharing lessons learned
in general.
- Assuming it gets accepted I think my LPC talk on "migrating to
gitlab" will raise some questions, and probably overflow into hallway
track or a BOF session.
- I've held a somewhat controversially received talk earlier this
year. I'm happy to do a Q&A on that, if there's interest.

But I'm open to anything else really on the larger topic of community mangement.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Linus Torvalds]

On Sun, Sep 9, 2018 at 10:59 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> I think for pratical reasons (the linux kernel is huge) focusing on
> subsystems is more useful, at least in the short term. Much easier to
> experiment with new things in smaller groups.

I think that realistically, it's never going to be anything *but*
subsystem-specific, not just because the kernel is huge.

There are simply often very different concerns.

An individual filesystem can be a big project, and people work on
filesystems for decades. They can get quite complex indeed. But at the
same time, an individual filesystem just doesn't tend to *impact*
other things. Sure, we may end up adding features to the VM or the VFS
layer to make it possible for it to do some particular thing, and we
may end up having lots of common code that a lot of filesystems end up
sharing, but in a very real sense, it is its own _mostly_ independent
thing, and what happens inside the community for that filesystem
doesn't tend to much affect anybody else.

Same goes for a lot of drivers. Yes, they have connections to the
outside, but what happens in one driver seldom affects anything else.

Equally importantly, filesystem changes can generally be tested with a
fairly targeted test-suite. When you make changes to one filesystem,
you need to test only _that_ filesystem.

The same _tends_ to be true for drivers too, although there testing
can be "interesting" because of the hardware dependency - a single
driver often covers a few tens (to a few hundred) different hardware
implementations. But the changes still don't tend to affect *other*
devices.

But things change once you start going up from individual filesystems
or drivers to a common layer. Making changes to a common layer is
simply _fundamentally_ way more painful. Sure, part of the pain is
that now you have to convert all the filesystems or drivers that
depended on that common layer to the new changes, but a large part is
simply that now the changes affect many different kinds of filesystems
or drivers, and testing is *much* harder.

You obviously see that with the whole drm layer (example: atomic
modesetting). That's still a fairly small set of different drivers
(small in number, not in code-size), and it already causes issues.

At the other end of the spectrum, some of the most painful changes
we've ever done have basically gone across *all* drivers, and caused
untold bugs for the better part of a decade. I'm thinking of all the
power management work we did back ten+ years ago.

The VM people (and some other groups - the scheduler comes to mind)
have had a different kind of issue entirely: not that the kernel has
tons of "sub-drivers" that depend on them - although that obviously is
true in a very real sense for any memory allocator etc - but simply
that there are lots of different loads. In a filesystem or a driver,
you can have a test-suite for correct behavior, but the behavior is
largely the same. When it comes to VM or scheduler, the problem is
that you have different loads, and performing well on one load does
not mean at all that you do well on another.

We had a few years when people were pushing scheduler rchanges without
really appreciating that "your load isn't everybody elses load" issue.

In contrast, in drivers and filesystems, things are usually more
black-and-white wrt "does this work well".  Yes, yes, you have latency
vs throughput issues etc, and you might have some scalability issues
with per-cpu queues etc, but at the individual driver level, those
kinds of concerns tend to not dominate. You want a stress-test setup
for testing, but you don't need to worry too much about lots of crazy
users.

So different areas of the kernel just tend to have different concerns.
You can allow people to work more freely on a driver that doesn't
affect other things than on something that possibly screws over a lot
of other developers.

But if we find "models that work", maybe we can at least have
processes that look a bit more like each other, even across
subsystems.

> That's why I added
> "subsystem governance". If there's enough interest on specific topics
> we could schedule some BOF sessions, otherwise just hallway track with
> interested parties.

So what I think would be good is to not talk about some nebulous
"community management", but talk about very specific and very real
examples of actual technical problems.

Partly exactly *because* I think the areas are not all the same, and
the friction points are likely *between* these areas that may even
have really good reasons to act differently, and mostly they are
independent and have little interaction, but then when interaction
happens, things don't work well.

IOW, if we have the top-level maintainers around, we should have a
gripe-fest where people come in and say "Hey, you, look, this
*particular* problem has been around for a year now, there's a patch,
why did it not get applied"?

Don't make it about some nebulous "we could do better as a community".

Instead, make it about some very *particular* issue where the process
failed. Make it something concrete and practical.

   "Look, this patch took a year to get in, for no good reason".

Or

  "Look, here's a feature that I *tried* to get accepted for a month,
nothing happened, so I gave up".

And if we have a few of those, maybe we can see a pattern, and perhaps
even come up with some suggestion on how to fix some flow.

And if people can't come up with particular examples, I don't think
it's much worth discussing. At that point it's not productive.

We need to name names, show patches, and talk about exactly where and
how something broke down.

> Specific topics I'm interested in:
> - New experiments in group maintainership, and sharing lessons learned
> in general.

I think that's good. But again, partly because these kinds of subjects
tend to devolve into too much of a generic overview, may I suggest
again trying to make things very concrete.

For example, talk about the actual tools you use. Make it tangible. A
couple of years ago the ARM people talked about the way they split
their time to avoid stepping on each other (both in timezones, but
also in how they pass the baton around in general, in addition to
using branches).

And yes, a lot of it probably ends up being "we didn't actually make
this official or write it up, but we worked enough together that we
ended up doing XYZ". That's fine. That's how real flows develop. With
discussion of what the problems were, and what this solved.

In other words, make it down to earth. Not the "visionary keynote",
but the "this is the everyday flow".

> - Assuming it gets accepted I think my LPC talk on "migrating to
> gitlab" will raise some questions, and probably overflow into hallway
> track or a BOF session.

I've not used gitlab personally, but I *have* used github for a much
smaller project.

I have to say, the random and relaxed model is enjoyable. I can see
how somebody coming from that, then finds the strict kernel rules (and
_different_ rules for different parts) off-putting and confusing.

At the same time, I have to say that people need to keep in mind that
the kernel is *different*. We're not a small project with five
developers that isn't all that critical. Some of our off-putting
development models are there for a very very good reason. I think a
lot of people who find the kernel unfriendly just don't appreciate
that part.

The kernel used to be pretty free-wheeling too. 20+ years ago.

And I still hate how github ends up making it really really easy to
make horribly bad commit messages, and it encourages a "just rebase on
top of the integration branch" model, and I do not believe that it
would ever work for the kernel at large. Too much room for chaos.

BUT.

I do think it's still instructive to look at how those "fun small
projects" work. Having the whole web interface and a more relaxed
setup is a good thing. And it's probably *better* than the strict
rules when you don't really need those strict rules.

So I do believe that it could work for a subsystem. Because "too much
room for chaos" ends up being nice when you don't want to worry about
the proper channels etc.

For example, we've had the "trivial tree", which tends to be a really
thankless project, that might well be managed way more easily by just
having a random tree that lots of people can commit to, and we could
even encourage the github (gitlab?) model of random non-kernel people
just sending their random trees to it, and have then the group of
committers be able to merge the changes (and at least on github, the
default merge is just a fast-forward, so it actually acts more like a
patch queue than a git tree).

And the reason I mention the trivial tree is not because the trivial
tree itself is all that interesting or because I'd like to belittle
that model ("that will only work for trivial unimportant stuff"), but
because it might be a good area to experiment in, and a way to get
people used to the flow.

Because if somebody is willing to every once in a while look at
trivial tree pull requests and merge them to the trivial tree, maybe
that person will start using the same flow for their "real" work.

And I do think that "patches by email" doesn't scale. I've been there,
done that, and I got the T-shirt.

I used tools that some people absolutely hated to get out of that
rat-hole. When that failed, I had to write my own.

So I very much do think that email doesn't really work at scale.

But I know the kernel people who still do real development (as opposed
to me) work that way.

So let me suggest a topic for the maintainer summit:

  "Live without email - possible?"

just to get that ball rolling

             Linus

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

[James Bottomley]

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

The reason is I've had too much experience with other open source
projects who religiously oppose email based interaction (some of them
because the kernel uses it) and have seen the amount of difficulty and
friction it causes and I really don't think we want to go down that
exclusionary road.  I think we always need a way of accepting patches
by email because it's the easiest communication mechanism for people
who aren't contributors.  However, I think we could discuss not having
email for our main workflows.

Some issues this brings up that various other communities solve in
different ways

   1. How do reviews happen?  Non email projects tend to have only one
      review mechanism (gerrit, github, gitlab, etc.) and stick to it.  Do
      we want to pick a technology or allow multiple?  I don't think this
      is kernel wide, it could be a sybsystem choice.
   2. Do we want to look at other review concepts like the core reviewers,
      since reviewers will now at least need accounts on whatever system
      it is ... it could finally be the way we give proper credit to
      reviewers.
   3. Pull requests to Linus ... what technology do you want to choose?

Note we don't even have to have a big bang on this: we could start with
non-email pull requests to Linus and then extend outwards.

James

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

[Linus Torvalds]

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.

It was more the "patch-bomb" model that I think it really wearing
people down. I know it used to wear me down. I'm *so* much happier
doing pull requests than handling patches.

              Linus

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

[Jiri Kosina]

On Mon, 10 Sep 2018, James Bottomley wrote:

>    1. How do reviews happen?  Non email projects tend to have only one
>       review mechanism (gerrit, github, gitlab, etc.) and stick to it.  Do
>       we want to pick a technology or allow multiple?  I don't think this
>       is kernel wide, it could be a sybsystem choice.

Yeah, but OTOH even now I've heard a lot of feedback about the irregular 
contributors / newcomers being confused by different subsystems having 
different processess and requirements; and those are basically just rather 
"minor" things currently (bugzilla usage, patchwork usage, subscriber-only 
mailinglists, etc), but it's still enough to confuse the hell out of 
people.

-- 
Jiri Kosina
SUSE Labs

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

[James Bottomley]

On Mon, 2018-09-10 at 17:13 +0200, Jiri Kosina wrote:
> On Mon, 10 Sep 2018, James Bottomley wrote:
> 
> >    1. How do reviews happen?  Non email projects tend to have only
> > one review mechanism (gerrit, github, gitlab, etc.) and stick to
> > it.  Do we want to pick a technology or allow multiple?  I don't
> > think this is kernel wide, it could be a sybsystem choice.
> 
> Yeah, but OTOH even now I've heard a lot of feedback about the
> irregular contributors / newcomers being confused by different
> subsystems having different processess and requirements; and those
> are basically just rather "minor" things currently (bugzilla usage,
> patchwork usage, subscriber-only mailinglists, etc), but it's still
> enough to confuse the hell out of people.

Well, I don't think it has to be a github/gitlab process.  It's not
impossible to craft a bugzilla based process for handling patches ...
although I bet it would have to be a pretty dedicated bugzilla person
to sign up to fix all the problem interactions and missing pieces.

I also don't think the confusion will go away.  Even most github
projects have huge issues in this regard: fine, it's easy to submit a
pull request, but not at all clear what you do when travis auto rejects
the pull because you're not in the cabal or you didn't sign the correct
CLA or it simply got it wrong and crashed before it got to the end of
testing your code.

James

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

[Daniel Vetter]

I need to split this up, otherwise I'll get lost on the different
sub-topics. I'll start with the easy ones.

On Mon, Sep 10, 2018 at 4:53 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>> Specific topics I'm interested in:
>> - New experiments in group maintainership, and sharing lessons learned
>> in general.
>
> I think that's good. But again, partly because these kinds of subjects
> tend to devolve into too much of a generic overview, may I suggest
> again trying to make things very concrete.
>
> For example, talk about the actual tools you use. Make it tangible. A
> couple of years ago the ARM people talked about the way they split
> their time to avoid stepping on each other (both in timezones, but
> also in how they pass the baton around in general, in addition to
> using branches).
>
> And yes, a lot of it probably ends up being "we didn't actually make
> this official or write it up, but we worked enough together that we
> ended up doing XYZ". That's fine. That's how real flows develop. With
> discussion of what the problems were, and what this solved.
>
> In other words, make it down to earth. Not the "visionary keynote",
> but the "this is the everyday flow".

Yup, fully agreed. We don't need another overview over group
maintainer ship. Also I don't think an update from arm-soc/tip or drm
is interesting either. I think only if there's a new group/subsystem
trying this out, with all the nitty-gritty details of "this totally
blew up in our faces" and "this worked shockingly well" and "here we
need to improve still, we're not happy" is what I'm looking for.
Without those details there's nothing really to learn, beyond just
rehashing one of the old discussions. I guess I should have put more
emphasis on _new_ experiments :-)

And if nothing changed, no new groups I think think we should table
this right away.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Sasha Levin]

On Mon, Sep 10, 2018 at 05:13:05PM +0200, Jiri Kosina wrote:
>On Mon, 10 Sep 2018, James Bottomley wrote:
>
>>    1. How do reviews happen?  Non email projects tend to have only one
>>       review mechanism (gerrit, github, gitlab, etc.) and stick to it.  Do
>>       we want to pick a technology or allow multiple?  I don't think this
>>       is kernel wide, it could be a sybsystem choice.
>
>Yeah, but OTOH even now I've heard a lot of feedback about the irregular
>contributors / newcomers being confused by different subsystems having
>different processess and requirements; and those are basically just rather
>"minor" things currently (bugzilla usage, patchwork usage, subscriber-only
>mailinglists, etc), but it's still enough to confuse the hell out of
>people.

Similarily with stable tags: some subsystems do not allow authors to tag
patches for stable, which in turn means people don't add these tags in
any of their patches, even to other subsystems, to "play safe".


--
Thanks,
Sasha

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

[Sasha Levin]

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.

Yes, some maintainers started adding links to lkml archives, but those
are very inconsistent and often just point to the patch submission
rather than relevant discussions.

I'm not sure what's a good way to solve this, but I'd really like to
stop losing this valuable information as a result of the current
process.


--
Thanks,
Sasha

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

[James Bottomley]

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.

James

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

[Konstantin Ryabitsev]

On Mon, Sep 10, 2018 at 03:38:07PM +0000, Sasha Levin via Ksummit-discuss wrote:
>Yes, some maintainers started adding links to lkml archives, but those
>are very inconsistent and often just point to the patch submission
>rather than relevant discussions.
>
>I'm not sure what's a good way to solve this, but I'd really like to
>stop losing this valuable information as a result of the current
>process.

This is partly the goal behind cregit:

https://cregit.linuxsources.org/

The plan is that the next version of cregit will become an official 
kernel.org resource some time mid-next year, and will aggregate as much 
information about the kernel code as it can from various places, 
including patchwork.

-K

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]

On Mon, Sep 10, 2018 at 03:38:07PM +0000, Sasha Levin via Ksummit-discuss wrote:

> Yes, some maintainers started adding links to lkml archives, but those
> are very inconsistent and often just point to the patch submission
> rather than relevant discussions.

> I'm not sure what's a good way to solve this, but I'd really like to
> stop losing this valuable information as a result of the current
> process.

Patchwork does a credible job of that for me - I especially like the
fact that you can look things up by hash from a commit in your local
tree.  It's not ideally formatted but it mostly gets the job done as
well as anything else I've seen for archive use.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Sasha Levin]

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.

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.


--
Thanks,
Sasha

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

[Daniel Vetter]

On Mon, Sep 10, 2018 at 4:53 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Sun, Sep 9, 2018 at 10:59 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>> - Assuming it gets accepted I think my LPC talk on "migrating to
>> gitlab" will raise some questions, and probably overflow into hallway
>> track or a BOF session.

First a bit more context: This is a different talk than the other
"stuff drm people are doing" talks I've done in the past: We haven't
done anything yet. We haven't even really started planning the
migration yet :-)

The idea here was that for once I don't do a talk when it's all done,
but way ahead of that when we're still figuring things out. The
underlying reason for the migration is that fd.o admins want to shut
down their home-grown collage of services and replace it with
something that's much easier to maintain, provides solid 2FA and
allows them to offload a lot of the admin work (handing out access
rights and stuff) to all the projects their hosting. Plus stop the
shell access services, if that's ever possible.

So right now this is only about moving the git server from one place
to the other. And we haven't even done the full plan for that
migration (it's a pile of repos and stuff). So really very early. But
now that we do have this modern thing, a lot of people are looking
into all the shiny features it offers, and trying to figure out
whether they're useful for us or not. And that's what I want to go
through in the talk - the title is a bit on the clickbait side :-)

> I've not used gitlab personally, but I *have* used github for a much
> smaller project.
>
> I have to say, the random and relaxed model is enjoyable. I can see
> how somebody coming from that, then finds the strict kernel rules (and
> _different_ rules for different parts) off-putting and confusing.
>
> At the same time, I have to say that people need to keep in mind that
> the kernel is *different*. We're not a small project with five
> developers that isn't all that critical. Some of our off-putting
> development models are there for a very very good reason. I think a
> lot of people who find the kernel unfriendly just don't appreciate
> that part.
>
> The kernel used to be pretty free-wheeling too. 20+ years ago.

What I definitely don't want is a free-wheeling thing a la your
standard github repo. There's also the issue that github massively
optimizes for small projects in their entire setup. I've done a blog
post about that a while ago and chatted with a bunch of githubbers,
they're really not interested in big-project workflows that much.

gitlab otoh is very interested in that, and they picked up some of the
concepts around how we use topic branches and pull requests in the
kernel. It's by far not all implemented yet, but a lot more promising
than anything else I've looked at. And we can always just keep using
our existing tooling ofc.

Aside from this there's a bunch of other reasons fd.o admins picked
gitlab (against other contenders they checked out), but this is one of
the big ones. At least from the kernel's pov. For anyone bored enough,
here's the full details of the why from fd.o admins:

https://www.fooishbar.org/blog/gitlab-fdo-introduction/

> And I still hate how github ends up making it really really easy to
> make horribly bad commit messages, and it encourages a "just rebase on
> top of the integration branch" model, and I do not believe that it
> would ever work for the kernel at large. Too much room for chaos.
>
> BUT.
>
> I do think it's still instructive to look at how those "fun small
> projects" work. Having the whole web interface and a more relaxed
> setup is a good thing. And it's probably *better* than the strict
> rules when you don't really need those strict rules.
>
> So I do believe that it could work for a subsystem. Because "too much
> room for chaos" ends up being nice when you don't want to worry about
> the proper channels etc.
>
> For example, we've had the "trivial tree", which tends to be a really
> thankless project, that might well be managed way more easily by just
> having a random tree that lots of people can commit to, and we could
> even encourage the github (gitlab?) model of random non-kernel people
> just sending their random trees to it, and have then the group of
> committers be able to merge the changes (and at least on github, the
> default merge is just a fast-forward, so it actually acts more like a
> patch queue than a git tree).

Yeah, the trivial/"fun first contributions" process is a lot more
polished on many of these projects, and there's a bunch such things we
kinda want to look into longer-term. And this really is all long-term,
because just the initial git server migration most likely won't even
start until next year.

A much bigger thing for us is CI integration. patchwork + patch bombs
+ lots of tears and gin do kinda work, but it's super painful and a
real chaos no one has any overview over. gitlab has really neat
integrated CI for anything that you can run on containers/virtual
machines (already played with it, pretty dope, and I have 0 clue about
this docker/container stuff). And also seems to have good support to
tie all kinds of exterrnal CI validation into pull requests (well
gitlab calls them merge requests, it's the same).

One thing we're at least planning to experiment with is to take the
driver pull requests from drm, auto-convert them into gitlab merge
requests (or just ask people to directly do that), and then let to
bots go wild. Would give us a nice single point where you can check
all the information from all the different checks and vendor CI and
everything. Not even that much with the goal to do the merge using the
web ui, just to integrate all the testing and validation in one spot.

> And the reason I mention the trivial tree is not because the trivial
> tree itself is all that interesting or because I'd like to belittle
> that model ("that will only work for trivial unimportant stuff"), but
> because it might be a good area to experiment in, and a way to get
> people used to the flow.
>
> Because if somebody is willing to every once in a while look at
> trivial tree pull requests and merge them to the trivial tree, maybe
> that person will start using the same flow for their "real" work.
>
> And I do think that "patches by email" doesn't scale. I've been there,
> done that, and I got the T-shirt.
>
> I used tools that some people absolutely hated to get out of that
> rat-hole. When that failed, I had to write my own.
>
> So I very much do think that email doesn't really work at scale.
>
> But I know the kernel people who still do real development (as opposed
> to me) work that way.
>
> So let me suggest a topic for the maintainer summit:
>
>   "Live without email - possible?"
>
> just to get that ball rolling

I'd say "nope", even with the s/live/patches/. Definitely not for
anything spanning subsystems. Even within gitlabd the cross-tree
support is not (yet) there. And we definitely need to have a solid
gitlab/mailing list gateway, which is somewhere on the huge list of
things fd.o admins need to do. It exists, but SMTP is pain, and fd.o
is volunteer run, so all takes time. And then the gateway might be too
much garbage to be useful.

My goal at least with this is much more in figuring out new workflows,
and running a pile of experiments. As mentioned, we don't yet even
have a plan for all this, the goal here is to spark some discussions
and figure out whether maybe others want to come along for the ride.

Whether anything of this will make it into the production drm
processes, no idea. "maybe" is the best answer at this time I think.

And yes I hope that by LPC I'll have a bit more solid understanding of
how this gitlab thing works and what we could try out, so this isn't
as much high-level gossipping as it is right now :-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Sasha Levin]

On Mon, Sep 10, 2018 at 11:47:38AM -0400, Konstantin Ryabitsev wrote:
>On Mon, Sep 10, 2018 at 03:38:07PM +0000, Sasha Levin via Ksummit-discuss wrote:
>>Yes, some maintainers started adding links to lkml archives, but those
>>are very inconsistent and often just point to the patch submission
>>rather than relevant discussions.
>>
>>I'm not sure what's a good way to solve this, but I'd really like to
>>stop losing this valuable information as a result of the current
>>process.
>
>This is partly the goal behind cregit:
>
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcregit.linuxsources.org%2F&data=02%7C01%7CAlexander.Levin%40microsoft.com%7Cabcc8f65199b4c5e4dc108d61734a674%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636721912238696228&sdata=ocQoQHzDCZuFwYxTIzDrg%2BNHKUHmZbLQElEcHK7Aaeo%3D&reserved=0
>
>The plan is that the next version of cregit will become an official 
>kernel.org resource some time mid-next year, and will aggregate as 
>much information about the kernel code as it can from various places, 
>including patchwork.

I thought cregit was more about identifying who wrote what line of code
rather than all the metadata around that line of code?


--
Thanks,
Sasha

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

[Konstantin Ryabitsev]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

On Mon, Sep 10, 2018 at 03:56:27PM +0000, Sasha Levin via Ksummit-discuss wrote:
>>The plan is that the next version of cregit will become an official
>>kernel.org resource some time mid-next year, and will aggregate as
>>much information about the kernel code as it can from various places,
>>including patchwork.
>
>I thought cregit was more about identifying who wrote what line of code
>rather than all the metadata around that line of code?

Yes, that's the primary goal, but the secondary goal is to provide as 
much information about the lifecycle of each change as possible. The way 
code metamorphoses from the initial submission to the final accepted 
commit is an important part of cregit's mission.

-K

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Daniel Vetter]

On Mon, Sep 10, 2018 at 5:47 PM, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> On Mon, Sep 10, 2018 at 03:38:07PM +0000, Sasha Levin via Ksummit-discuss
> wrote:
>>
>> Yes, some maintainers started adding links to lkml archives, but those
>> are very inconsistent and often just point to the patch submission
>> rather than relevant discussions.
>>
>> I'm not sure what's a good way to solve this, but I'd really like to
>> stop losing this valuable information as a result of the current
>> process.
>
>
> This is partly the goal behind cregit:
>
> https://cregit.linuxsources.org/
>
> The plan is that the next version of cregit will become an official
> kernel.org resource some time mid-next year, and will aggregate as much
> information about the kernel code as it can from various places, including
> patchwork.

Assuming we do indeed switch some parts of the drm process over to
gitlab (very big assumption here), whom would we need to chat with to
do that?

Atm what we're doing with patchwork is automatically add a Link: with
the https:// patchwork url for that patch. Which then has links to the
overall series, with CI results and discussions and all that. Plan for
gitlab is to do something similar, if we start using it for real for
anything. Would that be good enough?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[James Bottomley]

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.

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.

James

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

[Konstantin Ryabitsev]

[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]

On Mon, Sep 10, 2018 at 06:07:35PM +0200, Daniel Vetter wrote:
>Assuming we do indeed switch some parts of the drm process over to
>gitlab (very big assumption here), whom would we need to chat with to
>do that?

Hm... For the purposes of cregit or repository hosting?

>Atm what we're doing with patchwork is automatically add a Link: with
>the https:// patchwork url for that patch. Which then has links to the
>overall series, with CI results and discussions and all that. Plan for
>gitlab is to do something similar, if we start using it for real for
>anything. Would that be good enough?

That shouldn't be necessary in the near future. There is work under way 
for patchwork to accept message-id based URLs, so using the 
lkml.kernel.org/r/message-id URLs in commit messages should be enough 
for cregit to provide a link to the relevant patchwork thread. We will 
also probably end up integrating lore.kernel.org/patchwork with git in a 
way that would associate patches with final commit-ids and auto-archive 
them. It's not going to be 100% accurate for various reasons, but will 
at lest provide more hooks for projects like cregit to provide extra 
details about git commits.

-K

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Daniel Vetter]

On Mon, Sep 10, 2018 at 6:18 PM, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> On Mon, Sep 10, 2018 at 06:07:35PM +0200, Daniel Vetter wrote:
>>
>> Assuming we do indeed switch some parts of the drm process over to
>> gitlab (very big assumption here), whom would we need to chat with to
>> do that?
>
>
> Hm... For the purposes of cregit or repository hosting?

For cregit integration. Tbh I don't even know how the current mailing
lists hosted on freedesktop.org infrastructure are integrated into
cregit. But I assume they are somehow, since that's were all the drm
talk is happening. gitlab will also be hosted on fd.o infrastructure
for us.

>> Atm what we're doing with patchwork is automatically add a Link: with
>> the https:// patchwork url for that patch. Which then has links to the
>> overall series, with CI results and discussions and all that. Plan for
>> gitlab is to do something similar, if we start using it for real for
>> anything. Would that be good enough?
>
>
> That shouldn't be necessary in the near future. There is work under way for
> patchwork to accept message-id based URLs, so using the
> lkml.kernel.org/r/message-id URLs in commit messages should be enough for
> cregit to provide a link to the relevant patchwork thread. We will also
> probably end up integrating lore.kernel.org/patchwork with git in a way that
> would associate patches with final commit-ids and auto-archive them. It's
> not going to be 100% accurate for various reasons, but will at lest provide
> more hooks for projects like cregit to provide extra details about git
> commits.

There's at least 4 forks of patchwork :-/ The one we have on fd.o has
been doing this since ages. We added the Link: stuff so you can easily
go from e.g. git log to the patch discussion, without a detour through
google.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Sasha Levin]

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

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

[Daniel Vetter]

On Mon, Sep 10, 2018 at 4:53 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Sun, Sep 9, 2018 at 10:59 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>>
>> I think for pratical reasons (the linux kernel is huge) focusing on
>> subsystems is more useful, at least in the short term. Much easier to
>> experiment with new things in smaller groups.
>
> I think that realistically, it's never going to be anything *but*
> subsystem-specific, not just because the kernel is huge.
>
> There are simply often very different concerns.
>
> An individual filesystem can be a big project, and people work on
> filesystems for decades. They can get quite complex indeed. But at the
> same time, an individual filesystem just doesn't tend to *impact*
> other things. Sure, we may end up adding features to the VM or the VFS
> layer to make it possible for it to do some particular thing, and we
> may end up having lots of common code that a lot of filesystems end up
> sharing, but in a very real sense, it is its own _mostly_ independent
> thing, and what happens inside the community for that filesystem
> doesn't tend to much affect anybody else.
>
> Same goes for a lot of drivers. Yes, they have connections to the
> outside, but what happens in one driver seldom affects anything else.
>
> Equally importantly, filesystem changes can generally be tested with a
> fairly targeted test-suite. When you make changes to one filesystem,
> you need to test only _that_ filesystem.
>
> The same _tends_ to be true for drivers too, although there testing
> can be "interesting" because of the hardware dependency - a single
> driver often covers a few tens (to a few hundred) different hardware
> implementations. But the changes still don't tend to affect *other*
> devices.
>
> But things change once you start going up from individual filesystems
> or drivers to a common layer. Making changes to a common layer is
> simply _fundamentally_ way more painful. Sure, part of the pain is
> that now you have to convert all the filesystems or drivers that
> depended on that common layer to the new changes, but a large part is
> simply that now the changes affect many different kinds of filesystems
> or drivers, and testing is *much* harder.
>
> You obviously see that with the whole drm layer (example: atomic
> modesetting). That's still a fairly small set of different drivers
> (small in number, not in code-size), and it already causes issues.
>
> At the other end of the spectrum, some of the most painful changes
> we've ever done have basically gone across *all* drivers, and caused
> untold bugs for the better part of a decade. I'm thinking of all the
> power management work we did back ten+ years ago.
>
> The VM people (and some other groups - the scheduler comes to mind)
> have had a different kind of issue entirely: not that the kernel has
> tons of "sub-drivers" that depend on them - although that obviously is
> true in a very real sense for any memory allocator etc - but simply
> that there are lots of different loads. In a filesystem or a driver,
> you can have a test-suite for correct behavior, but the behavior is
> largely the same. When it comes to VM or scheduler, the problem is
> that you have different loads, and performing well on one load does
> not mean at all that you do well on another.
>
> We had a few years when people were pushing scheduler rchanges without
> really appreciating that "your load isn't everybody elses load" issue.
>
> In contrast, in drivers and filesystems, things are usually more
> black-and-white wrt "does this work well".  Yes, yes, you have latency
> vs throughput issues etc, and you might have some scalability issues
> with per-cpu queues etc, but at the individual driver level, those
> kinds of concerns tend to not dominate. You want a stress-test setup
> for testing, but you don't need to worry too much about lots of crazy
> users.
>
> So different areas of the kernel just tend to have different concerns.
> You can allow people to work more freely on a driver that doesn't
> affect other things than on something that possibly screws over a lot
> of other developers.
>
> But if we find "models that work", maybe we can at least have
> processes that look a bit more like each other, even across
> subsystems.

Yeah, fully agreed, I think this is the kernel community's real
strength. It's one overall project on one hand, everyone pushes into
the exact same directory structure with one overall git history (in
the end at least, once something has made it to upstream). But zooming
in, it's very much just a loosely-coupled pile of associated projects;
each can optimize for their local constraints. HW testing and hacking
is indeed totally different from core work that affects everyone.

This also ties somewhat into the gitlab discussions: github doesn't
support this model, and isn't interested in fixing this. gitlab at
least has made some foundational work in their internals already (how
they handle the fork tree mostly, since that's the big one), and
they're interested in exploring how to support something like the
kernel's git tree flow at a higher level, in their web UI. I wrote
this entire thing up semi-coherently a while ago on my blog:
https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html

>> That's why I added
>> "subsystem governance". If there's enough interest on specific topics
>> we could schedule some BOF sessions, otherwise just hallway track with
>> interested parties.
>
> So what I think would be good is to not talk about some nebulous
> "community management", but talk about very specific and very real
> examples of actual technical problems.
>
> Partly exactly *because* I think the areas are not all the same, and
> the friction points are likely *between* these areas that may even
> have really good reasons to act differently, and mostly they are
> independent and have little interaction, but then when interaction
> happens, things don't work well.
>
> IOW, if we have the top-level maintainers around, we should have a
> gripe-fest where people come in and say "Hey, you, look, this
> *particular* problem has been around for a year now, there's a patch,
> why did it not get applied"?
>
> Don't make it about some nebulous "we could do better as a community".
>
> Instead, make it about some very *particular* issue where the process
> failed. Make it something concrete and practical.
>
>    "Look, this patch took a year to get in, for no good reason".
>
> Or
>
>   "Look, here's a feature that I *tried* to get accepted for a month,
> nothing happened, so I gave up".
>
> And if we have a few of those, maybe we can see a pattern, and perhaps
> even come up with some suggestion on how to fix some flow.
>
> And if people can't come up with particular examples, I don't think
> it's much worth discussing. At that point it's not productive.
>
> We need to name names, show patches, and talk about exactly where and
> how something broke down.

Yeah, it's much easier to discuss concrete stuff than high-level
abstract concepts. That's why I listed a bunch of specific things I'm
interested in. Mostly that's stuff I'm actively working on in areas
that arent working perfectly in drm. Or at least where things are
painful enough that we're grasping for anything that looks like it
might help.

And if no one cares for a specific topic, then we'll best just throw
it off the agenda instead of having a generic discussion that goes
nowhere.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Olof Johansson]

Hi,

On Mon, Sep 10, 2018 at 8:38 AM, Sasha Levin via Ksummit-discuss
<ksummit-discuss@lists.linuxfoundation.org> 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 great for ephemeral discussions of the current patch set, but
several of your points sort of indicate that it _isn't_ a good
discussion forum either.


>
> 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.
>
> Yes, some maintainers started adding links to lkml archives, but those
> are very inconsistent and often just point to the patch submission
> rather than relevant discussions.

It makes it a pain for me as well. The way we deal with code coming in
is that very often we don't see patches until they're sent to us in a
pull request. I look through them (i.e. a light review), and if I find
something, I'll go look for the patch on the mailing list and reply on
it.

If that patch is up at higher versions, there's no way for me to
easily find all previous discussion about it, which sometimes means I
will have conflicting feedback from some other maintainer. If it's
minor feedback that isn't a really big deal, it's better to see the
other side early on and just not introduce the noise and conflicting
requests to the contributor.

Having worked in several corporate setups, none of them are ideal, but
some of them do fill the gaps we have while they introduce others.
There is definitely lots of opportunity for better tooling all around.

> I'm not sure what's a good way to solve this, but I'd really like to
> stop losing this valuable information as a result of the current
> process.

I think any tool we choose can/should/will have an email backed such
that email archives could always be a canonical historical fallback.
Especially for services where URLs to pull requests might not be
around 5 years from now, etc. We've already gone through a cycle of
this for email archives recently.



-Olof

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

[Olof Johansson]

On Mon, Sep 10, 2018 at 8:31 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> I need to split this up, otherwise I'll get lost on the different
> sub-topics. I'll start with the easy ones.

Agreed, I probably won't be able to keep up with this whole thread
this week due to $job, but a few stray comments:

> On Mon, Sep 10, 2018 at 4:53 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>> Specific topics I'm interested in:
>>> - New experiments in group maintainership, and sharing lessons learned
>>> in general.
>>
>> I think that's good. But again, partly because these kinds of subjects
>> tend to devolve into too much of a generic overview, may I suggest
>> again trying to make things very concrete.
>>
>> For example, talk about the actual tools you use. Make it tangible. A
>> couple of years ago the ARM people talked about the way they split
>> their time to avoid stepping on each other (both in timezones, but
>> also in how they pass the baton around in general, in addition to
>> using branches).
>>
>> And yes, a lot of it probably ends up being "we didn't actually make
>> this official or write it up, but we worked enough together that we
>> ended up doing XYZ". That's fine. That's how real flows develop. With
>> discussion of what the problems were, and what this solved.
>>
>> In other words, make it down to earth. Not the "visionary keynote",
>> but the "this is the everyday flow".
>
> Yup, fully agreed. We don't need another overview over group
> maintainer ship. Also I don't think an update from arm-soc/tip or drm
> is interesting either. I think only if there's a new group/subsystem
> trying this out, with all the nitty-gritty details of "this totally
> blew up in our faces" and "this worked shockingly well" and "here we
> need to improve still, we're not happy" is what I'm looking for.
> Without those details there's nothing really to learn, beyond just
> rehashing one of the old discussions. I guess I should have put more
> emphasis on _new_ experiments :-)

I'm not interested in standing up and talking about how Arnd and I
handle things right now, but what I would be really interested in
talking about is where we still have chafing, where things don't
actually work great (Linus might be happy, but we're definitely in a
spot where we could simplify life for _us_ quite a bit).

I'm super excited to hear a bit about the _actual_ plans of gitlab
move. As mentioned, not a visionary keynote, but others also talking
about what they're looking at to fix their current pain points.


For us on arm-soc, we've gotten a bit better at reducing our overhead,
but the bulk of material coming in these days tends to be a no-op from
us (just figure out that it merges, that we have handshakes with any
external dependencies or shared branches, and pick it up). We have
some submaintainers who need more work, and we pay closer attention to
and have more feedback, but reducing the overhead for some of the
others by letting them cross-review and merge themselves would be
useful.

I'm also starting to get mildly annoyed by the single-patch pull
requests that we sometimes get. In some ways, applying patches are
easier, not harder. For those, the model where "cherry pick when
merging" in common code review tools would work really well.

> And if nothing changed, no new groups I think think we should table
> this right away.

I really want to talk about this, but if there isn't enough interest
from others, we could just do it in a hallway. But I think the topic
is on point for the maintainer summit.


-Olof

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

[Konstantin Ryabitsev]

[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]

On Mon, Sep 10, 2018 at 06:23:52PM +0200, Daniel Vetter wrote:
>> Hm... For the purposes of cregit or repository hosting?
>
>For cregit integration. Tbh I don't even know how the current mailing
>lists hosted on freedesktop.org infrastructure are integrated into
>cregit. But I assume they are somehow, since that's were all the drm
>talk is happening. gitlab will also be hosted on fd.o infrastructure
>for us.

Cregit only considers LKML and the mainline tree -- at least right now.  
So, as long as all patches and discussions are cc'd to LKML, they will 
be within cregit's reach. I'm not sure there are any plans to look at 
any other lists at this point (I'm only very tangentially involved in 
cregit's development). Kate Stewart would be the right person to ask 
this.

>> That shouldn't be necessary in the near future. There is work under 
>> way for
>> patchwork to accept message-id based URLs, so using the
>> lkml.kernel.org/r/message-id URLs in commit messages should be enough for
>> cregit to provide a link to the relevant patchwork thread. We will also
>> probably end up integrating lore.kernel.org/patchwork with git in a way that
>> would associate patches with final commit-ids and auto-archive them. It's
>> not going to be 100% accurate for various reasons, but will at lest provide
>> more hooks for projects like cregit to provide extra details about git
>> commits.
>
>There's at least 4 forks of patchwork :-/ The one we have on fd.o has
>been doing this since ages. We added the Link: stuff so you can easily
>go from e.g. git log to the patch discussion, without a detour through
>google.

It's too bad that this hasn't percolated up to ozlabs, because I believe 
numeric-ID based patch links are actually harmful because they are 100% 
lossy.

-K

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Daniel Vetter]

On Mon, Sep 10, 2018 at 6:41 PM, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> On Mon, Sep 10, 2018 at 06:23:52PM +0200, Daniel Vetter wrote:
>>>
>>> Hm... For the purposes of cregit or repository hosting?
>>
>>
>> For cregit integration. Tbh I don't even know how the current mailing
>> lists hosted on freedesktop.org infrastructure are integrated into
>> cregit. But I assume they are somehow, since that's were all the drm
>> talk is happening. gitlab will also be hosted on fd.o infrastructure
>> for us.
>
>
> Cregit only considers LKML and the mainline tree -- at least right now.  So,
> as long as all patches and discussions are cc'd to LKML, they will be within
> cregit's reach. I'm not sure there are any plans to look at any other lists
> at this point (I'm only very tangentially involved in cregit's development).
> Kate Stewart would be the right person to ask this.

Hm yeah that's a bit a bummer. We don't tend to cc: lkml on anything
we do. And I think that holds true for many subsystems (but honestly I
didn't check). Can you pls pull Kate into this thread, so I have their
contact information?

>>> That shouldn't be necessary in the near future. There is work under way
>>> for
>>> patchwork to accept message-id based URLs, so using the
>>> lkml.kernel.org/r/message-id URLs in commit messages should be enough for
>>> cregit to provide a link to the relevant patchwork thread. We will also
>>> probably end up integrating lore.kernel.org/patchwork with git in a way
>>> that
>>> would associate patches with final commit-ids and auto-archive them. It's
>>> not going to be 100% accurate for various reasons, but will at lest
>>> provide
>>> more hooks for projects like cregit to provide extra details about git
>>> commits.
>>
>>
>> There's at least 4 forks of patchwork :-/ The one we have on fd.o has
>> been doing this since ages. We added the Link: stuff so you can easily
>> go from e.g. git log to the patch discussion, without a detour through
>> google.
>
>
> It's too bad that this hasn't percolated up to ozlabs, because I believe
> numeric-ID based patch links are actually harmful because they are 100%
> lossy.

We tried to upstream - it died in a bikeshed of competing approaches
and someone else won (but then took years longer to get their approach
merged). Anyway, from our experiences patchwork, even with the things
you've listed implemented, is miles away from what we actually need.
It's definitely better than old patchwork though.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[James Bottomley]

On Mon, 2018-09-10 at 16:24 +0000, Sasha Levin via Ksummit-discuss
wrote:
> 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
[...]
> > > 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?

It's a whitespace change ... I thought stable policy was to reject
those without further consideration.

However, given the #L1TF qualifier, I think it's a precursor patch for
another L1TF change, isn't it?

What's wrong with if in doubt, ask the maintainer.

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

Why?  If a Maintainer didn't tag it and no-one else submitted it, why
go looking for trouble?  I really strongly think stable should be a
push process not a random pull one.

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

So simply asking will get you that information.

James

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

[Daniel Vetter]

On Mon, Sep 10, 2018 at 6:39 PM, Olof Johansson <olof@lixom.net> wrote:
> On Mon, Sep 10, 2018 at 8:31 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>> I need to split this up, otherwise I'll get lost on the different
>> sub-topics. I'll start with the easy ones.
>
> Agreed, I probably won't be able to keep up with this whole thread
> this week due to $job, but a few stray comments:
>
>> On Mon, Sep 10, 2018 at 4:53 PM, Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:
>>>> Specific topics I'm interested in:
>>>> - New experiments in group maintainership, and sharing lessons learned
>>>> in general.
>>>
>>> I think that's good. But again, partly because these kinds of subjects
>>> tend to devolve into too much of a generic overview, may I suggest
>>> again trying to make things very concrete.
>>>
>>> For example, talk about the actual tools you use. Make it tangible. A
>>> couple of years ago the ARM people talked about the way they split
>>> their time to avoid stepping on each other (both in timezones, but
>>> also in how they pass the baton around in general, in addition to
>>> using branches).
>>>
>>> And yes, a lot of it probably ends up being "we didn't actually make
>>> this official or write it up, but we worked enough together that we
>>> ended up doing XYZ". That's fine. That's how real flows develop. With
>>> discussion of what the problems were, and what this solved.
>>>
>>> In other words, make it down to earth. Not the "visionary keynote",
>>> but the "this is the everyday flow".
>>
>> Yup, fully agreed. We don't need another overview over group
>> maintainer ship. Also I don't think an update from arm-soc/tip or drm
>> is interesting either. I think only if there's a new group/subsystem
>> trying this out, with all the nitty-gritty details of "this totally
>> blew up in our faces" and "this worked shockingly well" and "here we
>> need to improve still, we're not happy" is what I'm looking for.
>> Without those details there's nothing really to learn, beyond just
>> rehashing one of the old discussions. I guess I should have put more
>> emphasis on _new_ experiments :-)
>
> I'm not interested in standing up and talking about how Arnd and I
> handle things right now, but what I would be really interested in
> talking about is where we still have chafing, where things don't
> actually work great (Linus might be happy, but we're definitely in a
> spot where we could simplify life for _us_ quite a bit).
>
> I'm super excited to hear a bit about the _actual_ plans of gitlab
> move. As mentioned, not a visionary keynote, but others also talking
> about what they're looking at to fix their current pain points.

It's the topic in the other thread, so hooray for chaos, but don't
worry: I plan to make the talk as concrete as possible for a "we're
planning this" talk. Rought structure I have in mind:
- short overview of why fd.o admins want to switch and why, with a bit
of history on how drm is influenced from both kernel and userspace
alike.
- going through our current pain points, and how we think some gitlab
concepts could help. I hope that a bunch of things will be concrete
already here, using some of our userspace repos like the test-suite as
guinea pigs.
- the epic long lists of issues and infrastructure we're seeing
already in case we want to actually follow through on any of this.
Plus a request for "what did we miss?".

It's definitely not going to be your inspirational keynote thing about
how awesome community management is, ks is the wrong place for that
:-)

Cheers, Daniel

> For us on arm-soc, we've gotten a bit better at reducing our overhead,
> but the bulk of material coming in these days tends to be a no-op from
> us (just figure out that it merges, that we have handshakes with any
> external dependencies or shared branches, and pick it up). We have
> some submaintainers who need more work, and we pay closer attention to
> and have more feedback, but reducing the overhead for some of the
> others by letting them cross-review and merge themselves would be
> useful.
>
> I'm also starting to get mildly annoyed by the single-patch pull
> requests that we sometimes get. In some ways, applying patches are
> easier, not harder. For those, the model where "cherry pick when
> merging" in common code review tools would work really well.
>
>> And if nothing changed, no new groups I think think we should table
>> this right away.
>
> I really want to talk about this, but if there isn't enough interest
> from others, we could just do it in a hallway. But I think the topic
> is on point for the maintainer summit.
>
>
> -Olof



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Laurent Pinchart]

Hi Daniel,

On Monday, 10 September 2018 19:07:35 EEST Daniel Vetter wrote:
> On Mon, Sep 10, 2018 at 5:47 PM, Konstantin Ryabitsev wrote:
> > On Mon, Sep 10, 2018 at 03:38:07PM +0000, Sasha Levin wrote:
> >> Yes, some maintainers started adding links to lkml archives, but those
> >> are very inconsistent and often just point to the patch submission
> >> rather than relevant discussions.
> >> 
> >> I'm not sure what's a good way to solve this, but I'd really like to
> >> stop losing this valuable information as a result of the current
> >> process.
> > 
> > This is partly the goal behind cregit:
> > 
> > https://cregit.linuxsources.org/
> > 
> > The plan is that the next version of cregit will become an official
> > kernel.org resource some time mid-next year, and will aggregate as much
> > information about the kernel code as it can from various places, including
> > patchwork.
> 
> Assuming we do indeed switch some parts of the drm process over to
> gitlab (very big assumption here), whom would we need to chat with to
> do that?

Could you elaborate on what that means exactly ? For most subsystems the 
development process encompasses a large number of tasks, so switching to 
gitlab doesn't mean much without knowing exactly how the new process would 
look like. Which part(s) of the development process would be affected, and how 
? And as an added bonus, it would be helpful if you could also describe why 
you think they don't work today and would be better handled differently.

> Atm what we're doing with patchwork is automatically add a Link: with
> the https:// patchwork url for that patch. Which then has links to the
> overall series, with CI results and discussions and all that. Plan for
> gitlab is to do something similar, if we start using it for real for
> anything. Would that be good enough?

-- 
Regards,

Laurent Pinchart

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

[Laurent Pinchart]

Hi,

On Monday, 10 September 2018 19:33:09 EEST Olof Johansson wrote:
> On Mon, Sep 10, 2018 at 8:38 AM, Sasha Levin 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 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 great for ephemeral discussions of the current patch set, but
> several of your points sort of indicate that it _isn't_ a good
> discussion forum either.
> 
> > 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.
> > 
> > Yes, some maintainers started adding links to lkml archives, but those
> > are very inconsistent and often just point to the patch submission
> > rather than relevant discussions.
> 
> It makes it a pain for me as well. The way we deal with code coming in
> is that very often we don't see patches until they're sent to us in a
> pull request. I look through them (i.e. a light review), and if I find
> something, I'll go look for the patch on the mailing list and reply on
> it.
> 
> If that patch is up at higher versions, there's no way for me to
> easily find all previous discussion about it, which sometimes means I
> will have conflicting feedback from some other maintainer. If it's
> minor feedback that isn't a really big deal, it's better to see the
> other side early on and just not introduce the noise and conflicting
> requests to the contributor.
> 
> Having worked in several corporate setups, none of them are ideal, but
> some of them do fill the gaps we have while they introduce others.
> There is definitely lots of opportunity for better tooling all around.

One of the issues here is that patch series don't have fixed boundaries over 
their lifetime, the same way patches don't. A patch can evolve in scope from 
version to version, and similarly so can a patch series. It's not uncommon for 
patches to be dropped or added and for series to be split or merged. I've in 
the past incorporated part of an RFC patch series in the v1 of a series with a 
larger scope (after discussing it with the original developer of course).

While in many cases we can version both patch and series, it's not uncommon 
for subjects to be changed and scopes to be extended or shrunk. I would 
distrust a system claiming it can automatically track all patch series over 
their lifetime, always keeping history linked together.

That being said, if we could make that tracking information easily accessible 
in the common case where it actually exists, that would already be a good step 
forward in tooling improvement.

> > I'm not sure what's a good way to solve this, but I'd really like to
> > stop losing this valuable information as a result of the current
> > process.
> 
> I think any tool we choose can/should/will have an email backed such
> that email archives could always be a canonical historical fallback.
> Especially for services where URLs to pull requests might not be
> around 5 years from now, etc. We've already gone through a cycle of
> this for email archives recently.

-- 
Regards,

Laurent Pinchart

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

[Laurent Pinchart]

On Monday, 10 September 2018 18:13:05 EEST Jiri Kosina wrote:
> On Mon, 10 Sep 2018, James Bottomley wrote:
> >    1. How do reviews happen?  Non email projects tend to have only one
> >       review mechanism (gerrit, github, gitlab, etc.) and stick to it.  Do
> >       we want to pick a technology or allow multiple?  I don't think this
> >       is kernel wide, it could be a sybsystem choice.
> 
> Yeah, but OTOH even now I've heard a lot of feedback about the irregular
> contributors / newcomers being confused by different subsystems having
> different processess and requirements; and those are basically just rather
> "minor" things currently (bugzilla usage, patchwork usage, subscriber-only
> mailinglists, etc), but it's still enough to confuse the hell out of
> people.

That's also one of my concerns. The differences between subsystems that all 
use an email-based review process can already be confusing, or just annoying 
to handle, especially when specific tools are mandated (the DRM dim tool or 
the ARM patch system come to mind). I dread to think about how painful it 
would be if one subsystem adopted gitlab, another one gerrit, ... That would 
also make changes that cross subsystem boundaries a nightmare to handle. Let's 
not forget that many developers are not confined within a single subsystem.

On the other hand, I don't really see how switching the whole kernel to gitlab 
(or another system) could happen without frustrating a very large number of 
developers. We all know how conservative the community tend to be.

One possible course of action would be to make the new tools optional and keep 
email as a common denominator. That way the old dinosaurs who won't adopt any 
tool introducing even the slightest disturbance in their work flow (it's not 
pleasant to realize that I may well be one of them) will still be able to work 
undisturbed, and all the other developers would be able to enjoy the myriad of 
amazing features offered by their tooling of choice. This would however put an 
extra burden on the new tools that would need to have first-class email 
compatibility. I don't know whether that would be feasible.

-- 
Regards,

Laurent Pinchart

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

[Laurent Pinchart]

On Monday, 10 September 2018 18:56:18 EEST Daniel Vetter wrote:
> On Mon, Sep 10, 2018 at 4:53 PM, Linus Torvalds wrote:
> > On Sun, Sep 9, 2018 at 10:59 PM Daniel Vetter wrote:
> >> - Assuming it gets accepted I think my LPC talk on "migrating to
> >> gitlab" will raise some questions, and probably overflow into hallway
> >> track or a BOF session.
> 
> First a bit more context: This is a different talk than the other
> "stuff drm people are doing" talks I've done in the past: We haven't
> done anything yet. We haven't even really started planning the
> migration yet :-)
> 
> The idea here was that for once I don't do a talk when it's all done,
> but way ahead of that when we're still figuring things out. The
> underlying reason for the migration is that fd.o admins want to shut
> down their home-grown collage of services and replace it with
> something that's much easier to maintain, provides solid 2FA and
> allows them to offload a lot of the admin work (handing out access
> rights and stuff) to all the projects their hosting. Plus stop the
> shell access services, if that's ever possible.
> 
> So right now this is only about moving the git server from one place
> to the other. And we haven't even done the full plan for that
> migration (it's a pile of repos and stuff). So really very early. But
> now that we do have this modern thing, a lot of people are looking
> into all the shiny features it offers, and trying to figure out
> whether they're useful for us or not. And that's what I want to go
> through in the talk - the title is a bit on the clickbait side :-)
> 
> > I've not used gitlab personally, but I *have* used github for a much
> > smaller project.
> > 
> > I have to say, the random and relaxed model is enjoyable. I can see
> > how somebody coming from that, then finds the strict kernel rules (and
> > _different_ rules for different parts) off-putting and confusing.
> > 
> > At the same time, I have to say that people need to keep in mind that
> > the kernel is *different*. We're not a small project with five
> > developers that isn't all that critical. Some of our off-putting
> > development models are there for a very very good reason. I think a
> > lot of people who find the kernel unfriendly just don't appreciate
> > that part.
> > 
> > The kernel used to be pretty free-wheeling too. 20+ years ago.
> 
> What I definitely don't want is a free-wheeling thing a la your
> standard github repo. There's also the issue that github massively
> optimizes for small projects in their entire setup. I've done a blog
> post about that a while ago and chatted with a bunch of githubbers,
> they're really not interested in big-project workflows that much.
> 
> gitlab otoh is very interested in that, and they picked up some of the
> concepts around how we use topic branches and pull requests in the
> kernel. It's by far not all implemented yet, but a lot more promising
> than anything else I've looked at. And we can always just keep using
> our existing tooling ofc.
> 
> Aside from this there's a bunch of other reasons fd.o admins picked
> gitlab (against other contenders they checked out), but this is one of
> the big ones. At least from the kernel's pov. For anyone bored enough,
> here's the full details of the why from fd.o admins:
> 
> https://www.fooishbar.org/blog/gitlab-fdo-introduction/
> 
> > And I still hate how github ends up making it really really easy to
> > make horribly bad commit messages, and it encourages a "just rebase on
> > top of the integration branch" model, and I do not believe that it
> > would ever work for the kernel at large. Too much room for chaos.
> > 
> > BUT.
> > 
> > I do think it's still instructive to look at how those "fun small
> > projects" work. Having the whole web interface and a more relaxed
> > setup is a good thing. And it's probably *better* than the strict
> > rules when you don't really need those strict rules.
> > 
> > So I do believe that it could work for a subsystem. Because "too much
> > room for chaos" ends up being nice when you don't want to worry about
> > the proper channels etc.
> > 
> > For example, we've had the "trivial tree", which tends to be a really
> > thankless project, that might well be managed way more easily by just
> > having a random tree that lots of people can commit to, and we could
> > even encourage the github (gitlab?) model of random non-kernel people
> > just sending their random trees to it, and have then the group of
> > committers be able to merge the changes (and at least on github, the
> > default merge is just a fast-forward, so it actually acts more like a
> > patch queue than a git tree).
> 
> Yeah, the trivial/"fun first contributions" process is a lot more
> polished on many of these projects, and there's a bunch such things we
> kinda want to look into longer-term. And this really is all long-term,
> because just the initial git server migration most likely won't even
> start until next year.
> 
> A much bigger thing for us is CI integration. patchwork + patch bombs
> + lots of tears and gin do kinda work, but it's super painful and a
> real chaos no one has any overview over. gitlab has really neat
> integrated CI for anything that you can run on containers/virtual
> machines (already played with it, pretty dope, and I have 0 clue about
> this docker/container stuff). And also seems to have good support to
> tie all kinds of exterrnal CI validation into pull requests (well
> gitlab calls them merge requests, it's the same).
> 
> One thing we're at least planning to experiment with is to take the
> driver pull requests from drm, auto-convert them into gitlab merge
> requests (or just ask people to directly do that), and then let to
> bots go wild. Would give us a nice single point where you can check
> all the information from all the different checks and vendor CI and
> everything. Not even that much with the goal to do the merge using the
> web ui, just to integrate all the testing and validation in one spot.
> 
> > And the reason I mention the trivial tree is not because the trivial
> > tree itself is all that interesting or because I'd like to belittle
> > that model ("that will only work for trivial unimportant stuff"), but
> > because it might be a good area to experiment in, and a way to get
> > people used to the flow.
> > 
> > Because if somebody is willing to every once in a while look at
> > trivial tree pull requests and merge them to the trivial tree, maybe
> > that person will start using the same flow for their "real" work.
> > 
> > And I do think that "patches by email" doesn't scale. I've been there,
> > done that, and I got the T-shirt.
> > 
> > I used tools that some people absolutely hated to get out of that
> > rat-hole. When that failed, I had to write my own.
> > 
> > So I very much do think that email doesn't really work at scale.
> > 
> > But I know the kernel people who still do real development (as opposed
> > to me) work that way.
> > 
> > So let me suggest a topic for the maintainer summit:
> >   "Live without email - possible?"
> > 
> > just to get that ball rolling
> 
> I'd say "nope", even with the s/live/patches/. Definitely not for
> anything spanning subsystems. Even within gitlabd the cross-tree
> support is not (yet) there. And we definitely need to have a solid
> gitlab/mailing list gateway, which is somewhere on the huge list of
> things fd.o admins need to do. It exists, but SMTP is pain, and fd.o
> is volunteer run, so all takes time. And then the gateway might be too
> much garbage to be useful.

I believe we need a common communication system that is supported by all 
subsystems. Today that system is email.

If we don't want to challenge that, we'll need first-class compatibility 
between whatever new tool we introduce and email, in both direction. All 
discussions, including patch review, happening through other means (web UI for 
instance) will need to be pushed to emails, and email replies will need to be 
integrated back into the system, in such a way that will not completely mess 
up the formatting and communication flow. It has to be transparent enough.

If we want to challenge that, we'll have to agree about another communication 
system for the whole kernel. While I don't think that's realistic, I'm not 
opposed to discussing it. However, I expect many developers to come up with 
lists of requirements, and the result of merging all those requirements 
together to be exactly email and nothing else :-)

On my side, there are three very important features that a communication 
system should have:

- It should be push-based. I don't want to have to log in and pull information 
from web UIs.

- It should be customizable, offering an easy way to script review, and patch 
and pull request handling.

- It should offer an offline mode. Lots of us travel a lot or generally have 
to work without an internet connection more often than we would like, so any 
solution that requires being online won't work.

Emails provide all that, there may be good options I just fail to think about 
right now.

> My goal at least with this is much more in figuring out new workflows,
> and running a pile of experiments. As mentioned, we don't yet even
> have a plan for all this, the goal here is to spark some discussions
> and figure out whether maybe others want to come along for the ride.

I recently had to deal with a new bugs and tasks management tool that was 
developed in-house by a customer of mine. The tool was presented to us in its 
first RFC version (and in source code form, which is very nice), with very few 
implemented features, and without telling us what process it was supposed to 
support. When I inquired I got told that the process hasn't been taken into 
consideration to develop the tool, and that it would just come into existence 
as a result of the tool. Needless to say, it was hard for me to review the 
code, without knowing what it was supposed to do.

I don't claim we're going to that extreme, but I believe it would be useful to 
detail the problems we have in order to find solutions, instead of proposing 
solutions and then trying to retrofit them to problems.

> Whether anything of this will make it into the production drm
> processes, no idea. "maybe" is the best answer at this time I think.
> 
> And yes I hope that by LPC I'll have a bit more solid understanding of
> how this gitlab thing works and what we could try out, so this isn't
> as much high-level gossipping as it is right now :-)

-- 
Regards,

Laurent Pinchart

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

[Daniel Vetter]

On Mon, Sep 10, 2018 at 9:48 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Daniel,
>
> On Monday, 10 September 2018 19:07:35 EEST Daniel Vetter wrote:
>> On Mon, Sep 10, 2018 at 5:47 PM, Konstantin Ryabitsev wrote:
>> > On Mon, Sep 10, 2018 at 03:38:07PM +0000, Sasha Levin wrote:
>> >> Yes, some maintainers started adding links to lkml archives, but those
>> >> are very inconsistent and often just point to the patch submission
>> >> rather than relevant discussions.
>> >>
>> >> I'm not sure what's a good way to solve this, but I'd really like to
>> >> stop losing this valuable information as a result of the current
>> >> process.
>> >
>> > This is partly the goal behind cregit:
>> >
>> > https://cregit.linuxsources.org/
>> >
>> > The plan is that the next version of cregit will become an official
>> > kernel.org resource some time mid-next year, and will aggregate as much
>> > information about the kernel code as it can from various places, including
>> > patchwork.
>>
>> Assuming we do indeed switch some parts of the drm process over to
>> gitlab (very big assumption here), whom would we need to chat with to
>> do that?
>
> Could you elaborate on what that means exactly ? For most subsystems the
> development process encompasses a large number of tasks, so switching to
> gitlab doesn't mean much without knowing exactly how the new process would
> look like. Which part(s) of the development process would be affected, and how
> ? And as an added bonus, it would be helpful if you could also describe why
> you think they don't work today and would be better handled differently.

Let's move all the "how to gitab, or can we live without email?"
discussions in the other part of this thread. This here was just a
quick question about cregit (and I already regret that I mentioned
gitlab here, it seems to somewhat distract).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Daniel Vetter]

On Mon, Sep 10, 2018 at 10:32 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Monday, 10 September 2018 18:56:18 EEST Daniel Vetter wrote:
>> On Mon, Sep 10, 2018 at 4:53 PM, Linus Torvalds wrote:
>> > On Sun, Sep 9, 2018 at 10:59 PM Daniel Vetter wrote:
>> >> - Assuming it gets accepted I think my LPC talk on "migrating to
>> >> gitlab" will raise some questions, and probably overflow into hallway
>> >> track or a BOF session.
>>
>> First a bit more context: This is a different talk than the other
>> "stuff drm people are doing" talks I've done in the past: We haven't
>> done anything yet. We haven't even really started planning the
>> migration yet :-)
>>
>> The idea here was that for once I don't do a talk when it's all done,
>> but way ahead of that when we're still figuring things out. The
>> underlying reason for the migration is that fd.o admins want to shut
>> down their home-grown collage of services and replace it with
>> something that's much easier to maintain, provides solid 2FA and
>> allows them to offload a lot of the admin work (handing out access
>> rights and stuff) to all the projects their hosting. Plus stop the
>> shell access services, if that's ever possible.
>>
>> So right now this is only about moving the git server from one place
>> to the other. And we haven't even done the full plan for that
>> migration (it's a pile of repos and stuff). So really very early. But
>> now that we do have this modern thing, a lot of people are looking
>> into all the shiny features it offers, and trying to figure out
>> whether they're useful for us or not. And that's what I want to go
>> through in the talk - the title is a bit on the clickbait side :-)
>>
>> > I've not used gitlab personally, but I *have* used github for a much
>> > smaller project.
>> >
>> > I have to say, the random and relaxed model is enjoyable. I can see
>> > how somebody coming from that, then finds the strict kernel rules (and
>> > _different_ rules for different parts) off-putting and confusing.
>> >
>> > At the same time, I have to say that people need to keep in mind that
>> > the kernel is *different*. We're not a small project with five
>> > developers that isn't all that critical. Some of our off-putting
>> > development models are there for a very very good reason. I think a
>> > lot of people who find the kernel unfriendly just don't appreciate
>> > that part.
>> >
>> > The kernel used to be pretty free-wheeling too. 20+ years ago.
>>
>> What I definitely don't want is a free-wheeling thing a la your
>> standard github repo. There's also the issue that github massively
>> optimizes for small projects in their entire setup. I've done a blog
>> post about that a while ago and chatted with a bunch of githubbers,
>> they're really not interested in big-project workflows that much.
>>
>> gitlab otoh is very interested in that, and they picked up some of the
>> concepts around how we use topic branches and pull requests in the
>> kernel. It's by far not all implemented yet, but a lot more promising
>> than anything else I've looked at. And we can always just keep using
>> our existing tooling ofc.
>>
>> Aside from this there's a bunch of other reasons fd.o admins picked
>> gitlab (against other contenders they checked out), but this is one of
>> the big ones. At least from the kernel's pov. For anyone bored enough,
>> here's the full details of the why from fd.o admins:
>>
>> https://www.fooishbar.org/blog/gitlab-fdo-introduction/
>>
>> > And I still hate how github ends up making it really really easy to
>> > make horribly bad commit messages, and it encourages a "just rebase on
>> > top of the integration branch" model, and I do not believe that it
>> > would ever work for the kernel at large. Too much room for chaos.
>> >
>> > BUT.
>> >
>> > I do think it's still instructive to look at how those "fun small
>> > projects" work. Having the whole web interface and a more relaxed
>> > setup is a good thing. And it's probably *better* than the strict
>> > rules when you don't really need those strict rules.
>> >
>> > So I do believe that it could work for a subsystem. Because "too much
>> > room for chaos" ends up being nice when you don't want to worry about
>> > the proper channels etc.
>> >
>> > For example, we've had the "trivial tree", which tends to be a really
>> > thankless project, that might well be managed way more easily by just
>> > having a random tree that lots of people can commit to, and we could
>> > even encourage the github (gitlab?) model of random non-kernel people
>> > just sending their random trees to it, and have then the group of
>> > committers be able to merge the changes (and at least on github, the
>> > default merge is just a fast-forward, so it actually acts more like a
>> > patch queue than a git tree).
>>
>> Yeah, the trivial/"fun first contributions" process is a lot more
>> polished on many of these projects, and there's a bunch such things we
>> kinda want to look into longer-term. And this really is all long-term,
>> because just the initial git server migration most likely won't even
>> start until next year.
>>
>> A much bigger thing for us is CI integration. patchwork + patch bombs
>> + lots of tears and gin do kinda work, but it's super painful and a
>> real chaos no one has any overview over. gitlab has really neat
>> integrated CI for anything that you can run on containers/virtual
>> machines (already played with it, pretty dope, and I have 0 clue about
>> this docker/container stuff). And also seems to have good support to
>> tie all kinds of exterrnal CI validation into pull requests (well
>> gitlab calls them merge requests, it's the same).
>>
>> One thing we're at least planning to experiment with is to take the
>> driver pull requests from drm, auto-convert them into gitlab merge
>> requests (or just ask people to directly do that), and then let to
>> bots go wild. Would give us a nice single point where you can check
>> all the information from all the different checks and vendor CI and
>> everything. Not even that much with the goal to do the merge using the
>> web ui, just to integrate all the testing and validation in one spot.
>>
>> > And the reason I mention the trivial tree is not because the trivial
>> > tree itself is all that interesting or because I'd like to belittle
>> > that model ("that will only work for trivial unimportant stuff"), but
>> > because it might be a good area to experiment in, and a way to get
>> > people used to the flow.
>> >
>> > Because if somebody is willing to every once in a while look at
>> > trivial tree pull requests and merge them to the trivial tree, maybe
>> > that person will start using the same flow for their "real" work.
>> >
>> > And I do think that "patches by email" doesn't scale. I've been there,
>> > done that, and I got the T-shirt.
>> >
>> > I used tools that some people absolutely hated to get out of that
>> > rat-hole. When that failed, I had to write my own.
>> >
>> > So I very much do think that email doesn't really work at scale.
>> >
>> > But I know the kernel people who still do real development (as opposed
>> > to me) work that way.
>> >
>> > So let me suggest a topic for the maintainer summit:
>> >   "Live without email - possible?"
>> >
>> > just to get that ball rolling
>>
>> I'd say "nope", even with the s/live/patches/. Definitely not for
>> anything spanning subsystems. Even within gitlabd the cross-tree
>> support is not (yet) there. And we definitely need to have a solid
>> gitlab/mailing list gateway, which is somewhere on the huge list of
>> things fd.o admins need to do. It exists, but SMTP is pain, and fd.o
>> is volunteer run, so all takes time. And then the gateway might be too
>> much garbage to be useful.
>
> I believe we need a common communication system that is supported by all
> subsystems. Today that system is email.
>
> If we don't want to challenge that, we'll need first-class compatibility
> between whatever new tool we introduce and email, in both direction. All
> discussions, including patch review, happening through other means (web UI for
> instance) will need to be pushed to emails, and email replies will need to be
> integrated back into the system, in such a way that will not completely mess
> up the formatting and communication flow. It has to be transparent enough.
>
> If we want to challenge that, we'll have to agree about another communication
> system for the whole kernel. While I don't think that's realistic, I'm not
> opposed to discussing it. However, I expect many developers to come up with
> lists of requirements, and the result of merging all those requirements
> together to be exactly email and nothing else :-)
>
> On my side, there are three very important features that a communication
> system should have:
>
> - It should be push-based. I don't want to have to log in and pull information
> from web UIs.
>
> - It should be customizable, offering an easy way to script review, and patch
> and pull request handling.
>
> - It should offer an offline mode. Lots of us travel a lot or generally have
> to work without an internet connection more often than we would like, so any
> solution that requires being online won't work.
>
> Emails provide all that, there may be good options I just fail to think about
> right now.

Thanks for your list, "figuring out what we need from email to
evaluate the usefulness of the gitlab gateway" was somewhere on my
todo :-)

More seriously: We're _really_ not far beyond the "hey, what about
gitlab" stage of this entire discussions. As mentioned, I have not
much answers, much less a plan, right now. The mail goal here is just
to figure out the right questions (and then hopefully have some useful
progress to report at LPC already).

>> My goal at least with this is much more in figuring out new workflows,
>> and running a pile of experiments. As mentioned, we don't yet even
>> have a plan for all this, the goal here is to spark some discussions
>> and figure out whether maybe others want to come along for the ride.
>
> I recently had to deal with a new bugs and tasks management tool that was
> developed in-house by a customer of mine. The tool was presented to us in its
> first RFC version (and in source code form, which is very nice), with very few
> implemented features, and without telling us what process it was supposed to
> support. When I inquired I got told that the process hasn't been taken into
> consideration to develop the tool, and that it would just come into existence
> as a result of the tool. Needless to say, it was hard for me to review the
> code, without knowing what it was supposed to do.
>
> I don't claim we're going to that extreme, but I believe it would be useful to
> detail the problems we have in order to find solutions, instead of proposing
> solutions and then trying to retrofit them to problems.

We're definitely starting with some pain points, and don't do this
gitlab thing as an a solution looking desperately for a problem. With
my intel hat on there's a few main ones:
- CI integration with patchwork is a pain, for developers, maintainers
and CI people all alike. I plan to do some slides on what exactly
sucks and what gitlab is doing better, but I'm just not quite there
yet. As mentioned somewhere else, ideally we'd have the full demo
ready for LPC using the userspace igt gpu tests repo.
- First contributor flow can be (if done correctly) so much more fun
than mailing lists. There's been a bit of chatting on this already in
this thread.
- Tracking patch series as they evolve from RFC to final reviewed
version. Patchwork, even with all the extensions we have since years
in the fd.o one, just can't cope. This might be an artifact of our
group maintainership + committer model, I think for single maintainer
patchwork does work a bit better. This is the "patches on mailing
lists don't scale, I have the T-shirt" problem Linus already
mentioned. Our PMs/managers also don't like that they can't keep track
of what the fairly big drm/i915 team is doing :-)

Aside: If you want to be involved in the nitty gritty details (aka
lots of boring fd.o admin discussions), here's the overall migration
tracking task: https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/69

>> Whether anything of this will make it into the production drm
>> processes, no idea. "maybe" is the best answer at this time I think.
>>
>> And yes I hope that by LPC I'll have a bit more solid understanding of
>> how this gitlab thing works and what we could try out, so this isn't
>> as much high-level gossipping as it is right now :-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Sean Paul]

On Mon, Sep 10, 2018 at 4:15 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> On Monday, 10 September 2018 18:13:05 EEST Jiri Kosina wrote:
> > On Mon, 10 Sep 2018, James Bottomley wrote:
> > >    1. How do reviews happen?  Non email projects tend to have only one
> > >       review mechanism (gerrit, github, gitlab, etc.) and stick to it.  Do
> > >       we want to pick a technology or allow multiple?  I don't think this
> > >       is kernel wide, it could be a sybsystem choice.
> >
> > Yeah, but OTOH even now I've heard a lot of feedback about the irregular
> > contributors / newcomers being confused by different subsystems having
> > different processess and requirements; and those are basically just rather
> > "minor" things currently (bugzilla usage, patchwork usage, subscriber-only
> > mailinglists, etc), but it's still enough to confuse the hell out of
> > people.
>
> That's also one of my concerns. The differences between subsystems that all
> use an email-based review process can already be confusing, or just annoying
> to handle, especially when specific tools are mandated (the DRM dim tool or
> the ARM patch system come to mind). I dread to think about how painful it
> would be if one subsystem adopted gitlab, another one gerrit, ...

The other way to look at this is as a feature, not a bug. As mentioned
upthread, each subsystem is essentially its own oss project at this
point, so why keep pretending they're all the same thing? At least in
the gitlab/gerrit/github nightmare, the differing contributing rules
would be obvious as opposed to implicit as they are today.


> That would
> also make changes that cross subsystem boundaries a nightmare to handle. Let's
> not forget that many developers are not confined within a single subsystem.

Well, yeah, this kind of blows a hole in what I said above. I'm
imagining Kees crying out in pain thinking about tree-wide changes in
this new world :-).

That said, there's probably a pretty good middle ground between what
we have now and the gitlab utopia.

Sean

>
> On the other hand, I don't really see how switching the whole kernel to gitlab
> (or another system) could happen without frustrating a very large number of
> developers. We all know how conservative the community tend to be.
>
> One possible course of action would be to make the new tools optional and keep
> email as a common denominator. That way the old dinosaurs who won't adopt any
> tool introducing even the slightest disturbance in their work flow (it's not
> pleasant to realize that I may well be one of them) will still be able to work
> undisturbed, and all the other developers would be able to enjoy the myriad of
> amazing features offered by their tooling of choice. This would however put an
> extra burden on the new tools that would need to have first-class email
> compatibility. I don't know whether that would be feasible.
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

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

[Theodore Y. Ts'o]

On Mon, Sep 10, 2018 at 11:32:00PM +0300, Laurent Pinchart wrote:
> On my side, there are three very important features that a communication 
> system should have:
> 
> - It should be push-based. I don't want to have to log in and pull information 
> from web UIs.
> 
> - It should be customizable, offering an easy way to script review, and patch 
> and pull request handling.
> 
> - It should offer an offline mode. Lots of us travel a lot or generally have 
> to work without an internet connection more often than we would like, so any 
> solution that requires being online won't work.
> 
> Emails provide all that, there may be good options I just fail to think about 
> right now.

One more requirement I would add is that messages should be archived,
and should have a first class search system.  We should be able to
reference a commit id in a communications thread, and then a search
for that commit id (or commit description) should be able to turn up
that message, and from there, be able to see the rest of the messages
on that thread.

Being able to find the "legislative history" behind a particular
change in the kernel is super-important.

				- Ted

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

[Konstantin Ryabitsev]

[-- Attachment #1.1: Type: text/plain, Size: 2826 bytes --]

On 9/10/18 4:32 PM, Laurent Pinchart wrote:
> If we want to challenge that, we'll have to agree about another communication 
> system for the whole kernel. While I don't think that's realistic, I'm not 
> opposed to discussing it. However, I expect many developers to come up with 
> lists of requirements, and the result of merging all those requirements 
> together to be exactly email and nothing else :-)
> 
> On my side, there are three very important features that a communication 
> system should have:
> 
> - It should be push-based. I don't want to have to log in and pull information 
> from web UIs.
> 
> - It should be customizable, offering an easy way to script review, and patch 
> and pull request handling.
> 
> - It should offer an offline mode. Lots of us travel a lot or generally have 
> to work without an internet connection more often than we would like, so any 
> solution that requires being online won't work.

This is part of the reason why I mentioned pagure.io in a different
thread -- it is mostly a web-ui sitting on top of gitolite and was
written with an eye to be fully workable via ssh and email:

https://docs.pagure.org/pagure/overview.html#overview

With Pagure, *theoretically* (I haven't looked in any depth into any of
it), everyone who is happy with the current gitolite/email workflow
would just continue using their existing routine. Anyone who wants to
use the UI for issue tracking and pull requests can optionally choose to
do so. Since it uses gitolite, there wouldn't be a "flag day" where
everyone would have to switch to the new workflow.

It is used by Fedora and therefore, I guess, is to some degree "backed"
by Red Hat (in the same sense as how Fedora is "backed" by Red Hat). It
also has the benefit of not suffering from the "community edition" vs.
"commercial edition" duality that GitLab has. From my experience using
Puppet, I know how tempting it is for orgs to prevent useful features
from making it into the "community edition" if they can charge for them
instead.

That said, I'm not sure if this would actually reduce confusion instead
of creating more. We know for a fact that central issue tracking a-la
Github would fail for the kernel unless there is someone in a
janitorial^W heroic position of figuring out to whom assign each
incoming bug. I also know from experience that almost every web UI tool
written to work with git chokes and fails on something as large as the
kernel or when hit with a firehose of chatter like LKML.

In other words, I'm not at all ra-ra about implementing this, but if
there is enough consensus that it's worth trying out, I will be happy to
set something up for a test spin.

Best,
-- 
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Josh Triplett]

On Mon, Sep 10, 2018 at 10:59:26PM +0300, Laurent Pinchart wrote:
> One of the issues here is that patch series don't have fixed boundaries over 
> their lifetime, the same way patches don't. A patch can evolve in scope from 
> version to version, and similarly so can a patch series. It's not uncommon for 
> patches to be dropped or added and for series to be split or merged. I've in 
> the past incorporated part of an RFC patch series in the v1 of a series with a 
> larger scope (after discussing it with the original developer of course).

I do have some tools and algorithms that could be adapted to help
cross-match patch series and show how they evolve over time. It isn't
that hard to detect patch reordering and show interdiffs between
corresponding patches. Extending that to match patches between series
isn't much harder.

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

[Laurent Pinchart]

Hi Daniel,

On Monday, 10 September 2018 23:55:22 EEST Daniel Vetter wrote:
> On Mon, Sep 10, 2018 at 10:32 PM, Laurent Pinchart wrote:
> > On Monday, 10 September 2018 18:56:18 EEST Daniel Vetter wrote:
> >> On Mon, Sep 10, 2018 at 4:53 PM, Linus Torvalds wrote:
> >>> On Sun, Sep 9, 2018 at 10:59 PM Daniel Vetter wrote:
> >>>> - Assuming it gets accepted I think my LPC talk on "migrating to
> >>>> gitlab" will raise some questions, and probably overflow into hallway
> >>>> track or a BOF session.
> >> 
> >> First a bit more context: This is a different talk than the other
> >> "stuff drm people are doing" talks I've done in the past: We haven't
> >> done anything yet. We haven't even really started planning the
> >> migration yet :-)
> >> 
> >> The idea here was that for once I don't do a talk when it's all done,
> >> but way ahead of that when we're still figuring things out. The
> >> underlying reason for the migration is that fd.o admins want to shut
> >> down their home-grown collage of services and replace it with
> >> something that's much easier to maintain, provides solid 2FA and
> >> allows them to offload a lot of the admin work (handing out access
> >> rights and stuff) to all the projects their hosting. Plus stop the
> >> shell access services, if that's ever possible.
> >> 
> >> So right now this is only about moving the git server from one place
> >> to the other. And we haven't even done the full plan for that
> >> migration (it's a pile of repos and stuff). So really very early. But
> >> now that we do have this modern thing, a lot of people are looking
> >> into all the shiny features it offers, and trying to figure out
> >> whether they're useful for us or not. And that's what I want to go
> >> through in the talk - the title is a bit on the clickbait side :-)
> >> 
> >>> I've not used gitlab personally, but I *have* used github for a much
> >>> smaller project.
> >>> 
> >>> I have to say, the random and relaxed model is enjoyable. I can see
> >>> how somebody coming from that, then finds the strict kernel rules (and
> >>> _different_ rules for different parts) off-putting and confusing.
> >>> 
> >>> At the same time, I have to say that people need to keep in mind that
> >>> the kernel is *different*. We're not a small project with five
> >>> developers that isn't all that critical. Some of our off-putting
> >>> development models are there for a very very good reason. I think a
> >>> lot of people who find the kernel unfriendly just don't appreciate
> >>> that part.
> >>> 
> >>> The kernel used to be pretty free-wheeling too. 20+ years ago.
> >> 
> >> What I definitely don't want is a free-wheeling thing a la your
> >> standard github repo. There's also the issue that github massively
> >> optimizes for small projects in their entire setup. I've done a blog
> >> post about that a while ago and chatted with a bunch of githubbers,
> >> they're really not interested in big-project workflows that much.
> >> 
> >> gitlab otoh is very interested in that, and they picked up some of the
> >> concepts around how we use topic branches and pull requests in the
> >> kernel. It's by far not all implemented yet, but a lot more promising
> >> than anything else I've looked at. And we can always just keep using
> >> our existing tooling ofc.
> >> 
> >> Aside from this there's a bunch of other reasons fd.o admins picked
> >> gitlab (against other contenders they checked out), but this is one of
> >> the big ones. At least from the kernel's pov. For anyone bored enough,
> >> here's the full details of the why from fd.o admins:
> >> 
> >> https://www.fooishbar.org/blog/gitlab-fdo-introduction/
> >> 
> >>> And I still hate how github ends up making it really really easy to
> >>> make horribly bad commit messages, and it encourages a "just rebase on
> >>> top of the integration branch" model, and I do not believe that it
> >>> would ever work for the kernel at large. Too much room for chaos.
> >>> 
> >>> BUT.
> >>> 
> >>> I do think it's still instructive to look at how those "fun small
> >>> projects" work. Having the whole web interface and a more relaxed
> >>> setup is a good thing. And it's probably *better* than the strict
> >>> rules when you don't really need those strict rules.
> >>> 
> >>> So I do believe that it could work for a subsystem. Because "too much
> >>> room for chaos" ends up being nice when you don't want to worry about
> >>> the proper channels etc.
> >>> 
> >>> For example, we've had the "trivial tree", which tends to be a really
> >>> thankless project, that might well be managed way more easily by just
> >>> having a random tree that lots of people can commit to, and we could
> >>> even encourage the github (gitlab?) model of random non-kernel people
> >>> just sending their random trees to it, and have then the group of
> >>> committers be able to merge the changes (and at least on github, the
> >>> default merge is just a fast-forward, so it actually acts more like a
> >>> patch queue than a git tree).
> >> 
> >> Yeah, the trivial/"fun first contributions" process is a lot more
> >> polished on many of these projects, and there's a bunch such things we
> >> kinda want to look into longer-term. And this really is all long-term,
> >> because just the initial git server migration most likely won't even
> >> start until next year.
> >> 
> >> A much bigger thing for us is CI integration. patchwork + patch bombs
> >> + lots of tears and gin do kinda work, but it's super painful and a
> >> real chaos no one has any overview over. gitlab has really neat
> >> integrated CI for anything that you can run on containers/virtual
> >> machines (already played with it, pretty dope, and I have 0 clue about
> >> this docker/container stuff). And also seems to have good support to
> >> tie all kinds of exterrnal CI validation into pull requests (well
> >> gitlab calls them merge requests, it's the same).
> >> 
> >> One thing we're at least planning to experiment with is to take the
> >> driver pull requests from drm, auto-convert them into gitlab merge
> >> requests (or just ask people to directly do that), and then let to
> >> bots go wild. Would give us a nice single point where you can check
> >> all the information from all the different checks and vendor CI and
> >> everything. Not even that much with the goal to do the merge using the
> >> web ui, just to integrate all the testing and validation in one spot.
> >> 
> >>> And the reason I mention the trivial tree is not because the trivial
> >>> tree itself is all that interesting or because I'd like to belittle
> >>> that model ("that will only work for trivial unimportant stuff"), but
> >>> because it might be a good area to experiment in, and a way to get
> >>> people used to the flow.
> >>> 
> >>> Because if somebody is willing to every once in a while look at
> >>> trivial tree pull requests and merge them to the trivial tree, maybe
> >>> that person will start using the same flow for their "real" work.
> >>> 
> >>> And I do think that "patches by email" doesn't scale. I've been there,
> >>> done that, and I got the T-shirt.
> >>> 
> >>> I used tools that some people absolutely hated to get out of that
> >>> rat-hole. When that failed, I had to write my own.
> >>> 
> >>> So I very much do think that email doesn't really work at scale.
> >>> 
> >>> But I know the kernel people who still do real development (as opposed
> >>> to me) work that way.
> >>> 
> >>> So let me suggest a topic for the maintainer summit:
> >>>   "Live without email - possible?"
> >>> 
> >>> just to get that ball rolling
> >> 
> >> I'd say "nope", even with the s/live/patches/. Definitely not for
> >> anything spanning subsystems. Even within gitlabd the cross-tree
> >> support is not (yet) there. And we definitely need to have a solid
> >> gitlab/mailing list gateway, which is somewhere on the huge list of
> >> things fd.o admins need to do. It exists, but SMTP is pain, and fd.o
> >> is volunteer run, so all takes time. And then the gateway might be too
> >> much garbage to be useful.
> > 
> > I believe we need a common communication system that is supported by all
> > subsystems. Today that system is email.
> > 
> > If we don't want to challenge that, we'll need first-class compatibility
> > between whatever new tool we introduce and email, in both direction. All
> > discussions, including patch review, happening through other means (web UI
> > for instance) will need to be pushed to emails, and email replies will
> > need to be integrated back into the system, in such a way that will not
> > completely mess up the formatting and communication flow. It has to be
> > transparent enough.
> > 
> > If we want to challenge that, we'll have to agree about another
> > communication system for the whole kernel. While I don't think that's
> > realistic, I'm not opposed to discussing it. However, I expect many
> > developers to come up with lists of requirements, and the result of
> > merging all those requirements together to be exactly email and nothing
> > else :-)
> > 
> > On my side, there are three very important features that a communication
> > system should have:
> > 
> > - It should be push-based. I don't want to have to log in and pull
> > information from web UIs.
> > 
> > - It should be customizable, offering an easy way to script review, and
> > patch and pull request handling.
> > 
> > - It should offer an offline mode. Lots of us travel a lot or generally
> > have to work without an internet connection more often than we would
> > like, so any solution that requires being online won't work.
> > 
> > Emails provide all that, there may be good options I just fail to think
> > about right now.
> 
> Thanks for your list, "figuring out what we need from email to
> evaluate the usefulness of the gitlab gateway" was somewhere on my
> todo :-)

On a serious note, if you could come up with a communication system that have 
all (or most) of the good features or email, without the drawbacks, I would 
love that. Many have tried and failed, but I hope I'll see someone succeeding 
in my lifetime.

> More seriously: We're _really_ not far beyond the "hey, what about
> gitlab" stage of this entire discussions. As mentioned, I have not
> much answers, much less a plan, right now. The mail goal here is just
> to figure out the right questions (and then hopefully have some useful
> progress to report at LPC already).
> 
> >> My goal at least with this is much more in figuring out new workflows,
> >> and running a pile of experiments. As mentioned, we don't yet even
> >> have a plan for all this, the goal here is to spark some discussions
> >> and figure out whether maybe others want to come along for the ride.
> > 
> > I recently had to deal with a new bugs and tasks management tool that was
> > developed in-house by a customer of mine. The tool was presented to us in
> > its first RFC version (and in source code form, which is very nice), with
> > very few implemented features, and without telling us what process it was
> > supposed to support. When I inquired I got told that the process hasn't
> > been taken into consideration to develop the tool, and that it would just
> > come into existence as a result of the tool. Needless to say, it was hard
> > for me to review the code, without knowing what it was supposed to do.
> > 
> > I don't claim we're going to that extreme, but I believe it would be
> > useful to detail the problems we have in order to find solutions, instead
> > of proposing solutions and then trying to retrofit them to problems.
> 
> We're definitely starting with some pain points, and don't do this
> gitlab thing as an a solution looking desperately for a problem. With
> my intel hat on there's a few main ones:
> 
> - CI integration with patchwork is a pain, for developers, maintainers
> and CI people all alike. I plan to do some slides on what exactly
> sucks and what gitlab is doing better, but I'm just not quite there
> yet. As mentioned somewhere else, ideally we'd have the full demo
> ready for LPC using the userspace igt gpu tests repo.

I'm interested in knowing whether you think this is due to the concept behind 
patchwork, or to the current implementation. I like the idea of patchwork as a 
tool that assists an email-based workflow in areas where emails are too 
limited. I think we could do much more, and I believe we could achieve a good 
result, while keeping the same philosophy.

> - First contributor flow can be (if done correctly) so much more fun
> than mailing lists. There's been a bit of chatting on this already in
> this thread.

I recall lots of frustration from regular contributors during a discussion 
about kernel maintainership, where many considered that we went to extremes to 
help first contributors, while very little was done to address the issues of 
regular contributors. Let's keep both sides in mind, otherwise we'll end up 
moving our development process to instagram because, you know, that's where 
the new generation is, people don't use e-mails anymore.

> - Tracking patch series as they evolve from RFC to final reviewed
> version. Patchwork, even with all the extensions we have since years
> in the fd.o one, just can't cope. This might be an artifact of our
> group maintainership + committer model, I think for single maintainer
> patchwork does work a bit better. This is the "patches on mailing
> lists don't scale, I have the T-shirt" problem Linus already
> mentioned. Our PMs/managers also don't like that they can't keep track
> of what the fairly big drm/i915 team is doing :-)

I've pointed out the issue that patch series don't always have fixed 
boundaries in another reply to this thread, and I think that's the core reason 
why this problem isn't solvable. We should have a working solution for the 
common case though, and I fail to see why a tool like patchwork couldn't do it 
(not claiming it does at the moment of course).

> Aside: If you want to be involved in the nitty gritty details (aka
> lots of boring fd.o admin discussions), here's the overall migration
> tracking task:
> https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/69
> 
> >> Whether anything of this will make it into the production drm
> >> processes, no idea. "maybe" is the best answer at this time I think.
> >> 
> >> And yes I hope that by LPC I'll have a bit more solid understanding of
> >> how this gitlab thing works and what we could try out, so this isn't
> >> as much high-level gossipping as it is right now :-)
> 
> Cheers, Daniel

-- 
Regards,

Laurent Pinchart

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

[Laurent Pinchart]

Hi Sean,

On Tuesday, 11 September 2018 00:09:02 EEST Sean Paul wrote:
> On Mon, Sep 10, 2018 at 4:15 PM Laurent Pinchart wrote:
> > On Monday, 10 September 2018 18:13:05 EEST Jiri Kosina wrote:
> >> On Mon, 10 Sep 2018, James Bottomley wrote:
> >>>    1. How do reviews happen?  Non email projects tend to have only one
> >>>       review mechanism (gerrit, github, gitlab, etc.) and stick to it.
> >>>       Do we want to pick a technology or allow multiple?  I don't
> >>>       think this is kernel wide, it could be a sybsystem choice.
> >> 
> >> Yeah, but OTOH even now I've heard a lot of feedback about the irregular
> >> contributors / newcomers being confused by different subsystems having
> >> different processess and requirements; and those are basically just
> >> rather "minor" things currently (bugzilla usage, patchwork usage,
> >> subscriber-only mailinglists, etc), but it's still enough to confuse the
> >> hell out of people.
> > 
> > That's also one of my concerns. The differences between subsystems that
> > all use an email-based review process can already be confusing, or just
> > annoying to handle, especially when specific tools are mandated (the DRM
> > dim tool or the ARM patch system come to mind). I dread to think about
> > how painful it would be if one subsystem adopted gitlab, another one
> > gerrit, ...
> 
> The other way to look at this is as a feature, not a bug. As mentioned
> upthread, each subsystem is essentially its own oss project at this
> point, so why keep pretending they're all the same thing?

Subsystems are given lots of freedom in how they implement their development 
process, and many use that freedom, but in the end they are all integrated in 
the same kernel. This works because we have a common communication tool.

> At least in the gitlab/gerrit/github nightmare, the differing contributing
> rules would be obvious as opposed to implicit as they are today.

And we would lose the common communication tool.

(And if we went for gerrit, we'd likely lose the majority of developers, but 
that's a separate topic - after having to use gerrit when working on project 
Ara, I now reject any customer project that would force me to use gerrit 
again)

> > That would also make changes that cross subsystem boundaries a nightmare
> > to handle. Let's not forget that many developers are not confined within a
> > single subsystem.
> 
> Well, yeah, this kind of blows a hole in what I said above. I'm
> imagining Kees crying out in pain thinking about tree-wide changes in
> this new world :-).

I had the exact same image :-)

> That said, there's probably a pretty good middle ground between what
> we have now and the gitlab utopia.

I believe we all agree there's lots of room for improvement, that's already 
quite positive.

> > On the other hand, I don't really see how switching the whole kernel to
> > gitlab (or another system) could happen without frustrating a very large
> > number of developers. We all know how conservative the community tend to
> > be.
> > 
> > One possible course of action would be to make the new tools optional and
> > keep email as a common denominator. That way the old dinosaurs who won't
> > adopt any tool introducing even the slightest disturbance in their work
> > flow (it's not pleasant to realize that I may well be one of them) will
> > still be able to work undisturbed, and all the other developers would be
> > able to enjoy the myriad of amazing features offered by their tooling of
> > choice. This would however put an extra burden on the new tools that
> > would need to have first-class email compatibility. I don't know whether
> > that would be feasible.

-- 
Regards,

Laurent Pinchart

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

[Daniel Vetter]

Hi Laurent,

On Mon, Sep 10, 2018 at 11:33 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Monday, 10 September 2018 23:55:22 EEST Daniel Vetter wrote:
>> On Mon, Sep 10, 2018 at 10:32 PM, Laurent Pinchart wrote:
>> > On Monday, 10 September 2018 18:56:18 EEST Daniel Vetter wrote:
>> >> My goal at least with this is much more in figuring out new workflows,
>> >> and running a pile of experiments. As mentioned, we don't yet even
>> >> have a plan for all this, the goal here is to spark some discussions
>> >> and figure out whether maybe others want to come along for the ride.
>> >
>> > I recently had to deal with a new bugs and tasks management tool that was
>> > developed in-house by a customer of mine. The tool was presented to us in
>> > its first RFC version (and in source code form, which is very nice), with
>> > very few implemented features, and without telling us what process it was
>> > supposed to support. When I inquired I got told that the process hasn't
>> > been taken into consideration to develop the tool, and that it would just
>> > come into existence as a result of the tool. Needless to say, it was hard
>> > for me to review the code, without knowing what it was supposed to do.
>> >
>> > I don't claim we're going to that extreme, but I believe it would be
>> > useful to detail the problems we have in order to find solutions, instead
>> > of proposing solutions and then trying to retrofit them to problems.
>>
>> We're definitely starting with some pain points, and don't do this
>> gitlab thing as an a solution looking desperately for a problem. With
>> my intel hat on there's a few main ones:
>>
>> - CI integration with patchwork is a pain, for developers, maintainers
>> and CI people all alike. I plan to do some slides on what exactly
>> sucks and what gitlab is doing better, but I'm just not quite there
>> yet. As mentioned somewhere else, ideally we'd have the full demo
>> ready for LPC using the userspace igt gpu tests repo.
>
> I'm interested in knowing whether you think this is due to the concept behind
> patchwork, or to the current implementation. I like the idea of patchwork as a
> tool that assists an email-based workflow in areas where emails are too
> limited. I think we could do much more, and I believe we could achieve a good
> result, while keeping the same philosophy.

The problem with patchwork is that it's a sidelined add-on. It's not
in your face when doing a normal contribution. Our patchwork tries to
fix that by sending replies to the mailing lists, but to avoid spam,
it only does that when CI is done. While it's still crunching through
your series you have to know a magic link where you can watch it go
through it's backlog. We could update more often, but people already
complain about the spam our CI produces.

gitlab otoh gives you a neat status indicator, and direct links where
you can watch it do its thing live. All neatly integrated into the one
merge request interface.

Now if you've never done CI before, you'll probably go meh on this.
But the trick in making CI really effective is to make it about as
addictive as a slot machine. Instant gratification and quick results
is absolutely key, and developers want to watch it do its things. The
more you can give them that, the more your developers will care about
CI results (the green checkmark quickly starts to look like candy in
your eyes), and the less maintainers have to check this themselves.

There's a bunch of other things, like integration with the git side of
things (you can block a merge if it fails CI). So the above is the
contributor/maintainer perspective.

The CI perspective is that the guy maintaining patchwork for us would
like to do more useful things than maintain a pile of duct-tape :-)
The fully integrated REST api of gitlab is pretty good catnip for
devops types.

>> - First contributor flow can be (if done correctly) so much more fun
>> than mailing lists. There's been a bit of chatting on this already in
>> this thread.
>
> I recall lots of frustration from regular contributors during a discussion
> about kernel maintainership, where many considered that we went to extremes to
> help first contributors, while very little was done to address the issues of
> regular contributors. Let's keep both sides in mind, otherwise we'll end up
> moving our development process to instagram because, you know, that's where
> the new generation is, people don't use e-mails anymore.

First contributors aren't your antagonists, they're your canaries for
bad process. Long timers just suck it up (or don't even see it
anymore), first timers don't even bother because the hurdle is
insurmountable. And yes sometimes it's the other way round, were
problems really show up at scale, but only hurt a bit on the very
first patch. The goal, at least mine, is to make it easier for
everyone, at all levels of experience&contribution.

>> - Tracking patch series as they evolve from RFC to final reviewed
>> version. Patchwork, even with all the extensions we have since years
>> in the fd.o one, just can't cope. This might be an artifact of our
>> group maintainership + committer model, I think for single maintainer
>> patchwork does work a bit better. This is the "patches on mailing
>> lists don't scale, I have the T-shirt" problem Linus already
>> mentioned. Our PMs/managers also don't like that they can't keep track
>> of what the fairly big drm/i915 team is doing :-)
>
> I've pointed out the issue that patch series don't always have fixed
> boundaries in another reply to this thread, and I think that's the core reason
> why this problem isn't solvable. We should have a working solution for the
> common case though, and I fail to see why a tool like patchwork couldn't do it
> (not claiming it does at the moment of course).

gitlab (or well anything with a concept like pull requests) makes the
90% so much easier. And it doesn't take more work for contributors if
you set things up right - it's just a git push instead of a git
send-email. At least after initial setup is done.

And at least in a corporate environment (and I kinda have to care
about that) gitlab wins on the initial setup front hands down against
email. gitlab only needs https (even for git push/pull), and
coproporate firewalls are pretty ok with https. They are not ok with
smtp, like at all. And the amount of time we spend debugging random
git send-email setup issues is epic.

There's alwasy going to be the thing where you have to split up a
patch series into multiple patch series, or merge a few. And then you
need to manually add links to the other/past discussions in either
system. The gitlab plaintext syntax for auto-closing/linking other
issues and merge requests is pretty good, whereas emails it's all
colating web links and msg-id, which at least I personally fine a
chore and so almost never bother with.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Laurent Pinchart]

On Tuesday, 11 September 2018 00:33:36 EEST Laurent Pinchart wrote:
> On Monday, 10 September 2018 23:55:22 EEST Daniel Vetter wrote:
> > On Mon, Sep 10, 2018 at 10:32 PM, Laurent Pinchart wrote:
> >> On Monday, 10 September 2018 18:56:18 EEST Daniel Vetter wrote:
> >>> On Mon, Sep 10, 2018 at 4:53 PM, Linus Torvalds wrote:
> >>>> On Sun, Sep 9, 2018 at 10:59 PM Daniel Vetter wrote:
> >>>>> - Assuming it gets accepted I think my LPC talk on "migrating to
> >>>>> gitlab" will raise some questions, and probably overflow into hallway
> >>>>> track or a BOF session.
> >>> 
> >>> First a bit more context: This is a different talk than the other
> >>> "stuff drm people are doing" talks I've done in the past: We haven't
> >>> done anything yet. We haven't even really started planning the
> >>> migration yet :-)
> >>> 
> >>> The idea here was that for once I don't do a talk when it's all done,
> >>> but way ahead of that when we're still figuring things out. The
> >>> underlying reason for the migration is that fd.o admins want to shut
> >>> down their home-grown collage of services and replace it with
> >>> something that's much easier to maintain, provides solid 2FA and
> >>> allows them to offload a lot of the admin work (handing out access
> >>> rights and stuff) to all the projects their hosting. Plus stop the
> >>> shell access services, if that's ever possible.
> >>> 
> >>> So right now this is only about moving the git server from one place
> >>> to the other. And we haven't even done the full plan for that
> >>> migration (it's a pile of repos and stuff). So really very early. But
> >>> now that we do have this modern thing, a lot of people are looking
> >>> into all the shiny features it offers, and trying to figure out
> >>> whether they're useful for us or not. And that's what I want to go
> >>> through in the talk - the title is a bit on the clickbait side :-)
> >>> 
> >>>> I've not used gitlab personally, but I *have* used github for a much
> >>>> smaller project.
> >>>> 
> >>>> I have to say, the random and relaxed model is enjoyable. I can see
> >>>> how somebody coming from that, then finds the strict kernel rules (and
> >>>> _different_ rules for different parts) off-putting and confusing.
> >>>> 
> >>>> At the same time, I have to say that people need to keep in mind that
> >>>> the kernel is *different*. We're not a small project with five
> >>>> developers that isn't all that critical. Some of our off-putting
> >>>> development models are there for a very very good reason. I think a
> >>>> lot of people who find the kernel unfriendly just don't appreciate
> >>>> that part.
> >>>> 
> >>>> The kernel used to be pretty free-wheeling too. 20+ years ago.
> >>> 
> >>> What I definitely don't want is a free-wheeling thing a la your
> >>> standard github repo. There's also the issue that github massively
> >>> optimizes for small projects in their entire setup. I've done a blog
> >>> post about that a while ago and chatted with a bunch of githubbers,
> >>> they're really not interested in big-project workflows that much.
> >>> 
> >>> gitlab otoh is very interested in that, and they picked up some of the
> >>> concepts around how we use topic branches and pull requests in the
> >>> kernel. It's by far not all implemented yet, but a lot more promising
> >>> than anything else I've looked at. And we can always just keep using
> >>> our existing tooling ofc.
> >>> 
> >>> Aside from this there's a bunch of other reasons fd.o admins picked
> >>> gitlab (against other contenders they checked out), but this is one of
> >>> the big ones. At least from the kernel's pov. For anyone bored enough,
> >>> here's the full details of the why from fd.o admins:
> >>> 
> >>> https://www.fooishbar.org/blog/gitlab-fdo-introduction/
> >>> 
> >>>> And I still hate how github ends up making it really really easy to
> >>>> make horribly bad commit messages, and it encourages a "just rebase on
> >>>> top of the integration branch" model, and I do not believe that it
> >>>> would ever work for the kernel at large. Too much room for chaos.
> >>>> 
> >>>> BUT.
> >>>> 
> >>>> I do think it's still instructive to look at how those "fun small
> >>>> projects" work. Having the whole web interface and a more relaxed
> >>>> setup is a good thing. And it's probably *better* than the strict
> >>>> rules when you don't really need those strict rules.
> >>>> 
> >>>> So I do believe that it could work for a subsystem. Because "too much
> >>>> room for chaos" ends up being nice when you don't want to worry about
> >>>> the proper channels etc.
> >>>> 
> >>>> For example, we've had the "trivial tree", which tends to be a really
> >>>> thankless project, that might well be managed way more easily by just
> >>>> having a random tree that lots of people can commit to, and we could
> >>>> even encourage the github (gitlab?) model of random non-kernel people
> >>>> just sending their random trees to it, and have then the group of
> >>>> committers be able to merge the changes (and at least on github, the
> >>>> default merge is just a fast-forward, so it actually acts more like a
> >>>> patch queue than a git tree).
> >>> 
> >>> Yeah, the trivial/"fun first contributions" process is a lot more
> >>> polished on many of these projects, and there's a bunch such things we
> >>> kinda want to look into longer-term. And this really is all long-term,
> >>> because just the initial git server migration most likely won't even
> >>> start until next year.
> >>> 
> >>> A much bigger thing for us is CI integration. patchwork + patch bombs
> >>> + lots of tears and gin do kinda work, but it's super painful and a
> >>> real chaos no one has any overview over. gitlab has really neat
> >>> integrated CI for anything that you can run on containers/virtual
> >>> machines (already played with it, pretty dope, and I have 0 clue about
> >>> this docker/container stuff). And also seems to have good support to
> >>> tie all kinds of exterrnal CI validation into pull requests (well
> >>> gitlab calls them merge requests, it's the same).
> >>> 
> >>> One thing we're at least planning to experiment with is to take the
> >>> driver pull requests from drm, auto-convert them into gitlab merge
> >>> requests (or just ask people to directly do that), and then let to
> >>> bots go wild. Would give us a nice single point where you can check
> >>> all the information from all the different checks and vendor CI and
> >>> everything. Not even that much with the goal to do the merge using the
> >>> web ui, just to integrate all the testing and validation in one spot.
> >>> 
> >>>> And the reason I mention the trivial tree is not because the trivial
> >>>> tree itself is all that interesting or because I'd like to belittle
> >>>> that model ("that will only work for trivial unimportant stuff"), but
> >>>> because it might be a good area to experiment in, and a way to get
> >>>> people used to the flow.
> >>>> 
> >>>> Because if somebody is willing to every once in a while look at
> >>>> trivial tree pull requests and merge them to the trivial tree, maybe
> >>>> that person will start using the same flow for their "real" work.
> >>>> 
> >>>> And I do think that "patches by email" doesn't scale. I've been there,
> >>>> done that, and I got the T-shirt.
> >>>> 
> >>>> I used tools that some people absolutely hated to get out of that
> >>>> rat-hole. When that failed, I had to write my own.
> >>>> 
> >>>> So I very much do think that email doesn't really work at scale.
> >>>> 
> >>>> But I know the kernel people who still do real development (as opposed
> >>>> to me) work that way.
> >>>> 
> >>>> So let me suggest a topic for the maintainer summit:
> >>>>   "Live without email - possible?"
> >>>> 
> >>>> just to get that ball rolling
> >>> 
> >>> I'd say "nope", even with the s/live/patches/. Definitely not for
> >>> anything spanning subsystems. Even within gitlabd the cross-tree
> >>> support is not (yet) there. And we definitely need to have a solid
> >>> gitlab/mailing list gateway, which is somewhere on the huge list of
> >>> things fd.o admins need to do. It exists, but SMTP is pain, and fd.o
> >>> is volunteer run, so all takes time. And then the gateway might be too
> >>> much garbage to be useful.
> >> 
> >> I believe we need a common communication system that is supported by all
> >> subsystems. Today that system is email.
> >> 
> >> If we don't want to challenge that, we'll need first-class compatibility
> >> between whatever new tool we introduce and email, in both direction. All
> >> discussions, including patch review, happening through other means (web
> >> UI for instance) will need to be pushed to emails, and email replies will
> >> need to be integrated back into the system, in such a way that will not
> >> completely mess up the formatting and communication flow. It has to be
> >> transparent enough.
> >> 
> >> If we want to challenge that, we'll have to agree about another
> >> communication system for the whole kernel. While I don't think that's
> >> realistic, I'm not opposed to discussing it. However, I expect many
> >> developers to come up with lists of requirements, and the result of
> >> merging all those requirements together to be exactly email and nothing
> >> else :-)
> >> 
> >> On my side, there are three very important features that a communication
> >> system should have:
> >> 
> >> - It should be push-based. I don't want to have to log in and pull
> >> information from web UIs.
> >> 
> >> - It should be customizable, offering an easy way to script review, and
> >> patch and pull request handling.
> >> 
> >> - It should offer an offline mode. Lots of us travel a lot or generally
> >> have to work without an internet connection more often than we would
> >> like, so any solution that requires being online won't work.
> >> 
> >> Emails provide all that, there may be good options I just fail to think
> >> about right now.
> > 
> > Thanks for your list, "figuring out what we need from email to
> > evaluate the usefulness of the gitlab gateway" was somewhere on my
> > todo :-)
> 
> On a serious note, if you could come up with a communication system that
> have all (or most) of the good features or email, without the drawbacks, I
> would love that. Many have tried and failed, but I hope I'll see someone
> succeeding in my lifetime.
> 
> > More seriously: We're _really_ not far beyond the "hey, what about
> > gitlab" stage of this entire discussions. As mentioned, I have not
> > much answers, much less a plan, right now. The mail goal here is just
> > to figure out the right questions (and then hopefully have some useful
> > progress to report at LPC already).
> > 
> >>> My goal at least with this is much more in figuring out new workflows,
> >>> and running a pile of experiments. As mentioned, we don't yet even
> >>> have a plan for all this, the goal here is to spark some discussions
> >>> and figure out whether maybe others want to come along for the ride.
> >> 
> >> I recently had to deal with a new bugs and tasks management tool that
> >> was developed in-house by a customer of mine. The tool was presented to
> >> us in its first RFC version (and in source code form, which is very
> >> nice), with very few implemented features, and without telling us what
> >> process it was supposed to support. When I inquired I got told that the
> >> process hasn't been taken into consideration to develop the tool, and
> >> that it would just come into existence as a result of the tool. Needless
> >> to say, it was hard for me to review the code, without knowing what it
> >> was supposed to do.
> >> 
> >> I don't claim we're going to that extreme, but I believe it would be
> >> useful to detail the problems we have in order to find solutions,
> >> instead of proposing solutions and then trying to retrofit them to
> >> problems.
> > 
> > We're definitely starting with some pain points, and don't do this
> > gitlab thing as an a solution looking desperately for a problem. With
> > my intel hat on there's a few main ones:
> > 
> > - CI integration with patchwork is a pain, for developers, maintainers
> > and CI people all alike. I plan to do some slides on what exactly
> > sucks and what gitlab is doing better, but I'm just not quite there
> > yet. As mentioned somewhere else, ideally we'd have the full demo
> > ready for LPC using the userspace igt gpu tests repo.
> 
> I'm interested in knowing whether you think this is due to the concept
> behind patchwork, or to the current implementation. I like the idea of
> patchwork as a tool that assists an email-based workflow in areas where
> emails are too limited. I think we could do much more, and I believe we
> could achieve a good result, while keeping the same philosophy.
> 
> > - First contributor flow can be (if done correctly) so much more fun
> > than mailing lists. There's been a bit of chatting on this already in
> > this thread.
> 
> I recall lots of frustration from regular contributors during a discussion
> about kernel maintainership, where many considered that we went to extremes
> to help first contributors, while very little was done to address the
> issues of regular contributors. Let's keep both sides in mind, otherwise
> we'll end up moving our development process to instagram because, you know,
> that's where the new generation is, people don't use e-mails anymore.

After a private discussion I realize I've chosen my words unwisely. Newcomers 
and regular contributors are not antagonists, as "both sides" could be 
interpreted to mean. I really meant "everybody" here, as we have a continuum 
of profiles in our developers community.

We should strive for making everybody happy. My point is that, with the large 
number of developers and the wide diversity of profiles, that goal will never 
be fully reached as the processes we put in place can only be the result of a 
compromise. I thus wanted to emphasize that we shouldn't rule e-mail out on 
the basis that it's not ideal, or possibly painful, for some groups of 
profiles, the same way we should not consider a particular process as 
immutable on the basis that other groups of profiles got so used to it that 
they now suffer from Stockholm syndrome. Care needs to be taken to minimize 
the pain points for everybody alike.

> > - Tracking patch series as they evolve from RFC to final reviewed
> > version. Patchwork, even with all the extensions we have since years
> > in the fd.o one, just can't cope. This might be an artifact of our
> > group maintainership + committer model, I think for single maintainer
> > patchwork does work a bit better. This is the "patches on mailing
> > lists don't scale, I have the T-shirt" problem Linus already
> > mentioned. Our PMs/managers also don't like that they can't keep track
> > of what the fairly big drm/i915 team is doing :-)
> 
> I've pointed out the issue that patch series don't always have fixed
> boundaries in another reply to this thread, and I think that's the core
> reason why this problem isn't solvable. We should have a working solution
> for the common case though, and I fail to see why a tool like patchwork
> couldn't do it (not claiming it does at the moment of course).
> 
> > Aside: If you want to be involved in the nitty gritty details (aka
> > lots of boring fd.o admin discussions), here's the overall migration
> > tracking task:
> > https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/69
> > 
> >>> Whether anything of this will make it into the production drm
> >>> processes, no idea. "maybe" is the best answer at this time I think.
> >>> 
> >>> And yes I hope that by LPC I'll have a bit more solid understanding of
> >>> how this gitlab thing works and what we could try out, so this isn't
> >>> as much high-level gossipping as it is right now :-)

-- 
Regards,

Laurent Pinchart

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

[Laurent Pinchart]

Hi Josh,

On Tuesday, 11 September 2018 00:30:19 EEST Josh Triplett wrote:
> On Mon, Sep 10, 2018 at 10:59:26PM +0300, Laurent Pinchart wrote:
> > One of the issues here is that patch series don't have fixed boundaries
> > over their lifetime, the same way patches don't. A patch can evolve in
> > scope from version to version, and similarly so can a patch series. It's
> > not uncommon for patches to be dropped or added and for series to be
> > split or merged. I've in the past incorporated part of an RFC patch
> > series in the v1 of a series with a larger scope (after discussing it
> > with the original developer of course).
> 
> I do have some tools and algorithms that could be adapted to help
> cross-match patch series and show how they evolve over time. It isn't
> that hard to detect patch reordering and show interdiffs between
> corresponding patches. Extending that to match patches between series
> isn't much harder.

That would be a very nice addition to patchwork. I believe we need heuristics 
to do this, and by definition they will never achieve a 100% success rate, but 
if we can find most links between patch series, we'll be in a much better 
position than we are now.

-- 
Regards,

Laurent Pinchart

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

[Laurent Pinchart]

Hi Ted,

On Tuesday, 11 September 2018 00:11:28 EEST Theodore Y. Ts'o wrote:
> On Mon, Sep 10, 2018 at 11:32:00PM +0300, Laurent Pinchart wrote:
> > On my side, there are three very important features that a communication
> > system should have:
> > 
> > - It should be push-based. I don't want to have to log in and pull
> > information from web UIs.
> > 
> > - It should be customizable, offering an easy way to script review, and
> > patch and pull request handling.
> > 
> > - It should offer an offline mode. Lots of us travel a lot or generally
> > have to work without an internet connection more often than we would
> > like, so any solution that requires being online won't work.
> > 
> > Emails provide all that, there may be good options I just fail to think
> > about right now.
> 
> One more requirement I would add is that messages should be archived,
> and should have a first class search system.  We should be able to
> reference a commit id in a communications thread, and then a search
> for that commit id (or commit description) should be able to turn up
> that message, and from there, be able to see the rest of the messages
> on that thread.
> 
> Being able to find the "legislative history" behind a particular
> change in the kernel is super-important.

Fully agreed. I would even go one step further, I'd like a system where 
relationships between messages are kept. This obviously means linking patches 
from the same series, but also detecting new versions of patch series (to the 
extent possible, as already discussed in this mail thread).

-- 
Regards,

Laurent Pinchart

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

[Daniel Vetter]

On Mon, Sep 10, 2018 at 11:30 PM, Josh Triplett <josh@joshtriplett.org> wrote:
> On Mon, Sep 10, 2018 at 10:59:26PM +0300, Laurent Pinchart wrote:
>> One of the issues here is that patch series don't have fixed boundaries over
>> their lifetime, the same way patches don't. A patch can evolve in scope from
>> version to version, and similarly so can a patch series. It's not uncommon for
>> patches to be dropped or added and for series to be split or merged. I've in
>> the past incorporated part of an RFC patch series in the v1 of a series with a
>> larger scope (after discussing it with the original developer of course).
>
> I do have some tools and algorithms that could be adapted to help
> cross-match patch series and show how they evolve over time. It isn't
> that hard to detect patch reordering and show interdiffs between
> corresponding patches. Extending that to match patches between series
> isn't much harder.

Is that built on top of the new git range-diff tool, or at least that
concept? Or something else?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Josh Triplett]

On Tue, Sep 11, 2018 at 01:16:18AM +0200, Daniel Vetter wrote:
> On Mon, Sep 10, 2018 at 11:30 PM, Josh Triplett <josh@joshtriplett.org> wrote:
> > On Mon, Sep 10, 2018 at 10:59:26PM +0300, Laurent Pinchart wrote:
> >> One of the issues here is that patch series don't have fixed boundaries over
> >> their lifetime, the same way patches don't. A patch can evolve in scope from
> >> version to version, and similarly so can a patch series. It's not uncommon for
> >> patches to be dropped or added and for series to be split or merged. I've in
> >> the past incorporated part of an RFC patch series in the v1 of a series with a
> >> larger scope (after discussing it with the original developer of course).
> >
> > I do have some tools and algorithms that could be adapted to help
> > cross-match patch series and show how they evolve over time. It isn't
> > that hard to detect patch reordering and show interdiffs between
> > corresponding patches. Extending that to match patches between series
> > isn't much harder.
> 
> Is that built on top of the new git range-diff tool, or at least that
> concept? Or something else?

Same concept, just a different implementation of an algorithm comparable
to tbdiff's.

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

[Rafael J. Wysocki]

On Monday, September 10, 2018 11:19:41 PM CEST Konstantin Ryabitsev wrote:
> On 9/10/18 4:32 PM, Laurent Pinchart wrote:
> > If we want to challenge that, we'll have to agree about another communication 
> > system for the whole kernel. While I don't think that's realistic, I'm not 
> > opposed to discussing it. However, I expect many developers to come up with 
> > lists of requirements, and the result of merging all those requirements 
> > together to be exactly email and nothing else :-)
> > 
> > On my side, there are three very important features that a communication 
> > system should have:
> > 
> > - It should be push-based. I don't want to have to log in and pull information 
> > from web UIs.
> > 
> > - It should be customizable, offering an easy way to script review, and patch 
> > and pull request handling.
> > 
> > - It should offer an offline mode. Lots of us travel a lot or generally have 
> > to work without an internet connection more often than we would like, so any 
> > solution that requires being online won't work.
> 
> This is part of the reason why I mentioned pagure.io in a different
> thread -- it is mostly a web-ui sitting on top of gitolite and was
> written with an eye to be fully workable via ssh and email:
> 
> https://docs.pagure.org/pagure/overview.html#overview
> 
> With Pagure, *theoretically* (I haven't looked in any depth into any of
> it), everyone who is happy with the current gitolite/email workflow
> would just continue using their existing routine. Anyone who wants to
> use the UI for issue tracking and pull requests can optionally choose to
> do so. Since it uses gitolite, there wouldn't be a "flag day" where
> everyone would have to switch to the new workflow.
> 
> It is used by Fedora and therefore, I guess, is to some degree "backed"
> by Red Hat (in the same sense as how Fedora is "backed" by Red Hat). It
> also has the benefit of not suffering from the "community edition" vs.
> "commercial edition" duality that GitLab has. From my experience using
> Puppet, I know how tempting it is for orgs to prevent useful features
> from making it into the "community edition" if they can charge for them
> instead.
> 
> That said, I'm not sure if this would actually reduce confusion instead
> of creating more. We know for a fact that central issue tracking a-la
> Github would fail for the kernel unless there is someone in a
> janitorial^W heroic position of figuring out to whom assign each
> incoming bug.

And knowledge and enough power to make the relevant party actually take care
of the report.

And even with all that it sometimes isn't clear where the problem is to start
with and some debug work needs to be done upfront.

> I also know from experience that almost every web UI tool
> written to work with git chokes and fails on something as large as the
> kernel or when hit with a firehose of chatter like LKML.

Right.

Cheers,
Rafael

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

[Jani Nikula]

On Mon, 10 Sep 2018, Jiri Kosina <jikos@kernel.org> wrote:
> On Mon, 10 Sep 2018, James Bottomley wrote:
>
>>    1. How do reviews happen?  Non email projects tend to have only one
>>       review mechanism (gerrit, github, gitlab, etc.) and stick to it.  Do
>>       we want to pick a technology or allow multiple?  I don't think this
>>       is kernel wide, it could be a sybsystem choice.
>
> Yeah, but OTOH even now I've heard a lot of feedback about the irregular 
> contributors / newcomers being confused by different subsystems having 
> different processess and requirements; and those are basically just rather 
> "minor" things currently (bugzilla usage, patchwork usage, subscriber-only 
> mailinglists, etc), but it's still enough to confuse the hell out of 
> people.

MAINTAINERS is supposed to be the central database about all this. IMO
maintainers should be more active in getting their data updated. We have
folks who don't document their preferences or expectations, at all, and
then go on to rant at random contributors about how their corner of the
kernel community is supposed to operate. For example, that they never
look at bugzilla etc. If the current entries don't cover everything, one
can use W: to add a link to more details, or we can add new entries.

And that's just the obvious prerequisite to actively telling
contributors to look at MAINTAINERS.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

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

[Jani Nikula]

On Mon, 10 Sep 2018, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> That's also one of my concerns. The differences between subsystems that all 
> use an email-based review process can already be confusing, or just annoying 
> to handle, especially when specific tools are mandated (the DRM dim tool or 
> the ARM patch system come to mind).

Note that you don't need to use dim unless you become a committer or a
maintainer to a tree that's maintained using dim.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center

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

[Geert Uytterhoeven]

On Tue, Sep 11, 2018 at 10:44 AM Jani Nikula <jani.nikula@intel.com> wrote:
> On Mon, 10 Sep 2018, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> > That's also one of my concerns. The differences between subsystems that all
> > use an email-based review process can already be confusing, or just annoying
> > to handle, especially when specific tools are mandated (the DRM dim tool or
> > the ARM patch system come to mind).
>
> Note that you don't need to use dim unless you become a committer or a
> maintainer to a tree that's maintained using dim.

Which unfortunately cannot be said about the ARM patch system...

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: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance

[Daniel Vetter]

On Tue, Sep 11, 2018 at 11:08 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Tue, Sep 11, 2018 at 10:44 AM Jani Nikula <jani.nikula@intel.com> wrote:
>> On Mon, 10 Sep 2018, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
>> > That's also one of my concerns. The differences between subsystems that all
>> > use an email-based review process can already be confusing, or just annoying
>> > to handle, especially when specific tools are mandated (the DRM dim tool or
>> > the ARM patch system come to mind).
>>
>> Note that you don't need to use dim unless you become a committer or a
>> maintainer to a tree that's maintained using dim.
>
> Which unfortunately cannot be said about the ARM patch system...

Is there some docs about this ARM patch systems? Or just a link to
what it is? I've never heard of it, until this thread here.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 4826 bytes --]

On Tue, Sep 11, 2018 at 12:38:13AM +0300, Laurent Pinchart wrote:
> Hi Sean,
>
> On Tuesday, 11 September 2018 00:09:02 EEST Sean Paul wrote:
> > On Mon, Sep 10, 2018 at 4:15 PM Laurent Pinchart wrote:
> > > On Monday, 10 September 2018 18:13:05 EEST Jiri Kosina wrote:
> > >> On Mon, 10 Sep 2018, James Bottomley wrote:
> > >>>    1. How do reviews happen?  Non email projects tend to have only one
> > >>>       review mechanism (gerrit, github, gitlab, etc.) and stick to it.
> > >>>       Do we want to pick a technology or allow multiple?  I don't
> > >>>       think this is kernel wide, it could be a sybsystem choice.
> > >>
> > >> Yeah, but OTOH even now I've heard a lot of feedback about the irregular
> > >> contributors / newcomers being confused by different subsystems having
> > >> different processess and requirements; and those are basically just
> > >> rather "minor" things currently (bugzilla usage, patchwork usage,
> > >> subscriber-only mailinglists, etc), but it's still enough to confuse the
> > >> hell out of people.
> > >
> > > That's also one of my concerns. The differences between subsystems that
> > > all use an email-based review process can already be confusing, or just
> > > annoying to handle, especially when specific tools are mandated (the DRM
> > > dim tool or the ARM patch system come to mind). I dread to think about
> > > how painful it would be if one subsystem adopted gitlab, another one
> > > gerrit, ...
> >
> > The other way to look at this is as a feature, not a bug. As mentioned
> > upthread, each subsystem is essentially its own oss project at this
> > point, so why keep pretending they're all the same thing?
>
> Subsystems are given lots of freedom in how they implement their development
> process, and many use that freedom, but in the end they are all integrated in
> the same kernel. This works because we have a common communication tool.
>
> > At least in the gitlab/gerrit/github nightmare, the differing contributing
> > rules would be obvious as opposed to implicit as they are today.
>
> And we would lose the common communication tool.

And not only communication tool, but educational tool. Reviews are
performed by email visible to everyone and are supposed to be
lesson-learned for other contributors. In opposite, gerrit-like tools
favor one-to-one discussions.

>
> (And if we went for gerrit, we'd likely lose the majority of developers, but
> that's a separate topic - after having to use gerrit when working on project
> Ara, I now reject any customer project that would force me to use gerrit
> again)

As the one who suffers from internal gerrit and forced to use it,
I fully agree with you and will add that we will lose most reviewers too,
because it simply too much painful to follow and to do random review there.

>
> > > That would also make changes that cross subsystem boundaries a nightmare
> > > to handle. Let's not forget that many developers are not confined within a
> > > single subsystem.
> >
> > Well, yeah, this kind of blows a hole in what I said above. I'm
> > imagining Kees crying out in pain thinking about tree-wide changes in
> > this new world :-).
>
> I had the exact same image :-)

I already suffer from it while submitting patches both to netdev and
RDMA. The difference in coding style alone makes me nervous every time
I get comment for such cross-subsystem patches. I'm pretty sure that it
will be unbelievable hard to work in "multi-tool world".

>
> > That said, there's probably a pretty good middle ground between what
> > we have now and the gitlab utopia.
>
> I believe we all agree there's lots of room for improvement, that's already
> quite positive.
>
> > > On the other hand, I don't really see how switching the whole kernel to
> > > gitlab (or another system) could happen without frustrating a very large
> > > number of developers. We all know how conservative the community tend to
> > > be.
> > >
> > > One possible course of action would be to make the new tools optional and
> > > keep email as a common denominator. That way the old dinosaurs who won't
> > > adopt any tool introducing even the slightest disturbance in their work
> > > flow (it's not pleasant to realize that I may well be one of them) will
> > > still be able to work undisturbed, and all the other developers would be
> > > able to enjoy the myriad of amazing features offered by their tooling of
> > > choice. This would however put an extra burden on the new tools that
> > > would need to have first-class email compatibility. I don't know whether
> > > that would be feasible.
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Geert Uytterhoeven]

Hi Daniel,

On Tue, Sep 11, 2018 at 12:01 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Tue, Sep 11, 2018 at 11:08 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > On Tue, Sep 11, 2018 at 10:44 AM Jani Nikula <jani.nikula@intel.com> wrote:
> >> On Mon, 10 Sep 2018, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> >> > That's also one of my concerns. The differences between subsystems that all
> >> > use an email-based review process can already be confusing, or just annoying
> >> > to handle, especially when specific tools are mandated (the DRM dim tool or
> >> > the ARM patch system come to mind).
> >>
> >> Note that you don't need to use dim unless you become a committer or a
> >> maintainer to a tree that's maintained using dim.
> >
> > Which unfortunately cannot be said about the ARM patch system...
>
> Is there some docs about this ARM patch systems? Or just a link to
> what it is? I've never heard of it, until this thread here.

http://www.arm.linux.org.uk/developer/patches/info.php

It does take git-send-email patches, IFF they follow the rules.

I've just discovered it's even linked to from Documentation/arm/README,
which is horridly out-of-date (2.6? FTP?).

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: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance

[Daniel Vetter]

On Tue, Sep 11, 2018 at 12:09 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Tue, Sep 11, 2018 at 12:01 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>> On Tue, Sep 11, 2018 at 11:08 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>> > On Tue, Sep 11, 2018 at 10:44 AM Jani Nikula <jani.nikula@intel.com> wrote:
>> >> On Mon, 10 Sep 2018, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
>> >> > That's also one of my concerns. The differences between subsystems that all
>> >> > use an email-based review process can already be confusing, or just annoying
>> >> > to handle, especially when specific tools are mandated (the DRM dim tool or
>> >> > the ARM patch system come to mind).
>> >>
>> >> Note that you don't need to use dim unless you become a committer or a
>> >> maintainer to a tree that's maintained using dim.
>> >
>> > Which unfortunately cannot be said about the ARM patch system...
>>
>> Is there some docs about this ARM patch systems? Or just a link to
>> what it is? I've never heard of it, until this thread here.
>
> http://www.arm.linux.org.uk/developer/patches/info.php

Thanks.

> It does take git-send-email patches, IFF they follow the rules.
>
> I've just discovered it's even linked to from Documentation/arm/README,
> which is horridly out-of-date (2.6? FTP?).

>From a quick look: This is essentially another reimplementation of the
patchwork idea (but probably predating that)? With the difference it's
not all that accepting as patchwork, and it doesn't just automatically
read a mailing list en-passant. Or am I off the mark?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Geert Uytterhoeven]

Hi Daniel,

On Tue, Sep 11, 2018 at 12:17 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Tue, Sep 11, 2018 at 12:09 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > On Tue, Sep 11, 2018 at 12:01 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >> On Tue, Sep 11, 2018 at 11:08 AM, Geert Uytterhoeven
> >> <geert@linux-m68k.org> wrote:
> >> > On Tue, Sep 11, 2018 at 10:44 AM Jani Nikula <jani.nikula@intel.com> wrote:
> >> >> On Mon, 10 Sep 2018, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> >> >> > That's also one of my concerns. The differences between subsystems that all
> >> >> > use an email-based review process can already be confusing, or just annoying
> >> >> > to handle, especially when specific tools are mandated (the DRM dim tool or
> >> >> > the ARM patch system come to mind).
> >> >>
> >> >> Note that you don't need to use dim unless you become a committer or a
> >> >> maintainer to a tree that's maintained using dim.
> >> >
> >> > Which unfortunately cannot be said about the ARM patch system...
> >>
> >> Is there some docs about this ARM patch systems? Or just a link to
> >> what it is? I've never heard of it, until this thread here.
> >
> > http://www.arm.linux.org.uk/developer/patches/info.php
>
> Thanks.
>
> > It does take git-send-email patches, IFF they follow the rules.
> >
> > I've just discovered it's even linked to from Documentation/arm/README,
> > which is horridly out-of-date (2.6? FTP?).
>
> From a quick look: This is essentially another reimplementation of the
> patchwork idea (but probably predating that)? With the difference it's
> not all that accepting as patchwork, and it doesn't just automatically
> read a mailing list en-passant. Or am I off the mark?

That's correct. It is meant for reviewed patches only.

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: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance

[Alexandre Belloni]

Hi,

On 11/09/2018 00:44:57+0200, Daniel Vetter wrote:
> gitlab (or well anything with a concept like pull requests) makes the
> 90% so much easier. And it doesn't take more work for contributors if
> you set things up right - it's just a git push instead of a git
> send-email. At least after initial setup is done.
> 
> And at least in a corporate environment (and I kinda have to care
> about that) gitlab wins on the initial setup front hands down against
> email. gitlab only needs https (even for git push/pull), and
> coproporate firewalls are pretty ok with https. They are not ok with
> smtp, like at all. And the amount of time we spend debugging random
> git send-email setup issues is epic.
> 

I would like to chime in and remind you that there are many subsystems
where you get a lot of drive-by contribution from random people. I'm
obviously thinking about rtc but I think this would also apply to codec,
IIO, power/supply, hwmon... In that case any initial setup would be
prohibitive.

I feel like these subsystems are often left to the side when I read
threads like that talking about getting every patches reviewed, doing
more CI, etc...

So I need to emphasise that there are subsystem where people are not
backed by a company to contribute or review. What I often see is someone
having $random hardware and submitting a patch adding support for it.
That developer will definitively not review other patches because he has
no particular interest in them. He also probably doesn't have the
experience to do a review.

It is quite different from having a few big companies with huge teams
each maintaining a single driver in a subsystem... You simply can't have
the same expectations.

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1714 bytes --]

On Tue, Sep 11, 2018 at 02:44:23PM +0200, Alexandre Belloni wrote:
> On 11/09/2018 00:44:57+0200, Daniel Vetter wrote:

> > gitlab (or well anything with a concept like pull requests) makes the
> > 90% so much easier. And it doesn't take more work for contributors if
> > you set things up right - it's just a git push instead of a git
> > send-email. At least after initial setup is done.

> I would like to chime in and remind you that there are many subsystems
> where you get a lot of drive-by contribution from random people. I'm
> obviously thinking about rtc but I think this would also apply to codec,
> IIO, power/supply, hwmon... In that case any initial setup would be
> prohibitive.

Right, and this is also a potential issue for people working kernel wide
if we end up with a bunch of different instances of gitlab or something
similar.  

> So I need to emphasise that there are subsystem where people are not
> backed by a company to contribute or review. What I often see is someone
> having $random hardware and submitting a patch adding support for it.
> That developer will definitively not review other patches because he has
> no particular interest in them. He also probably doesn't have the
> experience to do a review.

Even where people do have corporate backing for what they're doing
they've often worked pretty hard to even get the time to do submissions,
or they're doing it as a byproduct of whatever the "real" goal is.  It
also reduces the impact from CI quite a bit if you've got lots of random
drivers with most of the changes going in there, though it's still a win
for the core and for any hardware which does manage to make it into a CI
system.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Daniel Vetter]

On Tue, Sep 11, 2018 at 2:44 PM, Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> On 11/09/2018 00:44:57+0200, Daniel Vetter wrote:
>> gitlab (or well anything with a concept like pull requests) makes the
>> 90% so much easier. And it doesn't take more work for contributors if
>> you set things up right - it's just a git push instead of a git
>> send-email. At least after initial setup is done.
>>
>> And at least in a corporate environment (and I kinda have to care
>> about that) gitlab wins on the initial setup front hands down against
>> email. gitlab only needs https (even for git push/pull), and
>> coproporate firewalls are pretty ok with https. They are not ok with
>> smtp, like at all. And the amount of time we spend debugging random
>> git send-email setup issues is epic.
>>
>
> I would like to chime in and remind you that there are many subsystems
> where you get a lot of drive-by contribution from random people. I'm
> obviously thinking about rtc but I think this would also apply to codec,
> IIO, power/supply, hwmon... In that case any initial setup would be
> prohibitive.
>
> I feel like these subsystems are often left to the side when I read
> threads like that talking about getting every patches reviewed, doing
> more CI, etc...
>
> So I need to emphasise that there are subsystem where people are not
> backed by a company to contribute or review. What I often see is someone
> having $random hardware and submitting a patch adding support for it.
> That developer will definitively not review other patches because he has
> no particular interest in them. He also probably doesn't have the
> experience to do a review.
>
> It is quite different from having a few big companies with huge teams
> each maintaining a single driver in a subsystem... You simply can't have
> the same expectations.

Yes drm has drm/i915 and drm/amdgpu. But reducing the graphics folks
to these two big drivers with huge teams backing them, would be about
the same as stating that linux only runs on x86 and arm. There's more.

And we do have quite serious problems with tiny boutique trees and
drive-by contributors who immediately disappear. We're still trying to
do our best to cope with that, which inolves lots of pain, and the
occasional success.

Here's a bunch of things we've done, all with at least one success
story within drm:

- Merge enough trees together until you have enough people capable to
doing maintainer duties for a triumvirate. That allows you to rotate,
arm-soc style. Rule of thumb is anything below 100 patches per release
cycle is probably too small, but you might need a lot more than that.
3 maintainers seems to be ideal.

- Intentionally abandon stuff. Sometimes no one else bothers to work
because the current maintainer is all over the place, does everything,
and suffocates any newbie's attempt to help out. Once something is
abandoned long enough it's either known to be dead, and not worth to
spend much time further maintaining. Or someone steps into the
intentionally created void and helps out.

- Make sure you have the smoothest ramp up from all stages of
contributing. bug report, first patch, oddball patch, first reviews,
then commit rights (first only for their own stuff, then maybe for
others), and so on. Any slightly elevated jump will mean people walk
away.

- Talk about the maintainer. If no one wants to help out, but it's a
generally active area, there's a problem. Fairly often it's a human
problem, and the maintainer is blind to their own short-comings. This
is very tricky, and requires enormous amounts of empathy and time, but
can be rectified.

Looking at drivers/rtc over the past 2-3 years it seems like a
decently active subsystem. Probably on the small side of things, but
not catastrophically so. But looking at contributor stats the picture
is totally different:

   241  Alexandre Belloni
    28  Linus Torvalds
    27  Arnd Bergmann
    25  Javier Martinez Canillas
    20  Uwe Kleine-König

That kind of skewed contribution statistics is indeed not sustainable,
and indicates some serious problem imo. What exactly goes wrong, and
how to best fix it I can't tell without more information though. From
my experience in drm, where we also have some areas with highly skewed
contribution statistics, it could be the maintainer driving people
away, ensuring that there's only one-off contributions. Usually
unkowningly.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Alexandre Belloni]

On 11/09/2018 15:35:38+0100, Mark Brown wrote:
> On Tue, Sep 11, 2018 at 02:44:23PM +0200, Alexandre Belloni wrote:
> > On 11/09/2018 00:44:57+0200, Daniel Vetter wrote:
> 
> > > gitlab (or well anything with a concept like pull requests) makes the
> > > 90% so much easier. And it doesn't take more work for contributors if
> > > you set things up right - it's just a git push instead of a git
> > > send-email. At least after initial setup is done.
> 
> > I would like to chime in and remind you that there are many subsystems
> > where you get a lot of drive-by contribution from random people. I'm
> > obviously thinking about rtc but I think this would also apply to codec,
> > IIO, power/supply, hwmon... In that case any initial setup would be
> > prohibitive.
> 
> Right, and this is also a potential issue for people working kernel wide
> if we end up with a bunch of different instances of gitlab or something
> similar.  
> 
> > So I need to emphasise that there are subsystem where people are not
> > backed by a company to contribute or review. What I often see is someone
> > having $random hardware and submitting a patch adding support for it.
> > That developer will definitively not review other patches because he has
> > no particular interest in them. He also probably doesn't have the
> > experience to do a review.
> 
> Even where people do have corporate backing for what they're doing
> they've often worked pretty hard to even get the time to do submissions,
> or they're doing it as a byproduct of whatever the "real" goal is.  It
> also reduces the impact from CI quite a bit if you've got lots of random
> drivers with most of the changes going in there, though it's still a win
> for the core and for any hardware which does manage to make it into a CI
> system.

Yes, that is also one of my points, I often get submission form people
getting the driver to work on a specific revision of the kernel (quite
often a vendor tree) and it is impossible to ask them to test changes on
later kernels because either they are not able to run a recent upstream
kernel or they already moved on and are not interested anymore.

I personally would rather not raise the bar for driver submission
but that also means that I have to make untested/unreviewed changes in
some of the drivers when refactoring.

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[Jiri Kosina]

On Mon, 10 Sep 2018, Linus Torvalds wrote:

> For example, we've had the "trivial tree", which tends to be a really 
> thankless project, that might well be managed way more easily by just 
> having a random tree that lots of people can commit to, and we could 
> even encourage the github (gitlab?) model of random non-kernel people 
> just sending their random trees to it, and have then the group of 
> committers be able to merge the changes (and at least on github, the 
> default merge is just a fast-forward, so it actually acts more like a 
> patch queue than a git tree).
> 
> And the reason I mention the trivial tree is not because the trivial
> tree itself is all that interesting or because I'd like to belittle
> that model ("that will only work for trivial unimportant stuff"), but
> because it might be a good area to experiment in, and a way to get
> people used to the flow.

For whatever that is worth -- I have had absolutely zero time to maintain 
that tree for past ~1 year, so I am open to any changes there that would 
make sense :)

Suggestions / help offers welcome.

Thanks,

-- 
Jiri Kosina
SUSE Labs

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

[Alexandre Belloni]

On 11/09/2018 17:02:31+0200, Daniel Vetter wrote:
> On Tue, Sep 11, 2018 at 2:44 PM, Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> > On 11/09/2018 00:44:57+0200, Daniel Vetter wrote:
> >> gitlab (or well anything with a concept like pull requests) makes the
> >> 90% so much easier. And it doesn't take more work for contributors if
> >> you set things up right - it's just a git push instead of a git
> >> send-email. At least after initial setup is done.
> >>
> >> And at least in a corporate environment (and I kinda have to care
> >> about that) gitlab wins on the initial setup front hands down against
> >> email. gitlab only needs https (even for git push/pull), and
> >> coproporate firewalls are pretty ok with https. They are not ok with
> >> smtp, like at all. And the amount of time we spend debugging random
> >> git send-email setup issues is epic.
> >>
> >
> > I would like to chime in and remind you that there are many subsystems
> > where you get a lot of drive-by contribution from random people. I'm
> > obviously thinking about rtc but I think this would also apply to codec,
> > IIO, power/supply, hwmon... In that case any initial setup would be
> > prohibitive.
> >
> > I feel like these subsystems are often left to the side when I read
> > threads like that talking about getting every patches reviewed, doing
> > more CI, etc...
> >
> > So I need to emphasise that there are subsystem where people are not
> > backed by a company to contribute or review. What I often see is someone
> > having $random hardware and submitting a patch adding support for it.
> > That developer will definitively not review other patches because he has
> > no particular interest in them. He also probably doesn't have the
> > experience to do a review.
> >
> > It is quite different from having a few big companies with huge teams
> > each maintaining a single driver in a subsystem... You simply can't have
> > the same expectations.
> 
> Yes drm has drm/i915 and drm/amdgpu. But reducing the graphics folks
> to these two big drivers with huge teams backing them, would be about
> the same as stating that linux only runs on x86 and arm. There's more.
> 
> And we do have quite serious problems with tiny boutique trees and
> drive-by contributors who immediately disappear. We're still trying to
> do our best to cope with that, which inolves lots of pain, and the
> occasional success.
> 
> Here's a bunch of things we've done, all with at least one success
> story within drm:
> 
> - Merge enough trees together until you have enough people capable to
> doing maintainer duties for a triumvirate. That allows you to rotate,
> arm-soc style. Rule of thumb is anything below 100 patches per release
> cycle is probably too small, but you might need a lot more than that.
> 3 maintainers seems to be ideal.
> 

I'm not sure what subsystem you would want to merge...

> - Intentionally abandon stuff. Sometimes no one else bothers to work
> because the current maintainer is all over the place, does everything,
> and suffocates any newbie's attempt to help out. Once something is
> abandoned long enough it's either known to be dead, and not worth to
> spend much time further maintaining. Or someone steps into the
> intentionally created void and helps out.

Well, that is exactly what I did, the RTC subsystem was left
unmaintained until I took the maintainership.

> - Make sure you have the smoothest ramp up from all stages of
> contributing. bug report, first patch, oddball patch, first reviews,
> then commit rights (first only for their own stuff, then maybe for
> others), and so on. Any slightly elevated jump will mean people walk
> away.
> 

And that is exactly what I want you to understand. There are still many
subsystem that don't spur enough interest to get people to work on it.
They submit a driver, it gets merged, it works and that's it.

Or maybe the subsystem is mostly complete and doesn't need more work
(how hard is it to give the date and time ?)

> - Talk about the maintainer. If no one wants to help out, but it's a
> generally active area, there's a problem. Fairly often it's a human
> problem, and the maintainer is blind to their own short-comings. This
> is very tricky, and requires enormous amounts of empathy and time, but
> can be rectified.
> 
> Looking at drivers/rtc over the past 2-3 years it seems like a
> decently active subsystem. Probably on the small side of things, but
> not catastrophically so. But looking at contributor stats the picture
> is totally different:
> 
>    241  Alexandre Belloni
>     28  Linus Torvalds
>     27  Arnd Bergmann
>     25  Javier Martinez Canillas
>     20  Uwe Kleine-König
> 
> That kind of skewed contribution statistics is indeed not sustainable,
> and indicates some serious problem imo. What exactly goes wrong, and
> how to best fix it I can't tell without more information though. From
> my experience in drm, where we also have some areas with highly skewed
> contribution statistics, it could be the maintainer driving people
> away, ensuring that there's only one-off contributions. Usually
> unkowningly.
> 

But your conclusion is really biased to only see what you want to see.
An RTC driver is simple enough to fit in a single patch and never need
any fix afterwards. And again, the typical contributor will submit only
one or two patches adding the driver he is interested in an move away.
Unlike DRM, there is a very small chance to get back to the driver to
fix issues afterwards. Anyone that got more than 1 patch in rtc already
contributed a lot.

I don't think there is anything to fix really, that is just the reality.
The driver is submitted, it works and continues to work, I'm not sure
what is wrong there.

I know that I drove someone away and I'm pretty sure it should be
handled better but honestly, it was a huge patch series mostly rewriting
one driver without adding features.

And you, probably not knowingly missed some pretty important
contributions from people that added features in the rtc core but that
usually adds up to 4-8 patches. Those were features that I was planning
to implement so this would qualify as success stories.

>From all the patches you see from me, many are cleaning up rtc drivers
after a long period of time without any RTC maintainer. I also own and
test most of the RTCs I'm working on.

Here are the stats for the RTC core from 4.4 to 4.18:
$ git shortlog --no-merges -s -n v4.4..v4.18 class.c hctosys.c interface.c nvmem.c systohc.c rtc-dev.c  rtc-proc.c rtc-sysfs.c
    19  Alexandre Belloni
     4  Baolin Wang
     3  Uwe Kleine-König
     2  Joshua Clayton
     2  LABBE Corentin
     2  Thomas Gleixner

Anyway, lets have a look at some numbers from DRM from 4.4 to 4.18:

$ git shortlog --no-merges -e -s -n v4.4..v4.18 drivers/gpu/drm/drm_*
   304  Daniel Vetter <daniel.vetter@ffwll.ch>
   138  Ville Syrjälä <ville.syrjala@linux.intel.com>
   113  Chris Wilson <chris@chris-wilson.co.uk>
    94  Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    44  Noralf Trønnes <noralf@tronnes.org>

Ok, so the core is still dominated by you. Not as much as RTC but in the
same order.

Lets have a look at DRM drivers (I'm taking a subset I hope is
representative):

             authored by     reviewed  by
driver       match others    match others  match on
amd          5961  622       6656  318     amd.com
atmel-hlcdc  18    68        3     41      maintainers
etnaviv      173   72        32    55      maintainers
exynos       225   173       41    80      samsung.com
hisilicon    11    75        12    66      maintainers
i915         6600  605       6029  831     intel.com + Chris
imx          35    125       1     50      maintainers
msm          380   176       31    92      maintainers + codeaurora
nouveau      938   362       21    193     maintainers + nvidia.com
omapdrm      278   282       56    188     ti.com
stm          29    16        18    18      maintainers
sun4i        154   120       53    50      maintainers
tegra        134   118       11    85      nvidia.com

Over the same timeframe, rtc has:
rtc          228   469       0     80      maintainers

This is how I interpret that:

Most of the drivers are developed by their maintainer or someone paid
by the vendor (which is basically the same because the maintainer is
actually getting paid to get his colleagues patches upstream).

I also see that the review numbers hint at biased reviews for the big
drivers as they are not coming from outsiders.

So what I see in DRM is exactly what you despis in other areas of the
kernel: mostly unreviewed maintainer self commits.

Obviously, for the smaller drivers, the numbers are not as critical
because they mostly see subsystem wide changes/refactoring.

So I still feel like RTC is at least as healthy as DRM because as you
can see, most of the patches are not coming from a maintainer (i.e. not
me).

Regards,

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[Guenter Roeck]

On Wed, Sep 12, 2018 at 12:00:47AM +0200, Alexandre Belloni wrote:
> > 
> > Looking at drivers/rtc over the past 2-3 years it seems like a
> > decently active subsystem. Probably on the small side of things, but
> > not catastrophically so. But looking at contributor stats the picture
> > is totally different:
> > 
> >    241  Alexandre Belloni
> >     28  Linus Torvalds
> >     27  Arnd Bergmann
> >     25  Javier Martinez Canillas
> >     20  Uwe Kleine-König
> > 
> > That kind of skewed contribution statistics is indeed not sustainable,
> > and indicates some serious problem imo. What exactly goes wrong, and
> > how to best fix it I can't tell without more information though. From
> > my experience in drm, where we also have some areas with highly skewed
> > contribution statistics, it could be the maintainer driving people
> > away, ensuring that there's only one-off contributions. Usually
> > unkowningly.
> > 

I have just seen this. I guess I must be driving _lots_ of people away.

git shortlog --no-merges -e -s -n v4.4..v4.18 drivers/watchdog 

   83	Guenter Roeck <linux@roeck-us.net>
   24	Wolfram Sang <wsa+renesas@sang-engineering.com>
   20	Damien Riegel <damien.riegel@savoirfairelinux.com>
   17	Arnd Bergmann <arnd@arndb.de>

git shortlog --no-merges -e -s -n v4.4..v4.18 drivers/hwmon

   157	Guenter Roeck <linux@roeck-us.net>
    70	Julia Lawall <Julia.Lawall@lip6.fr>
    23	Javier Martinez Canillas <javier@osg.samsung.com>
    10	Linus Walleij <linus.walleij@linaro.org>
    9	Pali Rohár <pali.rohar@gmail.com>

And there it was me erroneously thinking that this might be related to
me picking up subsystems for which there is not much interest, and to
doing a lot of cleanup in those subsystems in my non-existing spare
time. Bummer. Oh well, my apologies to everyone I have driven away.

Guenter

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

[Jani Nikula]

On Wed, 12 Sep 2018, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote:
> Most of the drivers are developed by their maintainer or someone paid
> by the vendor (which is basically the same because the maintainer is
> actually getting paid to get his colleagues patches upstream).
>
> I also see that the review numbers hint at biased reviews for the big
> drivers as they are not coming from outsiders.
>
> So what I see in DRM is exactly what you despis in other areas of the
> kernel: mostly unreviewed maintainer self commits.

I'll only speak for drm/i915 here as one of its maintainers, and I'll
steer clear of the preceding debate, but your conclusions don't hold
water wrt drm/i915.

Sure, most of the contributions, both patches and review, come from paid
Intel developers. It's a very busy driver. We pushed just under 8
commits per day on the average in the v4.4..v4.18 range. For reference,
that's 6.6% of all of drivers/. More than sound/, a bit less than fs/ or
net/ top level directories, but in the same ballpark.

By our rules, *nobody* gets to push unreviewed patches, and we follow
that religiously. The more complicated the patch, the more rigorous the
review must be, involving domain experts or generally more sets of eyes.

If we had to rely on outside reviews, either our rate of change would
grind to a halt, or we'd have to loosen our rules. Instead, we trust our
maintainers and committers to have the integrity to follow our
documented merge criteria. And bypassing the rules would be a fast lane
to losing the maintainer/committer status.

Anyone contributing to drm/i915 will tell you there are no biased
reviews. Some might say we are more gentle towards outside contributors
than our own. I'm also pretty confident you won't find examples of
unreviewed commits, let alone unreviewed maintainer self commits.


BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center

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

[Linus Walleij]

On Tue, Sep 11, 2018 at 5:02 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:

> - Merge enough trees together until you have enough people capable to
> doing maintainer duties for a triumvirate. That allows you to rotate,
> arm-soc style. Rule of thumb is anything below 100 patches per release
> cycle is probably too small, but you might need a lot more than that.
> 3 maintainers seems to be ideal.

This is the kind of rules of thumb we need to scale development
IMO. "My" subsystems (GPIO and pinctrl) is on some hard to define
threshold. I keep at it for now. Maybe I should just merge them
into one single tree to deliberately get a big enough mass to get
some group maintainership going.

> - Intentionally abandon stuff. Sometimes no one else bothers to work
> because the current maintainer is all over the place, does everything,
> and suffocates any newbie's attempt to help out.
(...)
> That kind of skewed contribution statistics is indeed not sustainable,
> and indicates some serious problem imo. What exactly goes wrong, and
> how to best fix it I can't tell without more information though. From
> my experience in drm, where we also have some areas with highly skewed
> contribution statistics, it could be the maintainer driving people
> away, ensuring that there's only one-off contributions. Usually
> unkowningly.

This problem is likely psychological and/or sociologial or even
ethnological rather than technical.

Despite several attempts of kernel maintainers to actively downplay
their role (Torvalds sets a good example in
Documentation/process/management-style.rst)
kernel maintainers are still perceived from the outside as some
kind of superior beings to which layperson developers feel
inferior to and look up to.

I think it's not an option to try to stop people from looking
up to kernel maintainers no matter how much we'd like that,
instead we need to assume the responsibility.

I do not know how to best deal with this, I guess maintainers
really need to watch their behaviors, but we would better ask
someone experienced in group dynamics what desirable
behaviors are.

If I take a guess I suspect the same qualities are desired for any
good leader or good parent: maintainers should have infinite
patience, infinite time to reply to questions (also infinitisemal
latency so they are always there!), recognize all their own
weaknesses and always say they are sorry when they have
been rude, be encouraging, sweet, nurturing, criticize in a
way that makes it clear that it is the performance not the person
that needs improvement, and throwing in some extra rewards
for desired behavior every now and then. (I think someone
mentioned a pareto ratio of 80% praise and 20% critique
is ideal, it's likely an unscientific rule of thumb.)

Needless to say no real person lives up to the above.
No parent does either. Some just fail less or in less obvious
ways.

I am worried that the intersection of the sets of people that
naturally have the desired personality traits and also are
reasonably good engineers is actually pretty small and that is
why we have a problem.

Yours,
Linus Walleij

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

[Alexandre Belloni]

On 12/09/2018 11:14:14+0200, Linus Walleij wrote:
> On Tue, Sep 11, 2018 at 5:02 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > That kind of skewed contribution statistics is indeed not sustainable,
> > and indicates some serious problem imo. What exactly goes wrong, and
> > how to best fix it I can't tell without more information though. From
> > my experience in drm, where we also have some areas with highly skewed
> > contribution statistics, it could be the maintainer driving people
> > away, ensuring that there's only one-off contributions. Usually
> > unkowningly.
> 
> This problem is likely psychological and/or sociologial or even
> ethnological rather than technical.
> 
> Despite several attempts of kernel maintainers to actively downplay
> their role (Torvalds sets a good example in
> Documentation/process/management-style.rst)
> kernel maintainers are still perceived from the outside as some
> kind of superior beings to which layperson developers feel
> inferior to and look up to.
> 
> I think it's not an option to try to stop people from looking
> up to kernel maintainers no matter how much we'd like that,
> instead we need to assume the responsibility.
> 
> I do not know how to best deal with this, I guess maintainers
> really need to watch their behaviors, but we would better ask
> someone experienced in group dynamics what desirable
> behaviors are.
> 
> If I take a guess I suspect the same qualities are desired for any
> good leader or good parent: maintainers should have infinite
> patience, infinite time to reply to questions (also infinitisemal
> latency so they are always there!), recognize all their own
> weaknesses and always say they are sorry when they have
> been rude, be encouraging, sweet, nurturing, criticize in a
> way that makes it clear that it is the performance not the person
> that needs improvement, and throwing in some extra rewards
> for desired behavior every now and then. (I think someone
> mentioned a pareto ratio of 80% praise and 20% critique
> is ideal, it's likely an unscientific rule of thumb.)
> 
> Needless to say no real person lives up to the above.
> No parent does either. Some just fail less or in less obvious
> ways.
> 
> I am worried that the intersection of the sets of people that
> naturally have the desired personality traits and also are
> reasonably good engineers is actually pretty small and that is
> why we have a problem.
> 

But is there really a problem to begin with? This is what Daniel wants
everybody to believe. He didn't scale in his own subsystem and basically
gave up reviewing drivers and this seems to be working fine for DRM.

But trying to impose that supposedly "new maintainership model" (again,
the numbers would indicate it is as hierarchical as any other part of
the kernel) to all the maintainers is quite far fetched. Many
maintainers are keeping up with their load and patches are getting
reviewed and applied.

I'm not saying there aren't any issues and that the level of reviews is
sufficient but I really don't think problematic maintainers are as
widespread as Daniel claims. It is really getting tiring to see him
show random statistics and draw wrong conclusions from them.

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[Thomas Gleixner]

On Wed, 12 Sep 2018, Alexandre Belloni wrote:
> On 12/09/2018 11:14:14+0200, Linus Walleij wrote:
> I'm not saying there aren't any issues and that the level of reviews is
> sufficient but I really don't think problematic maintainers are as
> widespread as Daniel claims. It is really getting tiring to see him
> show random statistics and draw wrong conclusions from them.

Agreed. Lies, damned lies and statistics...

The really interesting metric would be bugs/nr_commits. That gives you
valuable information how good your subsystem works and interacts with the
rest of the kernel.

But even then you need to be careful about analyzing the nature of the
bugs, which range between sloppy and incredibly unfortunate because subtle
interaction with changes outside of that maintainer tree brought the
carefully worked out patch into broken state.

Thanks,

	tglx

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

[Alexandre Belloni]

On 12/09/2018 11:42:53+0300, Jani Nikula wrote:
> On Wed, 12 Sep 2018, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote:
> > Most of the drivers are developed by their maintainer or someone paid
> > by the vendor (which is basically the same because the maintainer is
> > actually getting paid to get his colleagues patches upstream).
> >
> > I also see that the review numbers hint at biased reviews for the big
> > drivers as they are not coming from outsiders.
> >
> > So what I see in DRM is exactly what you despis in other areas of the
> > kernel: mostly unreviewed maintainer self commits.
> 
> I'll only speak for drm/i915 here as one of its maintainers, and I'll
> steer clear of the preceding debate, but your conclusions don't hold
> water wrt drm/i915.
> 
> Sure, most of the contributions, both patches and review, come from paid
> Intel developers. It's a very busy driver. We pushed just under 8
> commits per day on the average in the v4.4..v4.18 range. For reference,
> that's 6.6% of all of drivers/. More than sound/, a bit less than fs/ or
> net/ top level directories, but in the same ballpark.
> 
> By our rules, *nobody* gets to push unreviewed patches, and we follow
> that religiously. The more complicated the patch, the more rigorous the
> review must be, involving domain experts or generally more sets of eyes.
> 

I hope you do realise that we have to take your word for it because
there is no way to actually verify that claim. However, I'm all for
believing you. I'm just claiming that we can't actually know.

> If we had to rely on outside reviews, either our rate of change would
> grind to a halt,

Exactly, so I guess you can understand that this is basically not
something that you can ask in any other subsystem that has more than a
few drivers. There is simply no way to get outside reviews on drivers.

> or we'd have to loosen our rules. Instead, we trust our
> maintainers and committers to have the integrity to follow our
> documented merge criteria. And bypassing the rules would be a fast lane
> to losing the maintainer/committer status.
> 
> Anyone contributing to drm/i915 will tell you there are no biased
> reviews. Some might say we are more gentle towards outside contributors
> than our own. I'm also pretty confident you won't find examples of
> unreviewed commits, let alone unreviewed maintainer self commits.
> 

Again, this is a matter of trusting the coworkers reviews and I'm not
saying that they are not happening, I'm just saying we can't know.

Anyway, you are the ones maintaining your own driver and this is good,
this is simply what any maintainer should do. I'm pretty convinced that
you are careful to not break your own driver because that is your best
interest. And it seems that you are doing a good job as it has been a
while that I had issues with i915 (I wouldn't have said so two years
ago).

But again, I'm not sure this is the great success story Daniel claims it
is. I'm just seeing a maintainer that couldn't keep up with the number
of patches in his subsystem and created subsubsystems. And this is fine
because the subsubsystem maintainers have huge incentives to stay around
(the main one being that they are actually getting paid to do it).

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[Darren Hart]

On Mon, Sep 10, 2018 at 05:31:25PM +0200, Daniel Vetter wrote:
> I need to split this up, otherwise I'll get lost on the different
> sub-topics. I'll start with the easy ones.
> 
> On Mon, Sep 10, 2018 at 4:53 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >> Specific topics I'm interested in:
> >> - New experiments in group maintainership, and sharing lessons learned
> >> in general.
> >
> > I think that's good. But again, partly because these kinds of subjects
> > tend to devolve into too much of a generic overview, may I suggest
> > again trying to make things very concrete.
> >
> > For example, talk about the actual tools you use. Make it tangible. A
> > couple of years ago the ARM people talked about the way they split
> > their time to avoid stepping on each other (both in timezones, but
> > also in how they pass the baton around in general, in addition to
> > using branches).
> >
> > And yes, a lot of it probably ends up being "we didn't actually make
> > this official or write it up, but we worked enough together that we
> > ended up doing XYZ". That's fine. That's how real flows develop. With
> > discussion of what the problems were, and what this solved.
> >
> > In other words, make it down to earth. Not the "visionary keynote",
> > but the "this is the everyday flow".
> 
> Yup, fully agreed. We don't need another overview over group
> maintainer ship. Also I don't think an update from arm-soc/tip or drm
> is interesting either. I think only if there's a new group/subsystem
> trying this out, with all the nitty-gritty details of "this totally
> blew up in our faces" and "this worked shockingly well" and "here we
> need to improve still, we're not happy" is what I'm looking for.
> Without those details there's nothing really to learn, beyond just
> rehashing one of the old discussions. I guess I should have put more
> emphasis on _new_ experiments :-)
> 
> And if nothing changed, no new groups I think think we should table
> this right away.

For x86 platform drivers, Andy and I raised a few issues a while back
regarding some of the new tests added to -next which broke our process.
We discussed those in some detail back then, but I think the general
case that much of our process seems to assume a single maintainer. We
have put some fences in place to work around this, but they are rather
fragile. We don't have a combined testing branch anymore (but I think we
should). If we catch a bug in a commit far enough back in the history of
a "published" branch that we have both committed on top of it, it's a
major logistical pain to get back to good.

Regarding tooling, Andy and I have documented our process and shared our
tooling which has evolved to try and prevent human error. I believe DRM
has something even more evolved.

https://github.com/dvhart/pdx86-tools

For us, most of the patches we receive are one-offs to fix a specific
laptop. I expect these could work just fine from a GitHub workflow
and would help bridge the gap between all the people filing bugs in
bugzilla and the people submitting patches to LKML. With something like
GitHub, I think it's possible more of the bug reporters would consider
submitting fixes - even if Andy and I had to do a bit more work to get
them merged.

The question here is: how do we ensure patches submitted via
github/gitlab are also sent to LKML and to bridge the reviewers there
with the authors. Some kind of a bridge/gateway seems doable, but I'd
want this to be a broader effort than just our subsystem to make it
worthwhile - as well as socialize it sufficiently that the initial
glitches are anticipated and dealt with constructively.

-- 
Darren Hart
VMware Open Source Technology Center

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

[Darren Hart]

On Mon, Sep 10, 2018 at 07:10:58PM +0200, Daniel Vetter wrote:
> On Mon, Sep 10, 2018 at 6:39 PM, Olof Johansson <olof@lixom.net> wrote:
> > On Mon, Sep 10, 2018 at 8:31 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
...
> > I'm super excited to hear a bit about the _actual_ plans of gitlab
> > move. As mentioned, not a visionary keynote, but others also talking
> > about what they're looking at to fix their current pain points.
> 
> It's the topic in the other thread, so hooray for chaos, but don't
> worry: I plan to make the talk as concrete as possible for a "we're
> planning this" talk. Rought structure I have in mind:
> - short overview of why fd.o admins want to switch and why, with a bit
> of history on how drm is influenced from both kernel and userspace
> alike.
> - going through our current pain points, and how we think some gitlab
> concepts could help. I hope that a bunch of things will be concrete
> already here, using some of our userspace repos like the test-suite as
> guinea pigs.
> - the epic long lists of issues and infrastructure we're seeing
> already in case we want to actually follow through on any of this.
> Plus a request for "what did we miss?".
> 
> It's definitely not going to be your inspirational keynote thing about
> how awesome community management is, ks is the wrong place for that
> :-)

This sounds really useful to me.

-- 
Darren Hart
VMware Open Source Technology Center

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

[Dave Airlie]

On Thu, 13 Sep 2018 at 04:46, Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
>
> On 12/09/2018 11:42:53+0300, Jani Nikula wrote:
> > On Wed, 12 Sep 2018, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote:
> > > Most of the drivers are developed by their maintainer or someone paid
> > > by the vendor (which is basically the same because the maintainer is
> > > actually getting paid to get his colleagues patches upstream).
> > >
> > > I also see that the review numbers hint at biased reviews for the big
> > > drivers as they are not coming from outsiders.
> > >
> > > So what I see in DRM is exactly what you despis in other areas of the
> > > kernel: mostly unreviewed maintainer self commits.
> >
> > I'll only speak for drm/i915 here as one of its maintainers, and I'll
> > steer clear of the preceding debate, but your conclusions don't hold
> > water wrt drm/i915.
> >
> > Sure, most of the contributions, both patches and review, come from paid
> > Intel developers. It's a very busy driver. We pushed just under 8
> > commits per day on the average in the v4.4..v4.18 range. For reference,
> > that's 6.6% of all of drivers/. More than sound/, a bit less than fs/ or
> > net/ top level directories, but in the same ballpark.
> >
> > By our rules, *nobody* gets to push unreviewed patches, and we follow
> > that religiously. The more complicated the patch, the more rigorous the
> > review must be, involving domain experts or generally more sets of eyes.
> >
>
> I hope you do realise that we have to take your word for it because
> there is no way to actually verify that claim. However, I'm all for
> believing you. I'm just claiming that we can't actually know.
>

All the i915 review is done in public on the intel-gfx mailing list,
I've insisted that AMD do the same on their amd-gfx list. I also do
some spot checks that nothing is sneaking past and that review is more
than just rubber stamping at least where it matters.

So yes you can know.

Dave.

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

[Daniel Vetter]

On Wed, Sep 12, 2018 at 8:59 PM, Darren Hart <dvhart@infradead.org> wrote:
> On Mon, Sep 10, 2018 at 05:31:25PM +0200, Daniel Vetter wrote:
>> I need to split this up, otherwise I'll get lost on the different
>> sub-topics. I'll start with the easy ones.
>>
>> On Mon, Sep 10, 2018 at 4:53 PM, Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:
>> >> Specific topics I'm interested in:
>> >> - New experiments in group maintainership, and sharing lessons learned
>> >> in general.
>> >
>> > I think that's good. But again, partly because these kinds of subjects
>> > tend to devolve into too much of a generic overview, may I suggest
>> > again trying to make things very concrete.
>> >
>> > For example, talk about the actual tools you use. Make it tangible. A
>> > couple of years ago the ARM people talked about the way they split
>> > their time to avoid stepping on each other (both in timezones, but
>> > also in how they pass the baton around in general, in addition to
>> > using branches).
>> >
>> > And yes, a lot of it probably ends up being "we didn't actually make
>> > this official or write it up, but we worked enough together that we
>> > ended up doing XYZ". That's fine. That's how real flows develop. With
>> > discussion of what the problems were, and what this solved.
>> >
>> > In other words, make it down to earth. Not the "visionary keynote",
>> > but the "this is the everyday flow".
>>
>> Yup, fully agreed. We don't need another overview over group
>> maintainer ship. Also I don't think an update from arm-soc/tip or drm
>> is interesting either. I think only if there's a new group/subsystem
>> trying this out, with all the nitty-gritty details of "this totally
>> blew up in our faces" and "this worked shockingly well" and "here we
>> need to improve still, we're not happy" is what I'm looking for.
>> Without those details there's nothing really to learn, beyond just
>> rehashing one of the old discussions. I guess I should have put more
>> emphasis on _new_ experiments :-)
>>
>> And if nothing changed, no new groups I think think we should table
>> this right away.
>
> For x86 platform drivers, Andy and I raised a few issues a while back
> regarding some of the new tests added to -next which broke our process.
> We discussed those in some detail back then, but I think the general
> case that much of our process seems to assume a single maintainer. We
> have put some fences in place to work around this, but they are rather
> fragile. We don't have a combined testing branch anymore (but I think we
> should). If we catch a bug in a commit far enough back in the history of
> a "published" branch that we have both committed on top of it, it's a
> major logistical pain to get back to good.
>
> Regarding tooling, Andy and I have documented our process and shared our
> tooling which has evolved to try and prevent human error. I believe DRM
> has something even more evolved.
>
> https://github.com/dvhart/pdx86-tools

Hm, the gen-config scrips looks like a really neat idea. Atm we
manually maintain some configs for all the drm drivers, but this is
much better I think. Next step up would be to double-check that make
oldconfig didn't disable any of the options we want. I think this
would even be useful in upstream, if you can give it Kconfig files or
entire directories it's supposed to search for, and enable everything
in there.

Bit of googling and fooling around says make CONFIG_FOO=y olddefconfig
seems to do this, including enabling (all?) dependencies you need.

> For us, most of the patches we receive are one-offs to fix a specific
> laptop. I expect these could work just fine from a GitHub workflow
> and would help bridge the gap between all the people filing bugs in
> bugzilla and the people submitting patches to LKML. With something like
> GitHub, I think it's possible more of the bug reporters would consider
> submitting fixes - even if Andy and I had to do a bit more work to get
> them merged.

Get travis CI to run the checks for you and dump results into pull
requests. That's at least the plan we have on the gitlab side.
Everytime you see the same screw up 10 times, you add another check to
your scipts.

I haven't tried whether this works in practices for kernel stuff, and
how much work it is. But the concept is used to great success in other
communities. Think instead of just documentation where you have to
help new contributors to find all the bits (they're there, but the
kernel docs are huge, so finding everything is tricky), you have
interactive docs where bots walk first contributors through
everything.

E.g. forgot sob line -> bot gives you a link to the docs where sob is explained.

Some of these could be upstreamed to checkpatch I think, but you'd
probably still need some glue to extract the links/help texts and put
it at the right place in the pull request. E.g. anything coding style
related should ideally be a review comment added at exactly the right
spot.

> The question here is: how do we ensure patches submitted via
> github/gitlab are also sent to LKML and to bridge the reviewers there
> with the authors. Some kind of a bridge/gateway seems doable, but I'd
> want this to be a broader effort than just our subsystem to make it
> worthwhile - as well as socialize it sufficiently that the initial
> glitches are anticipated and dealt with constructively.

There are gateways (afaick), but generally those gateways are not
enthusiastic about spamming random people you just add to the Cc: list
of a patch. Definitely not on github - github doesn't want to be a
spam relay. On self-hosted stuff like gitlab this might be possible,
but I've honestly not tried this out yet.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Darren Hart]

On Wed, Sep 12, 2018 at 10:05:19PM +0200, Daniel Vetter wrote:
> On Wed, Sep 12, 2018 at 8:59 PM, Darren Hart <dvhart@infradead.org> wrote:
> > On Mon, Sep 10, 2018 at 05:31:25PM +0200, Daniel Vetter wrote:
> >> I need to split this up, otherwise I'll get lost on the different
> >> sub-topics. I'll start with the easy ones.
> >>
> >> On Mon, Sep 10, 2018 at 4:53 PM, Linus Torvalds
> >> <torvalds@linux-foundation.org> wrote:
> >> >> Specific topics I'm interested in:
> >> >> - New experiments in group maintainership, and sharing lessons learned
> >> >> in general.
> >> >
> >> > I think that's good. But again, partly because these kinds of subjects
> >> > tend to devolve into too much of a generic overview, may I suggest
> >> > again trying to make things very concrete.
> >> >
> >> > For example, talk about the actual tools you use. Make it tangible. A
> >> > couple of years ago the ARM people talked about the way they split
> >> > their time to avoid stepping on each other (both in timezones, but
> >> > also in how they pass the baton around in general, in addition to
> >> > using branches).
> >> >
> >> > And yes, a lot of it probably ends up being "we didn't actually make
> >> > this official or write it up, but we worked enough together that we
> >> > ended up doing XYZ". That's fine. That's how real flows develop. With
> >> > discussion of what the problems were, and what this solved.
> >> >
> >> > In other words, make it down to earth. Not the "visionary keynote",
> >> > but the "this is the everyday flow".
> >>
> >> Yup, fully agreed. We don't need another overview over group
> >> maintainer ship. Also I don't think an update from arm-soc/tip or drm
> >> is interesting either. I think only if there's a new group/subsystem
> >> trying this out, with all the nitty-gritty details of "this totally
> >> blew up in our faces" and "this worked shockingly well" and "here we
> >> need to improve still, we're not happy" is what I'm looking for.
> >> Without those details there's nothing really to learn, beyond just
> >> rehashing one of the old discussions. I guess I should have put more
> >> emphasis on _new_ experiments :-)
> >>
> >> And if nothing changed, no new groups I think think we should table
> >> this right away.
> >
> > For x86 platform drivers, Andy and I raised a few issues a while back
> > regarding some of the new tests added to -next which broke our process.
> > We discussed those in some detail back then, but I think the general
> > case that much of our process seems to assume a single maintainer. We
> > have put some fences in place to work around this, but they are rather
> > fragile. We don't have a combined testing branch anymore (but I think we
> > should). If we catch a bug in a commit far enough back in the history of
> > a "published" branch that we have both committed on top of it, it's a
> > major logistical pain to get back to good.
> >
> > Regarding tooling, Andy and I have documented our process and shared our
> > tooling which has evolved to try and prevent human error. I believe DRM
> > has something even more evolved.
> >
> > https://github.com/dvhart/pdx86-tools
> 
> Hm, the gen-config scrips looks like a really neat idea. Atm we
> manually maintain some configs for all the drm drivers, but this is
> much better I think. Next step up would be to double-check that make
> oldconfig didn't disable any of the options we want. I think this

The merge-config script reports on this when you include a .config, e.g.

$ make defconfig pdx86.config


> would even be useful in upstream, if you can give it Kconfig files or
> entire directories it's supposed to search for, and enable everything
> in there.
> 
> Bit of googling and fooling around says make CONFIG_FOO=y olddefconfig
> seems to do this, including enabling (all?) dependencies you need.

I'm working on config fragment howto talk for OSS EU which I hope to
include some targeted config fuzz testing in. I hope to have a more
fleshed out story on how work with this by then.

> > For us, most of the patches we receive are one-offs to fix a specific
> > laptop. I expect these could work just fine from a GitHub workflow
> > and would help bridge the gap between all the people filing bugs in
> > bugzilla and the people submitting patches to LKML. With something like
> > GitHub, I think it's possible more of the bug reporters would consider
> > submitting fixes - even if Andy and I had to do a bit more work to get
> > them merged.
> 
> Get travis CI to run the checks for you and dump results into pull
> requests. That's at least the plan we have on the gitlab side.
> Everytime you see the same screw up 10 times, you add another check to
> your scipts.
> 
> I haven't tried whether this works in practices for kernel stuff, and
> how much work it is. But the concept is used to great success in other
> communities. Think instead of just documentation where you have to
> help new contributors to find all the bits (they're there, but the
> kernel docs are huge, so finding everything is tricky), you have
> interactive docs where bots walk first contributors through
> everything.
> 
> E.g. forgot sob line -> bot gives you a link to the docs where sob is explained.

Agree - this idea has been circling around with a number of people
generally supporting the idea, but none of us has made the time to try
it yet. I'd be interested in a set of subsystem maintainers willing to
collaborate and try it out.

> 
> Some of these could be upstreamed to checkpatch I think, but you'd
> probably still need some glue to extract the links/help texts and put
> it at the right place in the pull request. E.g. anything coding style
> related should ideally be a review comment added at exactly the right
> spot.
> 
> > The question here is: how do we ensure patches submitted via
> > github/gitlab are also sent to LKML and to bridge the reviewers there
> > with the authors. Some kind of a bridge/gateway seems doable, but I'd
> > want this to be a broader effort than just our subsystem to make it
> > worthwhile - as well as socialize it sufficiently that the initial
> > glitches are anticipated and dealt with constructively.
> 
> There are gateways (afaick), but generally those gateways are not
> enthusiastic about spamming random people you just add to the Cc: list
> of a patch. Definitely not on github - github doesn't want to be a
> spam relay. On self-hosted stuff like gitlab this might be possible,
> but I've honestly not tried this out yet.
> 
> Cheers, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> 

-- 
Darren Hart
VMware Open Source Technology Center

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

[Linus Walleij]

On Wed, Sep 12, 2018 at 8:23 PM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> [Me]
> > I am worried that the intersection of the sets of people that
> > naturally have the desired personality traits and also are
> > reasonably good engineers is actually pretty small and that is
> > why we have a problem.
>
> But is there really a problem to begin with? This is what Daniel wants
> everybody to believe. He didn't scale in his own subsystem and basically
> gave up reviewing drivers and this seems to be working fine for DRM.

To me the problem is recruiting active maintainers, and not the formal
title and the entry in MAINTAINERS, but one that actually feels
responsibility for the code. Some have appeared in the past, they
make some really nice contributions and then move on.

But it is a bit like solar flares, I just don't know when they will turn
up next and what makes them passionate and stay or when they
leave.

The upside (IMO) of DRMs model is that more people feel resonsible
for the code. The downside is the risk that no-one does, and everyone
just thinks someone else will do stuff. They seem to land on the plus
so far.

Yours,
Linus Walleij

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

[Daniel Vetter]

On Wed, Sep 12, 2018 at 8:45 PM, Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> On 12/09/2018 11:42:53+0300, Jani Nikula wrote:
>> On Wed, 12 Sep 2018, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote:
>> > Most of the drivers are developed by their maintainer or someone paid
>> > by the vendor (which is basically the same because the maintainer is
>> > actually getting paid to get his colleagues patches upstream).
>> >
>> > I also see that the review numbers hint at biased reviews for the big
>> > drivers as they are not coming from outsiders.
>> >
>> > So what I see in DRM is exactly what you despis in other areas of the
>> > kernel: mostly unreviewed maintainer self commits.
>>
>> I'll only speak for drm/i915 here as one of its maintainers, and I'll
>> steer clear of the preceding debate, but your conclusions don't hold
>> water wrt drm/i915.
>>
>> Sure, most of the contributions, both patches and review, come from paid
>> Intel developers. It's a very busy driver. We pushed just under 8
>> commits per day on the average in the v4.4..v4.18 range. For reference,
>> that's 6.6% of all of drivers/. More than sound/, a bit less than fs/ or
>> net/ top level directories, but in the same ballpark.
>>
>> By our rules, *nobody* gets to push unreviewed patches, and we follow
>> that religiously. The more complicated the patch, the more rigorous the
>> review must be, involving domain experts or generally more sets of eyes.
>>
>
> I hope you do realise that we have to take your word for it because
> there is no way to actually verify that claim. However, I'm all for
> believing you. I'm just claiming that we can't actually know.
>
>> If we had to rely on outside reviews, either our rate of change would
>> grind to a halt,
>
> Exactly, so I guess you can understand that this is basically not
> something that you can ask in any other subsystem that has more than a
> few drivers. There is simply no way to get outside reviews on drivers.

I got bored, counted all the drivers in drm, it's about 100. So not
quite yet where rtc is, but we're getting there. Smallest of these is
just shy of 300 lines of code. Not quite as small as the smallest rtc
driver I agree, but compared to drm/amdgpu a rounding error in
difference really.

So yeah maybe it's all fake review that we're doing, and that's why
it's impossible.
-Daniel


>> or we'd have to loosen our rules. Instead, we trust our
>> maintainers and committers to have the integrity to follow our
>> documented merge criteria. And bypassing the rules would be a fast lane
>> to losing the maintainer/committer status.
>>
>> Anyone contributing to drm/i915 will tell you there are no biased
>> reviews. Some might say we are more gentle towards outside contributors
>> than our own. I'm also pretty confident you won't find examples of
>> unreviewed commits, let alone unreviewed maintainer self commits.
>>
>
> Again, this is a matter of trusting the coworkers reviews and I'm not
> saying that they are not happening, I'm just saying we can't know.
>
> Anyway, you are the ones maintaining your own driver and this is good,
> this is simply what any maintainer should do. I'm pretty convinced that
> you are careful to not break your own driver because that is your best
> interest. And it seems that you are doing a good job as it has been a
> while that I had issues with i915 (I wouldn't have said so two years
> ago).
>
> But again, I'm not sure this is the great success story Daniel claims it
> is. I'm just seeing a maintainer that couldn't keep up with the number
> of patches in his subsystem and created subsubsystems. And this is fine
> because the subsubsystem maintainers have huge incentives to stay around
> (the main one being that they are actually getting paid to do it).
>
> --
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Laurent Pinchart]

Hi Daniel,

On Tuesday, 11 September 2018 01:44:57 EEST Daniel Vetter wrote:
> On Mon, Sep 10, 2018 at 11:33 PM, Laurent Pinchart wrote:
> > On Monday, 10 September 2018 23:55:22 EEST Daniel Vetter wrote:
> >> On Mon, Sep 10, 2018 at 10:32 PM, Laurent Pinchart wrote:
> >>> On Monday, 10 September 2018 18:56:18 EEST Daniel Vetter wrote:
> >>>> My goal at least with this is much more in figuring out new workflows,
> >>>> and running a pile of experiments. As mentioned, we don't yet even
> >>>> have a plan for all this, the goal here is to spark some discussions
> >>>> and figure out whether maybe others want to come along for the ride.
> >>> 
> >>> I recently had to deal with a new bugs and tasks management tool that
> >>> was developed in-house by a customer of mine. The tool was presented to
> >>> us in its first RFC version (and in source code form, which is very
> >>> nice), with very few implemented features, and without telling us what
> >>> process it was supposed to support. When I inquired I got told that the
> >>> process hasn't been taken into consideration to develop the tool, and
> >>> that it would just come into existence as a result of the tool. Needless
> >>> to say, it was hard for me to review the code, without knowing what it
> >>> was supposed to do.
> >>> 
> >>> I don't claim we're going to that extreme, but I believe it would be
> >>> useful to detail the problems we have in order to find solutions,
> >>> instead of proposing solutions and then trying to retrofit them to
> >>> problems.
> >> 
> >> We're definitely starting with some pain points, and don't do this
> >> gitlab thing as an a solution looking desperately for a problem. With
> >> my intel hat on there's a few main ones:
> >> 
> >> - CI integration with patchwork is a pain, for developers, maintainers
> >> and CI people all alike. I plan to do some slides on what exactly
> >> sucks and what gitlab is doing better, but I'm just not quite there
> >> yet. As mentioned somewhere else, ideally we'd have the full demo
> >> ready for LPC using the userspace igt gpu tests repo.
> > 
> > I'm interested in knowing whether you think this is due to the concept
> > behind patchwork, or to the current implementation. I like the idea of
> > patchwork as a tool that assists an email-based workflow in areas where
> > emails are too limited. I think we could do much more, and I believe we
> > could achieve a good result, while keeping the same philosophy.
> 
> The problem with patchwork is that it's a sidelined add-on. It's not
> in your face when doing a normal contribution. Our patchwork tries to
> fix that by sending replies to the mailing lists, but to avoid spam,
> it only does that when CI is done. While it's still crunching through
> your series you have to know a magic link where you can watch it go
> through it's backlog. We could update more often, but people already
> complain about the spam our CI produces.
> 
> gitlab otoh gives you a neat status indicator, and direct links where
> you can watch it do its thing live. All neatly integrated into the one
> merge request interface.
> 
> Now if you've never done CI before, you'll probably go meh on this.
> But the trick in making CI really effective is to make it about as
> addictive as a slot machine. Instant gratification and quick results
> is absolutely key, and developers want to watch it do its things. The
> more you can give them that, the more your developers will care about
> CI results (the green checkmark quickly starts to look like candy in
> your eyes), and the less maintainers have to check this themselves.
> 
> There's a bunch of other things, like integration with the git side of
> things (you can block a merge if it fails CI). So the above is the
> contributor/maintainer perspective.
> 
> The CI perspective is that the guy maintaining patchwork for us would
> like to do more useful things than maintain a pile of duct-tape :-)
> The fully integrated REST api of gitlab is pretty good catnip for
> devops types.

I understand you point, and I'll claim you could do all this using patchwork 
too :-) Of course the amount of development would very well be prohibitive, 
and I'm not advocating for that.

On a more serious note, maybe our disagreement comes (partly) from not having 
defined which feature(s) of gitlab you would like to use. The CI 
infrastructure, as in taking a branch, running tests on it, reporting results, 
and offering a web dashboard (as long as it remains optional), seems totally 
fine with me. Pushing to branches with particular names/paths instead of 
issuing a pull request by e-mail, if it helps the CI system figuring out what 
to test and when, is something I wouldn't oppose either (provided the push 
would send a mail to appropriate mailing lists to notify everybody of pull 
requests, possibly formatted the same way as a git request-pull).

Regardless of how our tool is named, I'd like it to offer e-mail integration

- In the incoming direction (as patchwork does), as there will always be 
patches submitted by e-mail. Compared to commits pushed to a git tree, patch 
series submitted by e-mail may make it more difficult to extract some context 
information (heuristics would likely be needed to track multiple versions of 
the same series for instance), and some information might not be available at 
all, so we might not be able to offer the same level of integration in that 
case, but we should do as much as we can.

We may also try to standardize the formatting of information in patches or 
cover letters to ease the task for our tools (for instance a standard way to 
tell which branch a patch series is based on could be useful). I however don't 
want to make it more difficult than it is already to submit patches by e-mail.

- In the outgoing direction, as operations directly performed through git 
(e.g. pull requests, and possibly merges, as a reply to the pull request e-
mail) should be reflected on mailing list to inform all developers, and to 
retain history. Given how much information many developers have to filter, 
require information to be pulled from a web interface will simply not work, it 
has to be pushed through a mean that will ensure that the audience is reached.

> >> - First contributor flow can be (if done correctly) so much more fun
> >> than mailing lists. There's been a bit of chatting on this already in
> >> this thread.
> > 
> > I recall lots of frustration from regular contributors during a discussion
> > about kernel maintainership, where many considered that we went to
> > extremes to help first contributors, while very little was done to
> > address the issues of regular contributors. Let's keep both sides in
> > mind, otherwise we'll end up moving our development process to instagram
> > because, you know, that's where the new generation is, people don't use
> > e-mails anymore.
> 
> First contributors aren't your antagonists, they're your canaries for
> bad process. Long timers just suck it up (or don't even see it
> anymore), first timers don't even bother because the hurdle is
> insurmountable. And yes sometimes it's the other way round, were
> problems really show up at scale, but only hurt a bit on the very
> first patch. The goal, at least mine, is to make it easier for
> everyone, at all levels of experience&contribution.

I've replied to my own comment separately, I believe we're in agreement here.

> >> - Tracking patch series as they evolve from RFC to final reviewed
> >> version. Patchwork, even with all the extensions we have since years
> >> in the fd.o one, just can't cope. This might be an artifact of our
> >> group maintainership + committer model, I think for single maintainer
> >> patchwork does work a bit better. This is the "patches on mailing
> >> lists don't scale, I have the T-shirt" problem Linus already
> >> mentioned. Our PMs/managers also don't like that they can't keep track
> >> of what the fairly big drm/i915 team is doing :-)
> > 
> > I've pointed out the issue that patch series don't always have fixed
> > boundaries in another reply to this thread, and I think that's the core
> > reason why this problem isn't solvable. We should have a working solution
> > for the common case though, and I fail to see why a tool like patchwork
> > couldn't do it (not claiming it does at the moment of course).
> 
> gitlab (or well anything with a concept like pull requests) makes the
> 90% so much easier. And it doesn't take more work for contributors if
> you set things up right - it's just a git push instead of a git
> send-email. At least after initial setup is done.

Replacing a git send-email with a git push wouldn't be an issue for me as long 
as we address the requirements listed above. What would be an absolute no-go 
for me would be patch (and pull requests) review over a web interface.

> And at least in a corporate environment (and I kinda have to care
> about that) gitlab wins on the initial setup front hands down against
> email. gitlab only needs https (even for git push/pull), and
> coproporate firewalls are pretty ok with https. They are not ok with
> smtp, like at all. And the amount of time we spend debugging random
> git send-email setup issues is epic.

How far do we want to go to make obnoxious and clueless IT departments happy ? 
What about corporate environments where a proxy server intercepts even https 
traffic, with custom certificates installed on all machines, which is 
unfortunately not that uncommon ? I personally wouldn't trust such an 
environment, so we have to set a firm limit somewhere in any case.

> There's alwasy going to be the thing where you have to split up a
> patch series into multiple patch series, or merge a few. And then you
> need to manually add links to the other/past discussions in either
> system.

Yes, manual intervention will sometimes be needed, and regardless of the tool 
we use that will require a bit of work on the submitter's side, but I think 
that's doable.

> The gitlab plaintext syntax for auto-closing/linking other issues and merge
> requests is pretty good, whereas emails it's all colating web links and msg-
> id, which at least I personally fine a chore and so almost never bother
> with.

Let's not forget that gitlab instances, like git trees, won't be there 
forever, they will likely come and go. We should link information in a way 
that will survive that.

-- 
Regards,

Laurent Pinchart

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

[Theodore Y. Ts'o]

On Mon, Sep 10, 2018 at 05:31:25PM +0200, Daniel Vetter wrote:
> 
> Yup, fully agreed. We don't need another overview over group
> maintainer ship. Also I don't think an update from arm-soc/tip or drm
> is interesting either. I think only if there's a new group/subsystem
> trying this out, with all the nitty-gritty details of "this totally
> blew up in our faces" and "this worked shockingly well" and "here we
> need to improve still, we're not happy" is what I'm looking for.
> Without those details there's nothing really to learn, beyond just
> rehashing one of the old discussions. I guess I should have put more
> emphasis on _new_ experiments :-)
> 
> And if nothing changed, no new groups I think think we should table
> this right away.

I wonder if this is something that would be better done at the Kernel
Summit (e.g., in Vancouver), as a discussion session.  It's important
to remember that Maintainer's Summit has (by design) a small number of
attendees.  If the goal is to compare notes about various experiments,
it's likely there will be many kernel developers present in Vancouver.
After all, getting input from just "Maintainers" but all developers
participating in development process would be valuable.

						- Ted

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

[Daniel Vetter]

On Thu, Sep 13, 2018 at 4:56 AM, Theodore Y. Ts'o <tytso@mit.edu> wrote:
> On Mon, Sep 10, 2018 at 05:31:25PM +0200, Daniel Vetter wrote:
>>
>> Yup, fully agreed. We don't need another overview over group
>> maintainer ship. Also I don't think an update from arm-soc/tip or drm
>> is interesting either. I think only if there's a new group/subsystem
>> trying this out, with all the nitty-gritty details of "this totally
>> blew up in our faces" and "this worked shockingly well" and "here we
>> need to improve still, we're not happy" is what I'm looking for.
>> Without those details there's nothing really to learn, beyond just
>> rehashing one of the old discussions. I guess I should have put more
>> emphasis on _new_ experiments :-)
>>
>> And if nothing changed, no new groups I think think we should table
>> this right away.
>
> I wonder if this is something that would be better done at the Kernel
> Summit (e.g., in Vancouver), as a discussion session.  It's important
> to remember that Maintainer's Summit has (by design) a small number of
> attendees.  If the goal is to compare notes about various experiments,
> it's likely there will be many kernel developers present in Vancouver.
> After all, getting input from just "Maintainers" but all developers
> participating in development process would be valuable.

Yes, that was at least my idea for all of these topics. I wasn't sure
what label to pick since it's not really a tech topic either.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]

On Wed, Sep 12, 2018 at 10:05:19PM +0200, Daniel Vetter wrote:
> On Wed, Sep 12, 2018 at 8:59 PM, Darren Hart <dvhart@infradead.org> wrote:

> > Regarding tooling, Andy and I have documented our process and shared our
> > tooling which has evolved to try and prevent human error. I believe DRM
> > has something even more evolved.

> > https://github.com/dvhart/pdx86-tools

> Hm, the gen-config scrips looks like a really neat idea. Atm we
> manually maintain some configs for all the drm drivers, but this is
> much better I think. Next step up would be to double-check that make

Yes, I've got a script like that as well (mine's a *tiny* bit less
sophisticated) - it's super handy if you frequently add new drivers.

> Bit of googling and fooling around says make CONFIG_FOO=y olddefconfig
> seems to do this, including enabling (all?) dependencies you need.

That only works for dependencies that are selected, if there's a config
option that stops CONFIG_FOO being seen by the user (eg, having MFD_FOO
preventing SUBSYSTEM_FOO being enabled) then it'll just get silently
ignored.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Daniel Vetter]

On Thu, Sep 13, 2018 at 1:27 PM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, Sep 12, 2018 at 10:05:19PM +0200, Daniel Vetter wrote:
>> On Wed, Sep 12, 2018 at 8:59 PM, Darren Hart <dvhart@infradead.org> wrote:
>
>> > Regarding tooling, Andy and I have documented our process and shared our
>> > tooling which has evolved to try and prevent human error. I believe DRM
>> > has something even more evolved.
>
>> > https://github.com/dvhart/pdx86-tools
>
>> Hm, the gen-config scrips looks like a really neat idea. Atm we
>> manually maintain some configs for all the drm drivers, but this is
>> much better I think. Next step up would be to double-check that make
>
> Yes, I've got a script like that as well (mine's a *tiny* bit less
> sophisticated) - it's super handy if you frequently add new drivers.
>
>> Bit of googling and fooling around says make CONFIG_FOO=y olddefconfig
>> seems to do this, including enabling (all?) dependencies you need.
>
> That only works for dependencies that are selected, if there's a config
> option that stops CONFIG_FOO being seen by the user (eg, having MFD_FOO
> preventing SUBSYSTEM_FOO being enabled) then it'll just get silently
> ignored.

I guess I fumbled something with my testing, this does indeed not work
like I hoped :-/
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2481 bytes --]

On Wed, Sep 12, 2018 at 08:44:52PM +0200, Thomas Gleixner wrote:
> On Wed, 12 Sep 2018, Alexandre Belloni wrote:
> > On 12/09/2018 11:14:14+0200, Linus Walleij wrote:
> > I'm not saying there aren't any issues and that the level of reviews is
> > sufficient but I really don't think problematic maintainers are as
> > widespread as Daniel claims. It is really getting tiring to see him
> > show random statistics and draw wrong conclusions from them.
> 
> Agreed. Lies, damned lies and statistics...
> 
> The really interesting metric would be bugs/nr_commits. That gives you
> valuable information how good your subsystem works and interacts with the
> rest of the kernel.

That's one angle to look at it, and I agree it would be a pretty good
overview of how good a maintainer is at reviewing patches, in general.

However, there's different angles where the metric used by Daniel
makes sense. If there's a very significant part of the work that is
done by the maintainer of a given subsystem, and that there is a
single maintainer for that subsystem, what will happen when that
maintainer decides to stop contributing for some reason?

All the knowledge they built, experience they got (including at
reviewing) is gone, possibly forever, and there's no one to pick up
the subsystem, and the code is left to rot.

Maintainers burn-out are also a thing, that is only reinforced by
being the sole one caring for that subsystem.

And then, you also have the issue that nothing prevents that
maintainer to enforce particuliar rules and thus prevent contributors,
reinforcing the fact that they would be the sole maintainer for that
subsystem.

As a community, we should care about those issues as well. Basically,
the whole Linus discussion should apply at all the levels of the
hierarchy, for pretty much the same reasons.

Having multiple maintainers and / or a more even spread of the
contributions mitigate all these. So Daniel's metric is a pretty good
one, and it doesn't mean that a particular maintainer is bad at their
job, or is not making any effort, or shouldn't be praised. It really
is a different metric, for a different issue.

It's like running a datacenter off a single machine, with a single
power supply, a single internet connection and a single hard disk. No
one would want that.

"But the bandwidth is good".

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Alexandre Belloni]

On 13/09/2018 14:08:11+0200, Maxime Ripard wrote:
> On Wed, Sep 12, 2018 at 08:44:52PM +0200, Thomas Gleixner wrote:
> > On Wed, 12 Sep 2018, Alexandre Belloni wrote:
> > > On 12/09/2018 11:14:14+0200, Linus Walleij wrote:
> > > I'm not saying there aren't any issues and that the level of reviews is
> > > sufficient but I really don't think problematic maintainers are as
> > > widespread as Daniel claims. It is really getting tiring to see him
> > > show random statistics and draw wrong conclusions from them.
> > 
> > Agreed. Lies, damned lies and statistics...
> > 
> > The really interesting metric would be bugs/nr_commits. That gives you
> > valuable information how good your subsystem works and interacts with the
> > rest of the kernel.
> 
> That's one angle to look at it, and I agree it would be a pretty good
> overview of how good a maintainer is at reviewing patches, in general.
> 
> However, there's different angles where the metric used by Daniel
> makes sense. If there's a very significant part of the work that is
> done by the maintainer of a given subsystem, and that there is a
> single maintainer for that subsystem, what will happen when that
> maintainer decides to stop contributing for some reason?
> 

Daniel's metric (at least the one he used to gauge RTC) will never ever
be the good one. He simply looked at my contributions versus the top
contributors. The reality is that I'm taking more contributor patches
than I write.

If you have a look at the DRM statistics I gave, the situation is
actually quite similar. Contribution for each driver is massively
dominated by its maintainer. For the big ones (i915, amd, exynos), if
the company decides to stop developing the driver, it will be
completely dead. For the small one they basically only have one real
contributor.

> All the knowledge they built, experience they got (including at
> reviewing) is gone, possibly forever, and there's no one to pick up
> the subsystem, and the code is left to rot.
> 

And this is almost the same for the DRM core where Daniel is by far the
top contributor.

> Maintainers burn-out are also a thing, that is only reinforced by
> being the sole one caring for that subsystem.
> 
> And then, you also have the issue that nothing prevents that
> maintainer to enforce particuliar rules and thus prevent contributors,
> reinforcing the fact that they would be the sole maintainer for that
> subsystem.
> 

This is a real issue. What I'm saying is that it is not that common.

> As a community, we should care about those issues as well. Basically,
> the whole Linus discussion should apply at all the levels of the
> hierarchy, for pretty much the same reasons.
> 
> Having multiple maintainers and / or a more even spread of the
> contributions mitigate all these. So Daniel's metric is a pretty good
> one, and it doesn't mean that a particular maintainer is bad at their
> job, or is not making any effort, or shouldn't be praised. It really
> is a different metric, for a different issue.
> 

It is a very biased metric that will show in a bad light any subsystem
that has a small core and many drivers.
Conversely, it will show that unmaintained subsystems where all the
patches are going through akpm are working well.

> It's like running a datacenter off a single machine, with a single
> power supply, a single internet connection and a single hard disk. No
> one would want that.
> 

Group maintainership is definitively good but you can't force people to
get interested in a subsystem. and this is almost never an issue with
the maintainer attitude that would be driving off contributors.

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 5411 bytes --]

On Thu, Sep 13, 2018 at 02:57:23PM +0200, Alexandre Belloni wrote:
> On 13/09/2018 14:08:11+0200, Maxime Ripard wrote:
> > On Wed, Sep 12, 2018 at 08:44:52PM +0200, Thomas Gleixner wrote:
> > > On Wed, 12 Sep 2018, Alexandre Belloni wrote:
> > > > On 12/09/2018 11:14:14+0200, Linus Walleij wrote:
> > > > I'm not saying there aren't any issues and that the level of reviews is
> > > > sufficient but I really don't think problematic maintainers are as
> > > > widespread as Daniel claims. It is really getting tiring to see him
> > > > show random statistics and draw wrong conclusions from them.
> > > 
> > > Agreed. Lies, damned lies and statistics...
> > > 
> > > The really interesting metric would be bugs/nr_commits. That gives you
> > > valuable information how good your subsystem works and interacts with the
> > > rest of the kernel.
> > 
> > That's one angle to look at it, and I agree it would be a pretty good
> > overview of how good a maintainer is at reviewing patches, in general.
> > 
> > However, there's different angles where the metric used by Daniel
> > makes sense. If there's a very significant part of the work that is
> > done by the maintainer of a given subsystem, and that there is a
> > single maintainer for that subsystem, what will happen when that
> > maintainer decides to stop contributing for some reason?
> > 
> 
> Daniel's metric (at least the one he used to gauge RTC) will never ever
> be the good one. He simply looked at my contributions versus the top
> contributors. The reality is that I'm taking more contributor patches
> than I write.
> 
> If you have a look at the DRM statistics I gave, the situation is
> actually quite similar. Contribution for each driver is massively
> dominated by its maintainer. For the big ones (i915, amd, exynos), if
> the company decides to stop developing the driver, it will be
> completely dead. For the small one they basically only have one real
> contributor.
> 
> > All the knowledge they built, experience they got (including at
> > reviewing) is gone, possibly forever, and there's no one to pick up
> > the subsystem, and the code is left to rot.
> > 
> 
> And this is almost the same for the DRM core where Daniel is by far the
> top contributor.

DRM is far from perfect. No one ever said it was, and I disagree on
some of the solutions that were implemented there. However, having
imperfect solutions doesn't make the underlying problem go away.

> > Maintainers burn-out are also a thing, that is only reinforced by
> > being the sole one caring for that subsystem.
> > 
> > And then, you also have the issue that nothing prevents that
> > maintainer to enforce particuliar rules and thus prevent contributors,
> > reinforcing the fact that they would be the sole maintainer for that
> > subsystem.
> 
> This is a real issue. What I'm saying is that it is not that common.

Yet you have first-hand experience with at least two of them.

And it's *one* symptom of the same upstream issue. The fact that you
can't have a quite holiday without drowning in mails when you go back,
or that you can't take a break from the kernel for whatever reason
without putting the code you maintained and cared for for so long is
another one.

> > As a community, we should care about those issues as well. Basically,
> > the whole Linus discussion should apply at all the levels of the
> > hierarchy, for pretty much the same reasons.
> > 
> > Having multiple maintainers and / or a more even spread of the
> > contributions mitigate all these. So Daniel's metric is a pretty good
> > one, and it doesn't mean that a particular maintainer is bad at their
> > job, or is not making any effort, or shouldn't be praised. It really
> > is a different metric, for a different issue.
> 
> It is a very biased metric that will show in a bad light any subsystem
> that has a small core and many drivers.

Can we stop about the "bad light"? Back to the datacenter example,
pointing out that there's a single hard disk doesn't show a bad light
on the one that is there. It just points out that we should prepare
for the worse and add redundancy *before* the worse happens.

> Conversely, it will show that unmaintained subsystems where all the
> patches are going through akpm are working well.

Just like Thomas' metric will show that subsystems where a single
patch changing a printk or adding a comment would be the ideal
subsystem. This is just as good as any metric, and should be looked at
with some distance.

> > It's like running a datacenter off a single machine, with a single
> > power supply, a single internet connection and a single hard disk. No
> > one would want that.
> 
> Group maintainership is definitively good but you can't force people to
> get interested in a subsystem. and this is almost never an issue with
> the maintainer attitude that would be driving off contributors.

Again, you have a handful of first-hand experiences.

And true, you can't force people to be interested in a subsystem. And
implementing group maintainership will be hard for some subsystems
with a particular contribution pattern, just like yours.

But can't we at least acknowledge the issue and tend to fixing it when
we can?

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Jani Nikula]

On Thu, 13 Sep 2018, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote:
> On 13/09/2018 14:08:11+0200, Maxime Ripard wrote:
>> All the knowledge they built, experience they got (including at
>> reviewing) is gone, possibly forever, and there's no one to pick up
>> the subsystem, and the code is left to rot.
>
> And this is almost the same for the DRM core where Daniel is by far the
> top contributor.

Except he's no longer a maintainer in either DRM or i915. Checking the
stats against current MAINTAINERS will paint you a different picture.

And that brings us to another important point: Group maintainership
allows for easier onboarding of new maintainers, and easier retirement
of old ones. We've changed several maintainers for both the drm-misc
tree and i915 since we've switched to group maintainership, and there
hasn't been noticeable bumps in the road. Mostly just business as
usual. Being a maintainer doesn't have to be for life, and you don't
have to burn out and rage quit one fine day and leave everything in
ruins behind you as you go.

I'm not saying one size fits all, and I'm not saying it's easy to find
more maintainers. But it's certainly much *much* easier to find a new
co-maintainer to a team of two or three than a new solo maintainer.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

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

[Darren Hart]

On Thu, Sep 13, 2018 at 01:41:26PM +0200, Daniel Vetter wrote:
> On Thu, Sep 13, 2018 at 1:27 PM, Mark Brown <broonie@kernel.org> wrote:
> > On Wed, Sep 12, 2018 at 10:05:19PM +0200, Daniel Vetter wrote:
> >> On Wed, Sep 12, 2018 at 8:59 PM, Darren Hart <dvhart@infradead.org> wrote:
> >
> >> > Regarding tooling, Andy and I have documented our process and shared our
> >> > tooling which has evolved to try and prevent human error. I believe DRM
> >> > has something even more evolved.
> >
> >> > https://github.com/dvhart/pdx86-tools
> >
> >> Hm, the gen-config scrips looks like a really neat idea. Atm we
> >> manually maintain some configs for all the drm drivers, but this is
> >> much better I think. Next step up would be to double-check that make
> >
> > Yes, I've got a script like that as well (mine's a *tiny* bit less
> > sophisticated) - it's super handy if you frequently add new drivers.
> >
> >> Bit of googling and fooling around says make CONFIG_FOO=y olddefconfig
> >> seems to do this, including enabling (all?) dependencies you need.
> >
> > That only works for dependencies that are selected, if there's a config
> > option that stops CONFIG_FOO being seen by the user (eg, having MFD_FOO
> > preventing SUBSYSTEM_FOO being enabled) then it'll just get silently
> > ignored.
> 
> I guess I fumbled something with my testing, this does indeed not work
> like I hoped :-/

merge-config will tell you if the CONFIG_* you specified differs in the
resulting .config.

e.g.

$ ls arch/x86/configs/pd*
arch/x86/configs/pdx86-mods.config

$ make defconfig pdx86-mods.config
*** Default configuration is based on 'x86_64_defconfig'
#
# configuration written to .config
#
Using .config as base
Merging ./arch/x86/configs/pdx86-mods.config
Value of CONFIG_MELLANOX_PLATFORM is redefined by fragment ./arch/x86/configs/pdx86-mods.config:
Previous value: # CONFIG_MELLANOX_PLATFORM is not set
New value: CONFIG_MELLANOX_PLATFORM=y

Value of CONFIG_ACER_WIRELESS is redefined by fragment ./arch/x86/configs/pdx86-mods.config:
Previous value: # CONFIG_ACER_WIRELESS is not set
New value: CONFIG_ACER_WIRELESS=m

...


-- 
Darren Hart
VMware Open Source Technology Center

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

[Thomas Gleixner]

On Thu, 13 Sep 2018, Jani Nikula wrote:
> On Thu, 13 Sep 2018, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote:
> > On 13/09/2018 14:08:11+0200, Maxime Ripard wrote:
> >> All the knowledge they built, experience they got (including at
> >> reviewing) is gone, possibly forever, and there's no one to pick up
> >> the subsystem, and the code is left to rot.
> >
> > And this is almost the same for the DRM core where Daniel is by far the
> > top contributor.
> 
> Except he's no longer a maintainer in either DRM or i915. Checking the
> stats against current MAINTAINERS will paint you a different picture.
> 
> And that brings us to another important point: Group maintainership
> allows for easier onboarding of new maintainers, and easier retirement
> of old ones. We've changed several maintainers for both the drm-misc
> tree and i915 since we've switched to group maintainership, and there
> hasn't been noticeable bumps in the road. Mostly just business as
> usual. Being a maintainer doesn't have to be for life, and you don't
> have to burn out and rage quit one fine day and leave everything in
> ruins behind you as you go.
> 
> I'm not saying one size fits all, and I'm not saying it's easy to find
> more maintainers. But it's certainly much *much* easier to find a new
> co-maintainer to a team of two or three than a new solo maintainer.

You are sounding like DRM invented group maintainership and needs to go
advertising it now as the best invention since sliced bread.

It's been in practice since 2007 when the tip tree started with 3
maintainers. It was then adopted by ARM-SoC and Linus recommended it as a
good model way before DRM went that road.

We all know that group maintainership is a good thing, but we also know
that it's not working for all subsystems and that it's not always easy to
find matching co-maintainers. Most maintainers, if not all, would be happy
to have a competent, trusted and interested co-maintainer. So it's not that
they need to be educated on that.

Group maintainership is not the Panacea. So please stop the prayer wheel
and come up with solutions which address identifed indivudual problems. Not
having group maintainership is for some subsystems the least of their
worries. And as a member of the first official maintainer group in the
kernel I can assure you that group maintainership is not making all other
and potentially more dangerous problems magically go away.

Thanks,

	tglx

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

[Rodrigo Vivi]

[-- Attachment #1: Type: text/plain, Size: 3569 bytes --]

On Thu, Sep 13, 2018 at 1:07 PM Thomas Gleixner <tglx@linutronix.de> wrote:

> On Thu, 13 Sep 2018, Jani Nikula wrote:
> > On Thu, 13 Sep 2018, Alexandre Belloni <alexandre.belloni@bootlin.com>
> wrote:
> > > On 13/09/2018 14:08:11+0200, Maxime Ripard wrote:
> > >> All the knowledge they built, experience they got (including at
> > >> reviewing) is gone, possibly forever, and there's no one to pick up
> > >> the subsystem, and the code is left to rot.
> > >
> > > And this is almost the same for the DRM core where Daniel is by far the
> > > top contributor.
> >
> > Except he's no longer a maintainer in either DRM or i915. Checking the
> > stats against current MAINTAINERS will paint you a different picture.
> >
> > And that brings us to another important point: Group maintainership
> > allows for easier onboarding of new maintainers, and easier retirement
> > of old ones. We've changed several maintainers for both the drm-misc
> > tree and i915 since we've switched to group maintainership, and there
> > hasn't been noticeable bumps in the road. Mostly just business as
> > usual. Being a maintainer doesn't have to be for life, and you don't
> > have to burn out and rage quit one fine day and leave everything in
> > ruins behind you as you go.
> >
> > I'm not saying one size fits all, and I'm not saying it's easy to find
> > more maintainers. But it's certainly much *much* easier to find a new
> > co-maintainer to a team of two or three than a new solo maintainer.
>
> You are sounding like DRM invented group maintainership and needs to go
> advertising it now as the best invention since sliced bread.
>

I had to read the thread twice to see if I could understand how you arrived
to this conclusion.

I really didn't see anyone claiming to be the inventor of group
maintainership.

And this is really not the point of what Daniel is proposing here.


> It's been in practice since 2007 when the tip tree started with 3
> maintainers. It was then adopted by ARM-SoC and Linus recommended it as a
> good model way before DRM went that road.
>

Good for you!

Well, it actually might be good for everyone if you have lessons learned
for sharing as Daniel proposed:

"- New experiments in group maintainership, and sharing lessons learned
in general."


>
> We all know that group maintainership is a good thing, but we also know
> that it's not working for all subsystems and that it's not always easy to
> find matching co-maintainers. Most maintainers, if not all, would be happy
> to have a competent, trusted and interested co-maintainer. So it's not that
> they need to be educated on that.
>

What I see on Daniel's email is not an education proposal, but to just talk
and share
experience. He is "open to anything else really on the larger topic of
community mangement."


>
> Group maintainership is not the Panacea. So please stop the prayer wheel
> and come up with solutions which address identifed indivudual problems. Not
> having group maintainership is for some subsystems the least of their
> worries. And as a member of the first official maintainer group in the
> kernel I can assure you that group maintainership is not making all other
> and potentially more dangerous problems magically go away.
>

But if there's time to discuss I don't know why they should be exclusive
things...

Thanks,
Rodrigo.


> Thanks,
>
>         tglx
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>

[-- Attachment #2: Type: text/html, Size: 5257 bytes --]

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

[Dave Airlie]

> You are sounding like DRM invented group maintainership and needs to go
> advertising it now as the best invention since sliced bread.
>
> It's been in practice since 2007 when the tip tree started with 3
> maintainers. It was then adopted by ARM-SoC and Linus recommended it as a
> good model way before DRM went that road.


How many new maintainers at the x86 group brought in, how many
maintainers has it removed? What processes have you developed for
this? Just having 3 people do something once isn't really helping the
other groups figure out a plan.

The drm group maintainer ship is a lot more mature than others as in
there has been both joins and departs from the 2-3 groups that use the
tools and system.

> We all know that group maintainership is a good thing, but we also know
> that it's not working for all subsystems and that it's not always easy to
> find matching co-maintainers. Most maintainers, if not all, would be happy
> to have a competent, trusted and interested co-maintainer. So it's not that
> they need to be educated on that.
>
> Group maintainership is not the Panacea. So please stop the prayer wheel
> and come up with solutions which address identifed indivudual problems. Not
> having group maintainership is for some subsystems the least of their
> worries. And as a member of the first official maintainer group in the
> kernel I can assure you that group maintainership is not making all other
> and potentially more dangerous problems magically go away.
>

We have a lot more time than one slot. I think other subsystems might
want some ideas on how to move to group maintainership, and copy "TIP"
or "arm-soc" isn't helpful for them.

I've just migrated all the drm-next and fixes trees to the same tools
as the two group maintainer trees, it now means for the first time in
10 years I can actually give someone else full access to the exact
same system as I use for sending trees to Linus, and more importantly
we can have people learn the system on the misc or i915 trees and grow
into toplevel maintainers, with ease.

I think it's valuable discussion to move from "you didn't invent this,
we've been doing it since 1956 on mainframes, to how can we make this
into a process that works for other subsystem maintainers).

Dave.

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

[Rafael J. Wysocki]

On Friday, September 14, 2018 1:02:57 AM CEST Rodrigo Vivi wrote:
> On Thu, Sep 13, 2018 at 1:07 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> 

[cut]

> 
> >
> > Group maintainership is not the Panacea. So please stop the prayer wheel
> > and come up with solutions which address identifed indivudual problems. Not
> > having group maintainership is for some subsystems the least of their
> > worries. And as a member of the first official maintainer group in the
> > kernel I can assure you that group maintainership is not making all other
> > and potentially more dangerous problems magically go away.
> >
> 
> But if there's time to discuss I don't know why they should be exclusive
> things...

It's very much like saying "This works for me, so it also has to work for you
or if it doesn't, explain that to me, please!"

However, the real case is that different things work for different people and
by doing the above you really make people feel like they need to defend
themselves, which isn't particularly friendly to be honest.

And if you want any positive changes to happen, making people feel like they
need to defend themselves is really counter-productive.

While it is tempting to try to impose specific similar (or even identical)
solutions on everybody, which often happens in politics mind you, that often
goes against techical merit, personal preferences or sometimes even against
what it achievable in practice given the available resources and time.

Of course, you totally have the right to advocate for certain things, but then
please realize that your experience may not be the same as the experience of
the others and respect that.

Thanks,
Rafael

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

[Linus Walleij]

On Thu, Sep 13, 2018 at 2:08 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:

> If there's a very significant part of the work that is
> done by the maintainer of a given subsystem, and that there is a
> single maintainer for that subsystem, what will happen when that
> maintainer decides to stop contributing for some reason?
>
> All the knowledge they built, experience they got (including at
> reviewing) is gone, possibly forever, and there's no one to pick up
> the subsystem, and the code is left to rot.

Unfortunately this is what happened when David Brownell
passed away. His passing had a long-standing and serious
impact on the quality of the subsystems he helped creating.

GPIO was left unmaintained and patches were coming in
and merged by Andrew Morton, as is default (and it is a
good thing that we don't just stop merging code, that would
probably have been even worse). Most of it was fine.

However one piece that got merged at this turbulent time
was the GPIO sysfs ABI which in my opinion
was not very nice. The main problem was that it exposed
kernel internals (the global GPIO numberspace) to the whole
world and made them semi-ABI which is really tricky to
maintain in the long run. It probably didn't seem like a big
problem at the time and GPIO was seen as obscure. But
it has created a major maintenance headache, and I imagine
that an active maintainer would have come up with something
a bit different. I have moved that ABI to "obsolete" and try
to make the new character device ABI as tasty as possible
to encourage migration but it will have to be maintained
until there is noone left in the forest to hear the tree fall
when I cut it. I guess in 2045 or so.

There are other things that was David's ideas, such as highly
optimized bit-banging routines in SPI where it would have
been great to have his input. Those are less severe, but I
can't help to compare with the MMC/SD subsystem where at
one point last year I could reach out to the previous-to-previous
maintainer (Pierre Ossman) and ask why the subsystem had
a bounce buffer mechanism, which was really helpful because
he quickly provided the answer and we managed to fix it up
nicely (commit bd9b902798ab).

Yours,
Linus Walleij

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

[Geert Uytterhoeven]

Hi Linus,

On Fri, Sep 14, 2018 at 9:08 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Thu, Sep 13, 2018 at 2:08 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > If there's a very significant part of the work that is
> > done by the maintainer of a given subsystem, and that there is a
> > single maintainer for that subsystem, what will happen when that
> > maintainer decides to stop contributing for some reason?
> >
> > All the knowledge they built, experience they got (including at
> > reviewing) is gone, possibly forever, and there's no one to pick up
> > the subsystem, and the code is left to rot.
>
> Unfortunately this is what happened when David Brownell
> passed away. His passing had a long-standing and serious
> impact on the quality of the subsystems he helped creating.
>
> GPIO was left unmaintained and patches were coming in
> and merged by Andrew Morton, as is default (and it is a
> good thing that we don't just stop merging code, that would
> probably have been even worse). Most of it was fine.
>
> However one piece that got merged at this turbulent time
> was the GPIO sysfs ABI which in my opinion
> was not very nice. The main problem was that it exposed
> kernel internals (the global GPIO numberspace) to the whole
> world and made them semi-ABI which is really tricky to
> maintain in the long run. It probably didn't seem like a big
> problem at the time and GPIO was seen as obscure. But
> it has created a major maintenance headache, and I imagine
> that an active maintainer would have come up with something
> a bit different.

While we do miss David Brownell, I think there are some errors in your
timeline. Commit d8f388d8dc8d4f36 ("gpio: sysfs interface") was authored
by David himself.

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: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance

[Linus Walleij]

On Fri, Sep 14, 2018 at 9:39 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Fri, Sep 14, 2018 at 9:08 AM Linus Walleij <linus.walleij@linaro.org> wrote:

> > However one piece that got merged at this turbulent time
> > was the GPIO sysfs ABI which in my opinion
> > was not very nice. The main problem was that it exposed
> > kernel internals (the global GPIO numberspace) to the whole
> > world and made them semi-ABI which is really tricky to
> > maintain in the long run. It probably didn't seem like a big
> > problem at the time and GPIO was seen as obscure. But
> > it has created a major maintenance headache, and I imagine
> > that an active maintainer would have come up with something
> > a bit different.
>
> While we do miss David Brownell, I think there are some errors in your
> timeline. Commit d8f388d8dc8d4f36 ("gpio: sysfs interface") was authored
> by David himself.

Sigh yeah git history never lies, things were wrong in my head ... :/

It would nevertheless have been nice to have him
around to explain how this was thought out. Possibly I would
have been told off and discouraged to remove the sysfs
ABI at all.

IIRC I asked some of the other people of this commit at one
point what the ideas was, and the answer was "we just needed
something to control GPIOs from userspace".

Yours,
Linus Walleij

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

[Thomas Gleixner]

On Fri, 14 Sep 2018, Dave Airlie wrote:
> I think it's valuable discussion to move from "you didn't invent this,
> we've been doing it since 1956 on mainframes, to how can we make this
> into a process that works for other subsystem maintainers).

It would be also valuable to sit back and think about

  - why the DRM model works well for DRM

  - why it is not necessarily applicable for other subsystems

  - why other maintainer groups have different setups and issues

instead of telling everyone it works great for DRM, everyone should do that
and then pull random statistics to tell people that they have a problem.

I'm all for exchanging ideas and information, but I'm totally not
interested in the condescending tone which tells the world that anyone not
doing the DRM thing has a problem.

DRM is fundamentally different than anything I maintain. The vast majority
of contributors and therefore potential maintainers are working in
corporate teams, which are there to care about DRM and the corporates
graphics cards.

On my end, the only larger group of constant contributors is around perf
tooling as there seems to be a vested interest of distros to make this
work. We have a well working setup there.

The kernel side looks fundamentally different. We surely have maintainers
where we could gain them. We have a few regular reviewers, but that's it.

Everything else is drive by, random corporate feature enablement thrown
over the fence, distro value add etc. Nothing where you can keep people
affiliated.

We do not have the concept of teams dedicated to the problem space. We
can't split it into bits and pieces as it's intervowen at the hardware
level to quite some extent. Aside of that there are neither teams nor
individuals who care about one particular piece more than they care about
the whole thing.

I'm well aware of these problems, I talk openly about them, and try to come
up with solutions since years, but I can't change the way corporates work
and people tick at all. I lost at least two submaintainers after they
gained speed just because they changed jobs and vanished into nirwana.

I'm not buying at all, that having standardized setups and tools and
whatever, will change any of the underlying issues magically.

It won't make contributors more careful, it won't make developers magically
take over responsibility, it won't change the corporate 'get this feature
thrown over the fence' mentality, it won't make people appear who deeply
care.

It's nice that it works so well for you and I wish it would work in other
places similarly well, but please can we take that step back and look at
the specific problems of a specific subsystem instead of telling everyone
that they have a problem and offering the DRM way as Panacea.

Unless that systematic and specific analysis happens, I'm out of this
discussion.

Thanks,

	tglx

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

[Daniel Vetter]

Comment on timing: I typed this up on Friday, but wanted to sit on it
for a bit more and do some editing. Then w/e happened, and I guess
this now looks somewhat strange since it doesn't take latest
development into account. Since I'm still processing these I figured
I'll just send this out as-is.

On Fri, Sep 14, 2018 at 4:15 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Fri, 14 Sep 2018, Dave Airlie wrote:
>> I think it's valuable discussion to move from "you didn't invent this,
>> we've been doing it since 1956 on mainframes, to how can we make this
>> into a process that works for other subsystem maintainers).
>
> It would be also valuable to sit back and think about
>
>   - why the DRM model works well for DRM
>
>   - why it is not necessarily applicable for other subsystems
>
>   - why other maintainer groups have different setups and issues
>
> instead of telling everyone it works great for DRM, everyone should do that
> and then pull random statistics to tell people that they have a problem.
>
> I'm all for exchanging ideas and information, but I'm totally not
> interested in the condescending tone which tells the world that anyone not
> doing the DRM thing has a problem.
>
> DRM is fundamentally different than anything I maintain. The vast majority
> of contributors and therefore potential maintainers are working in
> corporate teams, which are there to care about DRM and the corporates
> graphics cards.
>
> On my end, the only larger group of constant contributors is around perf
> tooling as there seems to be a vested interest of distros to make this
> work. We have a well working setup there.
>
> The kernel side looks fundamentally different. We surely have maintainers
> where we could gain them. We have a few regular reviewers, but that's it.

DRM is more than just drm/i915 and drm/amdgpu. Yes those are indeed
fairly unusual cases, and when I made the conferences rounds
presenting about our committer model 2 years back I highlight that it
probably works much better if you have a tight-nit team. Both i915 and
amdgpu work with a committer model (amdgpu's unfortunately not quite
as aggressively public, there's still maintainers cherry-picking
staged patches over to the final trees).

But we also have a tons of drivers which range from outright
drive-thru to just chronically under-maintained reverse-engineered
stacks. Some have some coporate backing, a lot of it along the lines
of "I need to get this feature in, where can I drop my patches". So
2-3 years ago I'd say we definitely had a lot of the problems you and
other maintainers in this thread are describing. We still have a lot
of these, but I think we've substantial improved upon our own old
status quo. And yes, drm ex. i915&amdgpu is a bit smaller than tip,
but a fairly substantial junk still.

> Everything else is drive by, random corporate feature enablement thrown
> over the fence, distro value add etc. Nothing where you can keep people
> affiliated.
>
> We do not have the concept of teams dedicated to the problem space. We
> can't split it into bits and pieces as it's intervowen at the hardware
> level to quite some extent. Aside of that there are neither teams nor
> individuals who care about one particular piece more than they care about
> the whole thing.
>
> I'm well aware of these problems, I talk openly about them, and try to come
> up with solutions since years, but I can't change the way corporates work
> and people tick at all. I lost at least two submaintainers after they
> gained speed just because they changed jobs and vanished into nirwana.

These are all the same problems we've had (and to some extent, still
have) in small drm drivers, not mostly maintained as part of drm-misc.

> I'm not buying at all, that having standardized setups and tools and
> whatever, will change any of the underlying issues magically.

Standard tooling is indeed fairly miniscule thing (and we're
definitely not even close to an optimum with the drm tooling we do
have). But it contributes. Creating a great community where people
want to hang around in, even if it's not the job they're directly paid
for, takes a lot of work, at all fronts. No single item is going to be
your magic fix, but in aggregate, you really need all the pieces (or
most of them at least).

> It won't make contributors more careful, it won't make developers magically
> take over responsibility, it won't change the corporate 'get this feature
> thrown over the fence' mentality, it won't make people appear who deeply
> care.
>
> It's nice that it works so well for you and I wish it would work in other
> places similarly well, but please can we take that step back and look at
> the specific problems of a specific subsystem instead of telling everyone
> that they have a problem and offering the DRM way as Panacea.
>
> Unless that systematic and specific analysis happens, I'm out of this
> discussion.

I think most of the specific things we've learned in drm have been
brought up in the discussion already. Individually they indeed don't
seem all that important, so let me summarize them here:

- commit rights also works with a very lousely coupled group of
people. In drm-misc we've stuffed random tiny drivers all over the
place into one tree, and it's not utter chaos. This is new, since 2
years ago I mentioned that we've only tried this on tight-nit vendor
teams.

- stuffing even somewhat unrelated things into one tree, and
encouraging collaboration through the stick of forced cross-review,
helps a lot in improving the bus factor. Even for tiny things you end
up with more than 1 person who occasionally looked at it and has some
clue. Again, this is a newly gained insight.

- the pipeline from drive-thru contributor, to occasional, then
regular, then experienced enough to provide useful review, and so on,
until they start taking over maintainer duties is very lossy, and
generally takes a few years. It's also extremely sensitive to even the
tiniest barriers and hurdles - whether you end up with a new
maintainer or not feels like a "death by a thousand papercuts" thing.
And generally the people who drop out never tell you why, so figuring
out what hurts requires tons of experimenting. So even tiny things
that look totally inconsequential at first sight matter hugely for the
overall success here. Like tooling.

- it's paramount that people feel their contributions are valued -
they have tons of reasons for walking away asap, and the only thing we
can give them in return for staying is a warm and fuzzy feeling. Which
pays like shit, but it's all we have. We try to aggressively recognize
good contributors by giving them commit rights, adding them formally
as reviewers to MAINTAINERS, bunch of thank yous (I'm really bad at
those myself and do way too little). You'd probably be in complete
shock how quickly we hand out these charges and responsibilities, but
in the large scheme it really does work.

- we crack down hard on anything that might drive away contributors.
There's two big pieces here, first our Code of Conduct. Yes we enforce
it, and yes I have the mails to prove that people notice, and that
they stick around because we manage to create a more respectful and
constructive atmosphere. The other is that there's no special
priviledges for maintainers. If you have special maintainer powers,
you make it pretty clear that everyone else is a 2nd class
contributor, and no amount of recognizing is going to fix that and
make people stay when they have other duties that keep them busy.

And yes, DRM is by far not perfect. We still have a bunch of trees and
drivers which aren't well maintained in my opinion. And we're trying
out new things to figure out whether we can improve on the status quo.
What's flat out not true on the other hand is that we're just doing a
bunch of philosophical waxing, that we don't have similar problems to
everyone else (just a different mix of them of course), and that we
haven't figured out new stuff the past 2 years and new lessons
learned.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Ksummit-discuss] [MAINTAINER SUMMIT] Live without email - possible? - Was: community management/subsystem governance

[Mauro Carvalho Chehab]

Em Mon, 10 Sep 2018 04:53:07 -1000
Linus Torvalds <torvalds@linux-foundation.org> escreveu:

> So let me suggest a topic for the maintainer summit:
> 
>   "Live without email - possible?"
> 
> just to get that ball rolling

(I did a little reorder here, to place the new topic proposal at the
 beginning)

...

> I've not used gitlab personally, but I *have* used github for a much
> smaller project.
>
> I have to say, the random and relaxed model is enjoyable. I can see
> how somebody coming from that, then finds the strict kernel rules (and
> _different_ rules for different parts) off-putting and confusing.

With the risk of getting somewhat offtopic, let me give some hints
from my personal experience with github.

I'm currently hosting some EDAC/RAS tools and some media userspace stuff
on github (and a few other random stuff). I also contributed with some
solaar patches in the past, addressing some hardware issues with the
mouse I use here. A couple of weeks ago got commit rights on a camera 
application (camorama).

So, I have not only things hosted by me and projects that I contribute,
but also things hosted by someone else there with commit rights.

Yeah, for projects maintained by a small number of developers, a web
interface like github provides additional value over a single git host
site, as it provides a lightweight interface for bugtrack/issues, it 
allows threaded comments on pull requests, and it allows seeing all
(publicly available) forks.

Another interesting feature is that, if someone add more patches to a
branch that it is part of a pull request (or rebase it), their interface
automatically reflects it. So, it avoids merging old stuff, if you handle
pull requests via the web interface[1].

[1] From security PoV, this can be risky, as you might end merging
something wrong, if someone steals the credentials of the original
committer. One thing that I didn't try yet is how it would handle
GPG-signed tags.

It works nice on projects with a small number of maintainers/developers.

That's said, I don't think that such model would scale for the Kernel as
a hole. 

IMO, the number of issues and pull requests will make it messy and
easy to lose something. The same likely applies to high-traffic
subsystems like media.

For low traffic subsystems however, I can see such model would work
pretty well, as it would not only provide a simple centralized repository
for the subsystem, but would also work as a forum where people could 
add issues, comment on pull requests, create development forks, etc.
Also, "Gen-Y/Gen-Z" developers are likely more familiar with such
kind of interface, so it has the potential to attract new blood to 
the Kernel than e-mail discussions.

I guess we could experiment using it on some small subsystems and see
how well it would work.

Thanks,
Mauro

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

[Mauro Carvalho Chehab]

Em Tue, 11 Sep 2018 02:05:06 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:

> Hi Ted,
> 
> On Tuesday, 11 September 2018 00:11:28 EEST Theodore Y. Ts'o wrote:
> > On Mon, Sep 10, 2018 at 11:32:00PM +0300, Laurent Pinchart wrote:  
> > > On my side, there are three very important features that a communication
> > > system should have:
> > > 
> > > - It should be push-based. I don't want to have to log in and pull
> > > information from web UIs.
> > > 
> > > - It should be customizable, offering an easy way to script review, and
> > > patch and pull request handling.
> > > 
> > > - It should offer an offline mode. Lots of us travel a lot or generally
> > > have to work without an internet connection more often than we would
> > > like, so any solution that requires being online won't work.
> > > 
> > > Emails provide all that, there may be good options I just fail to think
> > > about right now.  
> > 
> > One more requirement I would add is that messages should be archived,
> > and should have a first class search system.  We should be able to
> > reference a commit id in a communications thread, and then a search
> > for that commit id (or commit description) should be able to turn up
> > that message, and from there, be able to see the rest of the messages
> > on that thread.
> > 
> > Being able to find the "legislative history" behind a particular
> > change in the kernel is super-important.  
> 
> Fully agreed. I would even go one step further, I'd like a system where 
> relationships between messages are kept. This obviously means linking patches 
> from the same series, but also detecting new versions of patch series (to the 
> extent possible, as already discussed in this mail thread).
> 

Let me go one step down.

While I do agree that the main Kernel development should happen via
email on the foreseen future, Why e-mail would be a mandatory
requirement for all kinds of Kernel development? 

I don't believe that a single development model fits all cases.

Let's say that someone is using something like github to manage the
development of a single driver - or even a low traffic subsystem.

The communication traffic between the developers there is usually
not relevant (nor wanted) at LKML.

What we usually do on normal subsystems is to have those discussions
"filtered" on a separate mailing list. I don't see why not use a
web-based interface for such purpose.

Btw, that's not that different on what happens on some companies that
do their driver developments internally. They do whatever they want
when developing the driver. Only when they have something ready they
use e-mail.

A github-like interface is actually better than that, as people 
interested on such driver/subsystem could contribute earlier than 
on a closed doors model, as the discussions can be seen publicly.

On both cases, the only relevant discussions for LKML and for the
Kernel maintainer that would be taking their patches are when they
send a pull request upstream.

Granted, there will be some drawbacks if email interface is not
available if such development community would need to talk with
other subsystems. So, yes, it is desirable to have an e-mail
interface, as otherwise a human would have to handle such things
manually, but, again, for low traffic development, such things
would be doable.

Thanks,
Mauro

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

[Geert Uytterhoeven]

Hi Mauro,

On Mon, Sep 17, 2018 at 1:43 PM Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
> Em Tue, 11 Sep 2018 02:05:06 +0300
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> > On Tuesday, 11 September 2018 00:11:28 EEST Theodore Y. Ts'o wrote:
> > > On Mon, Sep 10, 2018 at 11:32:00PM +0300, Laurent Pinchart wrote:
> > > > On my side, there are three very important features that a communication
> > > > system should have:
> > > >
> > > > - It should be push-based. I don't want to have to log in and pull
> > > > information from web UIs.
> > > >
> > > > - It should be customizable, offering an easy way to script review, and
> > > > patch and pull request handling.
> > > >
> > > > - It should offer an offline mode. Lots of us travel a lot or generally
> > > > have to work without an internet connection more often than we would
> > > > like, so any solution that requires being online won't work.
> > > >
> > > > Emails provide all that, there may be good options I just fail to think
> > > > about right now.
> > >
> > > One more requirement I would add is that messages should be archived,
> > > and should have a first class search system.  We should be able to
> > > reference a commit id in a communications thread, and then a search
> > > for that commit id (or commit description) should be able to turn up
> > > that message, and from there, be able to see the rest of the messages
> > > on that thread.
> > >
> > > Being able to find the "legislative history" behind a particular
> > > change in the kernel is super-important.
> >
> > Fully agreed. I would even go one step further, I'd like a system where
> > relationships between messages are kept. This obviously means linking patches
> > from the same series, but also detecting new versions of patch series (to the
> > extent possible, as already discussed in this mail thread).
> >
>
> Let me go one step down.
>
> While I do agree that the main Kernel development should happen via
> email on the foreseen future, Why e-mail would be a mandatory
> requirement for all kinds of Kernel development?
>
> I don't believe that a single development model fits all cases.
>
> Let's say that someone is using something like github to manage the
> development of a single driver - or even a low traffic subsystem.
>
> The communication traffic between the developers there is usually
> not relevant (nor wanted) at LKML.
>
> What we usually do on normal subsystems is to have those discussions
> "filtered" on a separate mailing list. I don't see why not use a
> web-based interface for such purpose.
>
> Btw, that's not that different on what happens on some companies that
> do their driver developments internally. They do whatever they want
> when developing the driver. Only when they have something ready they
> use e-mail.
>
> A github-like interface is actually better than that, as people
> interested on such driver/subsystem could contribute earlier than
> on a closed doors model, as the discussions can be seen publicly.
>
> On both cases, the only relevant discussions for LKML and for the
> Kernel maintainer that would be taking their patches are when they
> send a pull request upstream.

Development doesn't stop when the driver has been developed and merged
in mainline.
It's a good idea to always CC lkml when submitting a patch for a bug in the
driver.

> Granted, there will be some drawbacks if email interface is not
> available if such development community would need to talk with
> other subsystems. So, yes, it is desirable to have an e-mail
> interface, as otherwise a human would have to handle such things
> manually, but, again, for low traffic development, such things
> would be doable.

And once the driver has been integrated, maintenance (changed
subsystem APIs, cleanups, ...) will need be done, on a larger scale.

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: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance

[Mauro Carvalho Chehab]

Em Mon, 17 Sep 2018 14:03:55 +0200
Geert Uytterhoeven <geert@linux-m68k.org> escreveu:

> Hi Mauro,
> 
> On Mon, Sep 17, 2018 at 1:43 PM Mauro Carvalho Chehab
> <mchehab+samsung@kernel.org> wrote:
> > Em Tue, 11 Sep 2018 02:05:06 +0300
> > Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:  
> > > On Tuesday, 11 September 2018 00:11:28 EEST Theodore Y. Ts'o wrote:  
> > > > On Mon, Sep 10, 2018 at 11:32:00PM +0300, Laurent Pinchart wrote:  
> > > > > On my side, there are three very important features that a communication
> > > > > system should have:
> > > > >
> > > > > - It should be push-based. I don't want to have to log in and pull
> > > > > information from web UIs.
> > > > >
> > > > > - It should be customizable, offering an easy way to script review, and
> > > > > patch and pull request handling.
> > > > >
> > > > > - It should offer an offline mode. Lots of us travel a lot or generally
> > > > > have to work without an internet connection more often than we would
> > > > > like, so any solution that requires being online won't work.
> > > > >
> > > > > Emails provide all that, there may be good options I just fail to think
> > > > > about right now.  
> > > >
> > > > One more requirement I would add is that messages should be archived,
> > > > and should have a first class search system.  We should be able to
> > > > reference a commit id in a communications thread, and then a search
> > > > for that commit id (or commit description) should be able to turn up
> > > > that message, and from there, be able to see the rest of the messages
> > > > on that thread.
> > > >
> > > > Being able to find the "legislative history" behind a particular
> > > > change in the kernel is super-important.  
> > >
> > > Fully agreed. I would even go one step further, I'd like a system where
> > > relationships between messages are kept. This obviously means linking patches
> > > from the same series, but also detecting new versions of patch series (to the
> > > extent possible, as already discussed in this mail thread).
> > >  
> >
> > Let me go one step down.
> >
> > While I do agree that the main Kernel development should happen via
> > email on the foreseen future, Why e-mail would be a mandatory
> > requirement for all kinds of Kernel development?
> >
> > I don't believe that a single development model fits all cases.
> >
> > Let's say that someone is using something like github to manage the
> > development of a single driver - or even a low traffic subsystem.
> >
> > The communication traffic between the developers there is usually
> > not relevant (nor wanted) at LKML.
> >
> > What we usually do on normal subsystems is to have those discussions
> > "filtered" on a separate mailing list. I don't see why not use a
> > web-based interface for such purpose.
> >
> > Btw, that's not that different on what happens on some companies that
> > do their driver developments internally. They do whatever they want
> > when developing the driver. Only when they have something ready they
> > use e-mail.
> >
> > A github-like interface is actually better than that, as people
> > interested on such driver/subsystem could contribute earlier than
> > on a closed doors model, as the discussions can be seen publicly.
> >
> > On both cases, the only relevant discussions for LKML and for the
> > Kernel maintainer that would be taking their patches are when they
> > send a pull request upstream.  
> 
> Development doesn't stop when the driver has been developed and merged
> in mainline.

Yeah, sure.

> It's a good idea to always CC lkml when submitting a patch for a bug in the
> driver.

True, but this doesn't always happen. If it happens, nothing prevents
that someone would use a "man-handled copy-and-paste interface"
between e-mail and web.

Btw, this happens already, even with e-mail: from time to time, we
receive bug reports on media from something reported via distro bug
tracks (bugzilla, Trac, ...).

Even when the bug tracking system has an email interface
(Red Hat BZ has, for example), it is really rare to use email 
for tracked bug reports (even from Kernel.org bugzilla). 

What works in practice for such bugs is that we end by using web
interfaces if we need to talk about the bug inside the tracker
system, or via e-mail if we want to talk about it subsystem-wide.

Sub-optimal, but it works.

The same would happen if the development discussions would happen
inside a web interface like github/gitlab. Of course, the maintainer
would still need to be reachable by e-mail.

> > Granted, there will be some drawbacks if email interface is not
> > available if such development community would need to talk with
> > other subsystems. So, yes, it is desirable to have an e-mail
> > interface, as otherwise a human would have to handle such things
> > manually, but, again, for low traffic development, such things
> > would be doable.  
> 
> And once the driver has been integrated, maintenance (changed
> subsystem APIs, cleanups, ...) will need be done, on a larger scale.

True, but still doable.

See, I don't have myself any plans to use something like github
for Kernel development. Yet, I think we should be open to work
with people that would prefer to work with such model.

Btw, on a quick look, it seems that github has/had an email 
interface already:
	https://blog.github.com/2011-03-10-reply-to-comments-from-email/

It seems that there are ways to create new issues there via e-mail
too, although currently it sounds a little hacky (requiring either
to run an script or to add a github bot user to the project):

	https://stackoverflow.com/questions/25051686/create-github-issue-from-freshdesk

Thanks,
Mauro

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

[Julia Lawall]

> Btw, on a quick look, it seems that github has/had an email
> interface already:
> 	https://blog.github.com/2011-03-10-reply-to-comments-from-email/

I only interact with issues posted to github via email (alpine
specifically).  The only problem is that people tend to omit context,
because they assume that you see the code or previous messages that they
see in the web interface, which you do not.

julia

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

[Christoph Hellwig]

On Mon, Sep 17, 2018 at 08:43:35AM -0300, Mauro Carvalho Chehab wrote:
> While I do agree that the main Kernel development should happen via
> email on the foreseen future, Why e-mail would be a mandatory
> requirement for all kinds of Kernel development? 
> 
> I don't believe that a single development model fits all cases.
> 
> Let's say that someone is using something like github to manage the
> development of a single driver - or even a low traffic subsystem.

Sadly enough that already is the case.  The ACPI maintainers refuse
to take perfectly fine patches and instead redirect people to a
github version (which doesn't look like the kernel code at all),
which requires a signup with a not exactly trust-worthy webservice.

I don't think we should care how a subsystem is managed internally
as long as they accept perfectly fine formatted patches by email.

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

[Christoph Hellwig]

On Mon, Sep 17, 2018 at 03:10:50PM +0200, Julia Lawall wrote:
> > Btw, on a quick look, it seems that github has/had an email
> > interface already:
> > 	https://blog.github.com/2011-03-10-reply-to-comments-from-email/
> 
> I only interact with issues posted to github via email (alpine
> specifically).  The only problem is that people tend to omit context,
> because they assume that you see the code or previous messages that they
> see in the web interface, which you do not.

The major problem with github is that as far as I can tell there is no
way to interact with it without creating an account.

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

[Laurent Pinchart]

On Monday, 17 September 2018 16:29:08 EEST Christoph Hellwig wrote:
> On Mon, Sep 17, 2018 at 03:10:50PM +0200, Julia Lawall wrote:
> > > Btw, on a quick look, it seems that github has/had an email
> > > 
> > > interface already:
> > > 	https://blog.github.com/2011-03-10-reply-to-comments-from-email/
> > 
> > I only interact with issues posted to github via email (alpine
> > specifically).  The only problem is that people tend to omit context,
> > because they assume that you see the code or previous messages that they
> > see in the web interface, which you do not.
> 
> The major problem with github is that as far as I can tell there is no
> way to interact with it without creating an account.

That's what bothers me as well. I'm not opposed to a subsystem replacing git 
request-pull + email with git-push, provided that an e-mail gateway forwards 
the pull request to the appropriate mailing lists. I'm also no opposed to a 
subsystem offering git-push as an optional alternative to git-send-email to 
submit patches, provided the above e-mail gateway. What I don't want is having 
to create accounts and authenticate the git-push, as that would make drive-by 
contributions more difficult. For the replacement of pull requests I could 
live with having to submit my ssh public key (but not individually to all 
subsystems), but for the alternative to patch submission by e-mail we would 
need to support unauthenticated git-push.

-- 
Regards,

Laurent Pinchart

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

[Mauro Carvalho Chehab]

Em Mon, 17 Sep 2018 06:29:08 -0700
Christoph Hellwig <hch@infradead.org> escreveu:

> On Mon, Sep 17, 2018 at 03:10:50PM +0200, Julia Lawall wrote:
> > > Btw, on a quick look, it seems that github has/had an email
> > > interface already:
> > > 	https://blog.github.com/2011-03-10-reply-to-comments-from-email/  
> > 
> > I only interact with issues posted to github via email (alpine
> > specifically).  The only problem is that people tend to omit context,
> > because they assume that you see the code or previous messages that they
> > see in the web interface, which you do not.  
> 
> The major problem with github is that as far as I can tell there is no
> way to interact with it without creating an account.

Well, the same happens with moderated mailing lists. There are a
lot of them:
	$ git grep moderated MAINTAINERS|wc -l
	221

Except when it is something that I really want to be merged
(e. g. something that affects my own machines or I have a demand
from my employer), when a perfectly fine patch I sent is ignored 
by such lists, I just ignore whatever e-mail I receive from their
mailman interface, and I assume that, if I don't receive any reply
from a human, either the maintainers of such subsystem(s) accepted
it or they just don't care enough. So, if it is patch affecting
media, I just apply after a reasonable reviewing time.

In the case of github-like interfaces, I would do the same: I
would copy the maintainer(s) and just ignore any "non-subscriber's 
warning" kind of e-mail.

That's actually one difference in this case: while on moderated
ML you need to be added to each individual ML in order to send
e-mails, on a web-based interface, just one subscription is
enough for all projects hosted there, and there are a lot less
git hosting servers than email mailing lists. So, in the specific
case of github, I wouldn't have any issues, as I had to create
an account there due to other purposes. Yet, I don't have any
need right now to have an account on gitlab or Pagure. I very
likely wouldn't create an account there just to forward patches
to a random kernel subsystem/driver eventually hosted there.

Thanks,
Mauro

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

[Laurent Pinchart]

On Monday, 17 September 2018 16:04:13 EEST Mauro Carvalho Chehab wrote:
> Em Mon, 17 Sep 2018 14:03:55 +0200 Geert Uytterhoeven escreveu:
> > On Mon, Sep 17, 2018 at 1:43 PM Mauro Carvalho Chehab wrote:
> >> Em Tue, 11 Sep 2018 02:05:06 +0300 Laurent Pinchart escreveu:
> >>> On Tuesday, 11 September 2018 00:11:28 EEST Theodore Y. Ts'o wrote:
> >>>> On Mon, Sep 10, 2018 at 11:32:00PM +0300, Laurent Pinchart wrote:
> >>>>> On my side, there are three very important features that a
> >>>>> communication system should have:
> >>>>> 
> >>>>> - It should be push-based. I don't want to have to log in and pull
> >>>>> information from web UIs.
> >>>>> 
> >>>>> - It should be customizable, offering an easy way to script
> >>>>> review, and patch and pull request handling.
> >>>>> 
> >>>>> - It should offer an offline mode. Lots of us travel a lot or
> >>>>> generally have to work without an internet connection more often
> >>>>> than we would like, so any solution that requires being online
> >>>>> won't work.
> >>>>> 
> >>>>> Emails provide all that, there may be good options I just fail to
> >>>>> think about right now.
> >>>> 
> >>>> One more requirement I would add is that messages should be
> >>>> archived, and should have a first class search system.  We should be
> >>>> able to reference a commit id in a communications thread, and then a
> >>>> search for that commit id (or commit description) should be able to
> >>>> turn up that message, and from there, be able to see the rest of the
> >>>> messages on that thread.
> >>>> 
> >>>> Being able to find the "legislative history" behind a particular
> >>>> change in the kernel is super-important.
> >>> 
> >>> Fully agreed. I would even go one step further, I'd like a system
> >>> where relationships between messages are kept. This obviously means
> >>> linking patches from the same series, but also detecting new versions
> >>> of patch series (to the extent possible, as already discussed in this
> >>> mail thread).
> >> 
> >> Let me go one step down.
> >> 
> >> While I do agree that the main Kernel development should happen via
> >> email on the foreseen future, Why e-mail would be a mandatory
> >> requirement for all kinds of Kernel development?

Nothing in the list of requirements above mandates e-mail, it just happens 
that e-mail fits them at the moment.

> >> I don't believe that a single development model fits all cases.
> >> 
> >> Let's say that someone is using something like github to manage the
> >> development of a single driver - or even a low traffic subsystem.

Please note that Daniel specifically mentioned gitlab, not github, and 
explained how the github model wouldn't fit our needs.

> >> The communication traffic between the developers there is usually
> >> not relevant (nor wanted) at LKML.

Not on LKML, but it should be public, searchable and mirrored, not hidden 
behind an authentication, or stored in a single location.

> >> What we usually do on normal subsystems is to have those discussions
> >> "filtered" on a separate mailing list. I don't see why not use a
> >> web-based interface for such purpose.

There are multiple reasons. One of them is that you'll lose the whole history 
the day the project is deleted from gitlab, github or any other single 
provider. Another one is that it requires drive-by contributors to log in to 
different web UIs to submit patches to different subsystems (and from my point 
of view even a single web UI is too much). As soon as you require people to 
pull content instead of getting it in their mailbox (or whatever alternative 
to e-mail we would come up with), you've lost.

> >> Btw, that's not that different on what happens on some companies that
> >> do their driver developments internally. They do whatever they want
> >> when developing the driver. Only when they have something ready they
> >> use e-mail.

And we've told companies for years that they should develop in the open. It 
has borne some fruits (albeit not enough), so let's not go back to where we 
were before.

> >> A github-like interface is actually better than that, as people
> >> interested on such driver/subsystem could contribute earlier than
> >> on a closed doors model, as the discussions can be seen publicly.
> >> 
> >> On both cases, the only relevant discussions for LKML and for the
> >> Kernel maintainer that would be taking their patches are when they
> >> send a pull request upstream.
> > 
> > Development doesn't stop when the driver has been developed and merged
> > in mainline.
> 
> Yeah, sure.
> 
> > It's a good idea to always CC lkml when submitting a patch for a bug in
> > the driver.
> 
> True, but this doesn't always happen. If it happens, nothing prevents
> that someone would use a "man-handled copy-and-paste interface"
> between e-mail and web.
> 
> Btw, this happens already, even with e-mail: from time to time, we
> receive bug reports on media from something reported via distro bug
> tracks (bugzilla, Trac, ...).
> 
> Even when the bug tracking system has an email interface
> (Red Hat BZ has, for example), it is really rare to use email
> for tracked bug reports (even from Kernel.org bugzilla).
> 
> What works in practice for such bugs is that we end by using web
> interfaces if we need to talk about the bug inside the tracker
> system, or via e-mail if we want to talk about it subsystem-wide.
> 
> Sub-optimal, but it works.

That makes our work more difficult, due to the lack of integration between the 
bug tracker and our usual workflow. Bugs reported through bug trackers are 
often handled as second-class citizens for that reason.

> The same would happen if the development discussions would happen
> inside a web interface like github/gitlab. Of course, the maintainer
> would still need to be reachable by e-mail.

If your point is that it would be similarly painful, I agree :-) (or to be 
honest I'm concerned it would be even more painful, but certainly not less).

> >> Granted, there will be some drawbacks if email interface is not
> >> available if such development community would need to talk with
> >> other subsystems. So, yes, it is desirable to have an e-mail
> >> interface, as otherwise a human would have to handle such things
> >> manually, but, again, for low traffic development, such things
> >> would be doable.
> > 
> > And once the driver has been integrated, maintenance (changed
> > subsystem APIs, cleanups, ...) will need be done, on a larger scale.
> 
> True, but still doable.
> 
> See, I don't have myself any plans to use something like github
> for Kernel development. Yet, I think we should be open to work
> with people that would prefer to work with such model.
> 
> Btw, on a quick look, it seems that github has/had an email
> interface already:
> 	https://blog.github.com/2011-03-10-reply-to-comments-from-email/
> 
> It seems that there are ways to create new issues there via e-mail
> too, although currently it sounds a little hacky (requiring either
> to run an script or to add a github bot user to the project):
> 
> 	https://stackoverflow.com/questions/25051686/create-github-issue-from-fresh
> desk

If you want to look at specific features I'd recommend checking gitlab and not 
github, for the reasons outlined by Daniel.

As explained before, there's nothing wrong in my opinion in providing a web UI 
for some features as an optional alternative to e-mail, as long as proper e-
mail gateways are in place to make e-mail-based workflow mostly undisturbed.

-- 
Regards,

Laurent Pinchart

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

[Mauro Carvalho Chehab]

Em Mon, 17 Sep 2018 06:12:18 -0700
Christoph Hellwig <hch@infradead.org> escreveu:

> On Mon, Sep 17, 2018 at 08:43:35AM -0300, Mauro Carvalho Chehab wrote:
> > While I do agree that the main Kernel development should happen via
> > email on the foreseen future, Why e-mail would be a mandatory
> > requirement for all kinds of Kernel development? 
> > 
> > I don't believe that a single development model fits all cases.
> > 
> > Let's say that someone is using something like github to manage the
> > development of a single driver - or even a low traffic subsystem.  
> 
> Sadly enough that already is the case.  The ACPI maintainers refuse
> to take perfectly fine patches and instead redirect people to a
> github version (which doesn't look like the kernel code at all),
> which requires a signup with a not exactly trust-worthy webservice.
> 
> I don't think we should care how a subsystem is managed internally
> as long as they accept perfectly fine formatted patches by email.

Fully agreed.

IMO, a mandatory requirement is that anyone that uses a development model
that would refuse a perfectly fine patch sent via a plain e-mail from a
non-subscriber should ensure that, if such email is ever received, it
will be properly handled.

IMO, we should add such rule on our patch development process docs (if
not there already), and if abuses are happening, see what it can be done
to fix it.

In other words, in the case of a moderated ML, it should be up to the
ML maintainers to accept valid patch emails, without requiring
occasional contributors to subscribe. 

The same rule should apply to github-like development: it should be
up to the maintainers to do whatever it is needed for such patches
to be handled on their development model.

Thanks,
Mauro

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

[Christoph Hellwig]

On Mon, Sep 17, 2018 at 10:58:05AM -0300, Mauro Carvalho Chehab wrote:
> > > specifically).  The only problem is that people tend to omit context,
> > > because they assume that you see the code or previous messages that they
> > > see in the web interface, which you do not.  
> > 
> > The major problem with github is that as far as I can tell there is no
> > way to interact with it without creating an account.
> 
> Well, the same happens with moderated mailing lists. There are a
> lot of them:
> 	$ git grep moderated MAINTAINERS|wc -l
> 	221

Note that moderated doesn't mean that it always rejects non-subscribers.
For example I post to linux-arm-kernel frequently, and my mails always
seem to make it through with a delay.  Other lists seems to reject
non-subcribers, but the personal email addresses of the maintainers
still allow to submit patches without any signup.

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

[Laurent Pinchart]

On Monday, 17 September 2018 16:58:05 EEST Mauro Carvalho Chehab wrote:
> Em Mon, 17 Sep 2018 06:29:08 -0700 Christoph Hellwig escreveu:
> > On Mon, Sep 17, 2018 at 03:10:50PM +0200, Julia Lawall wrote:
> >>> Btw, on a quick look, it seems that github has/had an email
> >>> 
> >>> interface already:
> >>> 	https://blog.github.com/2011-03-10-reply-to-comments-from-email/
> >> 
> >> I only interact with issues posted to github via email (alpine
> >> specifically).  The only problem is that people tend to omit context,
> >> because they assume that you see the code or previous messages that they
> >> see in the web interface, which you do not.
> > 
> > The major problem with github is that as far as I can tell there is no
> > way to interact with it without creating an account.
> 
> Well, the same happens with moderated mailing lists. There are a
> lot of them:
> 	$ git grep moderated MAINTAINERS|wc -l
> 	221

I disagree, I think that's very different. A moderated mailing list requires 
you to subscribe, but then doesn't require you to authenticate for every 
interaction, while a web UI will require authentication.

> Except when it is something that I really want to be merged
> (e. g. something that affects my own machines or I have a demand
> from my employer), when a perfectly fine patch I sent is ignored
> by such lists, I just ignore whatever e-mail I receive from their
> mailman interface, and I assume that, if I don't receive any reply
> from a human, either the maintainers of such subsystem(s) accepted
> it or they just don't care enough. So, if it is patch affecting
> media, I just apply after a reasonable reviewing time.
> 
> In the case of github-like interfaces, I would do the same: I
> would copy the maintainer(s) and just ignore any "non-subscriber's
> warning" kind of e-mail.

There would be no such warning, as you wouldn't be able to post a message in 
the first place.

> That's actually one difference in this case: while on moderated
> ML you need to be added to each individual ML in order to send
> e-mails, on a web-based interface, just one subscription is
> enough for all projects hosted there, and there are a lot less
> git hosting servers than email mailing lists.

At the moment there is. If we start hosting gitlab instances for different 
subsystems, the situation will become very different.

> So, in the specific case of github, I wouldn't have any issues, as I had to
> create an account there due to other purposes. Yet, I don't have any
> need right now to have an account on gitlab or Pagure. I very
> likely wouldn't create an account there just to forward patches
> to a random kernel subsystem/driver eventually hosted there.

Exactly my point :-)

-- 
Regards,

Laurent Pinchart

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

[Geert Uytterhoeven]

Hi Christoph,

On Mon, Sep 17, 2018 at 4:18 PM Christoph Hellwig <hch@infradead.org> wrote:
> On Mon, Sep 17, 2018 at 10:58:05AM -0300, Mauro Carvalho Chehab wrote:
> > > > specifically).  The only problem is that people tend to omit context,
> > > > because they assume that you see the code or previous messages that they
> > > > see in the web interface, which you do not.
> > >
> > > The major problem with github is that as far as I can tell there is no
> > > way to interact with it without creating an account.
> >
> > Well, the same happens with moderated mailing lists. There are a
> > lot of them:
> >       $ git grep moderated MAINTAINERS|wc -l
> >       221
>
> Note that moderated doesn't mean that it always rejects non-subscribers.
> For example I post to linux-arm-kernel frequently, and my mails always
> seem to make it through with a delay.

linux-arm-kernel is a gateway to many maintainers, most of them will take
your patches fine.

But if it is for core ARM, it still has to be submitted to the ARM patch system
separately.

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: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance

[Mauro Carvalho Chehab]

Em Mon, 17 Sep 2018 17:14:29 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:

> On Monday, 17 September 2018 16:04:13 EEST Mauro Carvalho Chehab wrote:
> > Em Mon, 17 Sep 2018 14:03:55 +0200 Geert Uytterhoeven escreveu:  
> > > On Mon, Sep 17, 2018 at 1:43 PM Mauro Carvalho Chehab wrote:  
> > >> Em Tue, 11 Sep 2018 02:05:06 +0300 Laurent Pinchart escreveu:  
> > >>> On Tuesday, 11 September 2018 00:11:28 EEST Theodore Y. Ts'o wrote:  
> > >>>> On Mon, Sep 10, 2018 at 11:32:00PM +0300, Laurent Pinchart wrote:  
> > >>>>> On my side, there are three very important features that a
> > >>>>> communication system should have:
> > >>>>> 
> > >>>>> - It should be push-based. I don't want to have to log in and pull
> > >>>>> information from web UIs.
> > >>>>> 
> > >>>>> - It should be customizable, offering an easy way to script
> > >>>>> review, and patch and pull request handling.
> > >>>>> 
> > >>>>> - It should offer an offline mode. Lots of us travel a lot or
> > >>>>> generally have to work without an internet connection more often
> > >>>>> than we would like, so any solution that requires being online
> > >>>>> won't work.
> > >>>>> 
> > >>>>> Emails provide all that, there may be good options I just fail to
> > >>>>> think about right now.  
> > >>>> 
> > >>>> One more requirement I would add is that messages should be
> > >>>> archived, and should have a first class search system.  We should be
> > >>>> able to reference a commit id in a communications thread, and then a
> > >>>> search for that commit id (or commit description) should be able to
> > >>>> turn up that message, and from there, be able to see the rest of the
> > >>>> messages on that thread.
> > >>>> 
> > >>>> Being able to find the "legislative history" behind a particular
> > >>>> change in the kernel is super-important.  
> > >>> 
> > >>> Fully agreed. I would even go one step further, I'd like a system
> > >>> where relationships between messages are kept. This obviously means
> > >>> linking patches from the same series, but also detecting new versions
> > >>> of patch series (to the extent possible, as already discussed in this
> > >>> mail thread).  
> > >> 
> > >> Let me go one step down.
> > >> 
> > >> While I do agree that the main Kernel development should happen via
> > >> email on the foreseen future, Why e-mail would be a mandatory
> > >> requirement for all kinds of Kernel development?  
> 
> Nothing in the list of requirements above mandates e-mail, it just happens 
> that e-mail fits them at the moment.
> 
> > >> I don't believe that a single development model fits all cases.
> > >> 
> > >> Let's say that someone is using something like github to manage the
> > >> development of a single driver - or even a low traffic subsystem.  
> 
> Please note that Daniel specifically mentioned gitlab, not github, and 
> explained how the github model wouldn't fit our needs.

Yes, I saw Daniel's email. Well, gitlab may fit better for DRM, but
other developers may have different preferences [1].

I don't think we should (or we can) force everybody to use a single
development model.

[1] IMO, adopting gitlab/github/whatever-web-UI for a high traffic
subsystem like DRM or media is a completely different beast: one has
to do enough tests that this would work before start any migration, and
it should  ensure that the usual e-mail workflow submission and patch
review will keep working as before, as the rest of the Kernel community
won't change their workflow.

> > >> The communication traffic between the developers there is usually
> > >> not relevant (nor wanted) at LKML.  
> 
> Not on LKML, but it should be public, searchable and mirrored, not hidden 
> behind an authentication, or stored in a single location.

Yeah, being public and searchable are important features.

However, nowadays, the concept of "stored in a single location" is
something that doesn't make much sense: most of stuff are stored on
clouds, specially if one is using a big service provider. On a cloud
service, the concept of "mirrored" also is not relevant: a single
URL usually is handled by multiple servers. Usually, it is invisible
to the users what is the real infrastructure behind the service.

> > >> What we usually do on normal subsystems is to have those discussions
> > >> "filtered" on a separate mailing list. I don't see why not use a
> > >> web-based interface for such purpose.  
> 
> There are multiple reasons. One of them is that you'll lose the whole history 
> the day the project is deleted from gitlab, github or any other single 
> provider. 

This can happen whatever infra is used. That's why the git logs should be
clear enough to not depend on it. I'm pretty sure that, whatever we use
nowadays (even mirrored ML logs) will some day be replaced by something
else. Try to seek, for example, for the old usenet messages. The only
thing that is more warranted to survive as time goes by are the patch
logs.

> Another one is that it requires drive-by contributors to log in to 
> different web UIs to submit patches to different subsystems (and from my point 
> of view even a single web UI is too much). As soon as you require people to 
> pull content instead of getting it in their mailbox (or whatever alternative 
> to e-mail we would come up with), you've lost.

This is a valid point: whatever development process is used, drive-by
contributors should be allowed to send e-mails without needing to subscribe
(neither to a moderated list nor to a web-UI). I don't care how the 
maintainer will handle such patches, provided that they will be properly
handled.

> > >> Btw, that's not that different on what happens on some companies that
> > > It's a good idea to always CC lkml when submitting a patch for a bug in
> > > the driver.  
> > 
> > True, but this doesn't always happen. If it happens, nothing prevents
> > that someone would use a "man-handled copy-and-paste interface"
> > between e-mail and web.
> > 
> > Btw, this happens already, even with e-mail: from time to time, we
> > receive bug reports on media from something reported via distro bug
> > tracks (bugzilla, Trac, ...).
> > 
> > Even when the bug tracking system has an email interface
> > (Red Hat BZ has, for example), it is really rare to use email
> > for tracked bug reports (even from Kernel.org bugzilla).
> > 
> > What works in practice for such bugs is that we end by using web
> > interfaces if we need to talk about the bug inside the tracker
> > system, or via e-mail if we want to talk about it subsystem-wide.
> > 
> > Sub-optimal, but it works.  
> 
> That makes our work more difficult, due to the lack of integration between the 
> bug tracker and our usual workflow. Bugs reported through bug trackers are 
> often handled as second-class citizens for that reason.
> 
> > The same would happen if the development discussions would happen
> > inside a web interface like github/gitlab. Of course, the maintainer
> > would still need to be reachable by e-mail.  
> 
> If your point is that it would be similarly painful, I agree :-) (or to be 
> honest I'm concerned it would be even more painful, but certainly not less).

Actually, I think it could be less painful on drivers than git+kernel BZ
if the developers of such driver/subsystem are all using their web-UI
and they only receive a handful contributions from "outside world", as
the bugs will be tracked by the same interface. That won't be the case 
of larger subsystems like media, DRM, net, sound, etc.

Thanks,
Mauro

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

[Mauro Carvalho Chehab]

Em Mon, 17 Sep 2018 16:50:23 +0200
Geert Uytterhoeven <geert@linux-m68k.org> escreveu:

> Hi Christoph,
> 
> On Mon, Sep 17, 2018 at 4:18 PM Christoph Hellwig <hch@infradead.org> wrote:
> > On Mon, Sep 17, 2018 at 10:58:05AM -0300, Mauro Carvalho Chehab wrote:  
> > > > > specifically).  The only problem is that people tend to omit context,
> > > > > because they assume that you see the code or previous messages that they
> > > > > see in the web interface, which you do not.  
> > > >
> > > > The major problem with github is that as far as I can tell there is no
> > > > way to interact with it without creating an account.  
> > >
> > > Well, the same happens with moderated mailing lists. There are a
> > > lot of them:
> > >       $ git grep moderated MAINTAINERS|wc -l
> > >       221  
> >
> > Note that moderated doesn't mean that it always rejects non-subscribers.
> > For example I post to linux-arm-kernel frequently, and my mails always
> > seem to make it through with a delay.  

Yeah, same happens to me. I stopped receiving emails from several such
lists. Not sure if I ended by subscribing to it (in order to actively
participate on some discussions) or if my email was simply whitelisted.

> linux-arm-kernel is a gateway to many maintainers, most of them will take
> your patches fine.
> 
> But if it is for core ARM, it still has to be submitted to the ARM patch system
> separately.

Provided that get_maintainers.pl gets it, and someone will manually
whitelist either my e-mail or my patch on an eventual patch
submission, no issues with that.

Thanks,
Mauro

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

[Joe Perches]

On Mon, 2018-09-17 at 10:58 -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 17 Sep 2018 06:29:08 -0700
> Christoph Hellwig <hch@infradead.org> escreveu:
> 
> > On Mon, Sep 17, 2018 at 03:10:50PM +0200, Julia Lawall wrote:
> > > > Btw, on a quick look, it seems that github has/had an email
> > > > interface already:
> > > > 	https://blog.github.com/2011-03-10-reply-to-comments-from-email/  
> > > 
> > > I only interact with issues posted to github via email (alpine
> > > specifically).  The only problem is that people tend to omit context,
> > > because they assume that you see the code or previous messages that they
> > > see in the web interface, which you do not.  
> > 
> > The major problem with github is that as far as I can tell there is no
> > way to interact with it without creating an account.
> 
> Well, the same happens with moderated mailing lists. There are a
> lot of them:
> 	$ git grep moderated MAINTAINERS|wc -l
> 	221

moderation doesn't mean rejection by non-subscribers and
it's nowhere near that number.

$ git grep -i moderated MAINTAINERS | sort | uniq -c | wc -l
32

Most all of those have public archives too.

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

[Rafael J. Wysocki]

On Monday, September 17, 2018 3:12:18 PM CEST Christoph Hellwig wrote:
> On Mon, Sep 17, 2018 at 08:43:35AM -0300, Mauro Carvalho Chehab wrote:
> > While I do agree that the main Kernel development should happen via
> > email on the foreseen future, Why e-mail would be a mandatory
> > requirement for all kinds of Kernel development? 
> > 
> > I don't believe that a single development model fits all cases.
> > 
> > Let's say that someone is using something like github to manage the
> > development of a single driver - or even a low traffic subsystem.
> 
> Sadly enough that already is the case.  The ACPI maintainers refuse
> to take perfectly fine patches and instead redirect people to a
> github version (which doesn't look like the kernel code at all),
> which requires a signup with a not exactly trust-worthy webservice.

That's ACPICA to be precise and that's because it is a separate project really
that's used by the kernel.  It generally is better to get patches to the
upstream first and to the kernel from there.

That's nothing new, though, it's been like that for years.

Cheers,
Rafael

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

[Rafael J. Wysocki]

On Monday, September 17, 2018 11:59:22 PM CEST Rafael J. Wysocki wrote:
> On Monday, September 17, 2018 3:12:18 PM CEST Christoph Hellwig wrote:
> > On Mon, Sep 17, 2018 at 08:43:35AM -0300, Mauro Carvalho Chehab wrote:
> > > While I do agree that the main Kernel development should happen via
> > > email on the foreseen future, Why e-mail would be a mandatory
> > > requirement for all kinds of Kernel development? 
> > > 
> > > I don't believe that a single development model fits all cases.
> > > 
> > > Let's say that someone is using something like github to manage the
> > > development of a single driver - or even a low traffic subsystem.
> > 
> > Sadly enough that already is the case.  The ACPI maintainers refuse
> > to take perfectly fine patches and instead redirect people to a
> > github version (which doesn't look like the kernel code at all),
> > which requires a signup with a not exactly trust-worthy webservice.
> 
> That's ACPICA to be precise and that's because it is a separate project really
> that's used by the kernel.  It generally is better to get patches to the
> upstream first and to the kernel from there.
> 
> That's nothing new, though, it's been like that for years.

Also they do take patches from email (they may not prefer to do it this way,
but still), but those patches need to be against the upstream code base
which, indeed, uses a different coding style and other conventions.

Cheers,
Rafael

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

[Dave Airlie]

> This is a valid point: whatever development process is used, drive-by
> contributors should be allowed to send e-mails without needing to subscribe
> (neither to a moderated list nor to a web-UI). I don't care how the
> maintainer will handle such patches, provided that they will be properly
> handled.
>
It really depends on what type of one-off contributor they are.

Setting up git send-email isn't trivial for everyone, if you are a
gmail user and work for a company that doesn't embrace smtp so much,
then having a webui and https git access will be a lot easier for
one-off contributions.

Beware of thinking our setup with email is in any way simple for a
newcomer to setup properly.

Dave.

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

[James Bottomley]

On September 17, 2018 4:39:48 PM MST, Dave Airlie <airlied@gmail.com> wrote:
>> This is a valid point: whatever development process is used, drive-by
>> contributors should be allowed to send e-mails without needing to
>subscribe
>> (neither to a moderated list nor to a web-UI). I don't care how the
>> maintainer will handle such patches, provided that they will be
>properly
>> handled.
>>
>It really depends on what type of one-off contributor they are.
>
>Setting up git send-email isn't trivial for everyone, if you are a
>gmail user and work for a company that doesn't embrace smtp so much,
>then having a webui and https git access will be a lot easier for
>one-off contributions.

Agree with this but that's why I don't use git-send-email

>Beware of thinking our setup with email is in any way simple for a
>newcomer to setup properly.

Right, but there are many other ways of doing this which still work with mailing lists.


James

>Dave.
>_______________________________________________
>Ksummit-discuss mailing list
>Ksummit-discuss@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Nicolas Ferre]

On 18/09/2018 at 00:39, Dave Airlie wrote:
>> This is a valid point: whatever development process is used, drive-by
>> contributors should be allowed to send e-mails without needing to subscribe
>> (neither to a moderated list nor to a web-UI). I don't care how the
>> maintainer will handle such patches, provided that they will be properly
>> handled.
>>
> It really depends on what type of one-off contributor they are.
> 
> Setting up git send-email isn't trivial for everyone, if you are a
> gmail user and work for a company that doesn't embrace smtp so much,

Indeed, an always recommencing uphill battle of Open Source group of 
engineers in an "Enterprise" environment...

> then having a webui and https git access will be a lot easier for
> one-off contributions.
> 
> Beware of thinking our setup with email is in any way simple for a
> newcomer to setup properly.
> 
> Dave.
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> 


-- 
Nicolas Ferre

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

[Geert Uytterhoeven]

On Tue, Sep 18, 2018 at 9:37 AM Nicolas Ferre
<nicolas.ferre@microchip.com> wrote:
> On 18/09/2018 at 00:39, Dave Airlie wrote:
> >> This is a valid point: whatever development process is used, drive-by
> >> contributors should be allowed to send e-mails without needing to subscribe
> >> (neither to a moderated list nor to a web-UI). I don't care how the
> >> maintainer will handle such patches, provided that they will be properly
> >> handled.
> >>
> > It really depends on what type of one-off contributor they are.
> >
> > Setting up git send-email isn't trivial for everyone, if you are a
> > gmail user and work for a company that doesn't embrace smtp so much,
>
> Indeed, an always recommencing uphill battle of Open Source group of
> engineers in an "Enterprise" environment...

This is not limited to Open Source cooperation.

When people from multiple companies are working together in other areas,
it is not uncommon for some of them to be blocked from access to collaboration
tools in the same "Enterprise" environment.

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: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance

[Daniel Vetter]

On Tue, Sep 18, 2018 at 1:04 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On September 17, 2018 4:39:48 PM MST, Dave Airlie <airlied@gmail.com> wrote:
>>> This is a valid point: whatever development process is used, drive-by
>>> contributors should be allowed to send e-mails without needing to
>>subscribe
>>> (neither to a moderated list nor to a web-UI). I don't care how the
>>> maintainer will handle such patches, provided that they will be
>>properly
>>> handled.
>>>
>>It really depends on what type of one-off contributor they are.
>>
>>Setting up git send-email isn't trivial for everyone, if you are a
>>gmail user and work for a company that doesn't embrace smtp so much,
>>then having a webui and https git access will be a lot easier for
>>one-off contributions.
>
> Agree with this but that's why I don't use git-send-email
>
>>Beware of thinking our setup with email is in any way simple for a
>>newcomer to setup properly.
>
> Right, but there are many other ways of doing this which still work with mailing lists.

Aside from bare diffs stuffed into plaintext mails directly (which I
is a lot harder to set up than git send-email for new people), what
else is there that works with mailing lists? I'd be great if we have
other options here, since it is a fairly annoying problem for us.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Eric W. Biederman]

Mauro Carvalho Chehab <mchehab+samsung@kernel.org> writes:

> Em Mon, 17 Sep 2018 17:14:29 +0300
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
>
>> On Monday, 17 September 2018 16:04:13 EEST Mauro Carvalho Chehab wrote:
>> > Em Mon, 17 Sep 2018 14:03:55 +0200 Geert Uytterhoeven escreveu:  
>> > > On Mon, Sep 17, 2018 at 1:43 PM Mauro Carvalho Chehab wrote:  

>> > >> The communication traffic between the developers there is usually
>> > >> not relevant (nor wanted) at LKML.  
>> 
>> Not on LKML, but it should be public, searchable and mirrored, not hidden 
>> behind an authentication, or stored in a single location.
>
> Yeah, being public and searchable are important features.
>
> However, nowadays, the concept of "stored in a single location" is
> something that doesn't make much sense: most of stuff are stored on
> clouds, specially if one is using a big service provider. On a cloud
> service, the concept of "mirrored" also is not relevant: a single
> URL usually is handled by multiple servers. Usually, it is invisible
> to the users what is the real infrastructure behind the service.

But "single point of failure" continues to be relevant.  It is straight
forward to have a personal archive of a mailing list.  Not so much with
other solutions.

>> > >> What we usually do on normal subsystems is to have those discussions
>> > >> "filtered" on a separate mailing list. I don't see why not use a
>> > >> web-based interface for such purpose.  
>> 
>> There are multiple reasons. One of them is that you'll lose the whole history 
>> the day the project is deleted from gitlab, github or any other single 
>> provider. 
>
> This can happen whatever infra is used. That's why the git logs should be
> clear enough to not depend on it. I'm pretty sure that, whatever we use
> nowadays (even mirrored ML logs) will some day be replaced by something
> else. Try to seek, for example, for the old usenet messages. The only
> thing that is more warranted to survive as time goes by are the patch
> logs.

It is absolutely reasonable to expect discussions to be public and to
build the infrastructure to make it happen.  Certainly such archives
have been invaluable in my work on the kernel for tracking down why do
the things that we do in the kernel.

One of the more interesting developments in this area recently is the
public-inbox project, and it's use in lore.kernel.org.  I know have all
of the archives of linux-kernel sitting in a little git archive on my
laptop.  Depending on what I am doing a local git-grep can be more
productive than looking at the the nice searchable web archive.

It is my hope that as this method of mirroring and archiving a mailling
list become more common sites like github and gitlab will adopt similar
strategies for the discussion that happen on their sites.

Eric

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

[Laurent Pinchart]

On Tuesday, 18 September 2018 01:39:48 EEST Dave Airlie wrote:
> > This is a valid point: whatever development process is used, drive-by
> > contributors should be allowed to send e-mails without needing to
> > subscribe
> > (neither to a moderated list nor to a web-UI). I don't care how the
> > maintainer will handle such patches, provided that they will be properly
> > handled.
> 
> It really depends on what type of one-off contributor they are.
> 
> Setting up git send-email isn't trivial for everyone, if you are a
> gmail user and work for a company that doesn't embrace smtp so much,
> then having a webui and https git access will be a lot easier for
> one-off contributions.
> 
> Beware of thinking our setup with email is in any way simple for a
> newcomer to setup properly.

Would there be some value in creating new git-send-gmail or git-send-outlook 
scripts that would work around the issues with common mail providers ?

-- 
Regards,

Laurent Pinchart

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

[James Bottomley]

On Tue, 2018-09-18 at 10:00 +0200, Daniel Vetter wrote:
> On Tue, Sep 18, 2018 at 1:04 AM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On September 17, 2018 4:39:48 PM MST, Dave Airlie <airlied@gmail.co
> > m> wrote:
> > > > This is a valid point: whatever development process is used,
> > > > drive-by contributors should be allowed to send e-mails without
> > > > needing to
> > > 
> > > subscribe
> > > > (neither to a moderated list nor to a web-UI). I don't care how
> > > > the maintainer will handle such patches, provided that they
> > > > will be
> > > 
> > > properly handled.
> > > > 
> > > 
> > > It really depends on what type of one-off contributor they are.
> > > 
> > > Setting up git send-email isn't trivial for everyone, if you are
> > > a gmail user and work for a company that doesn't embrace smtp so
> > > much, then having a webui and https git access will be a lot
> > > easier for one-off contributions.
> > 
> > Agree with this but that's why I don't use git-send-email
> > 
> > > Beware of thinking our setup with email is in any way simple for
> > > a newcomer to setup properly.
> > 
> > Right, but there are many other ways of doing this which still work
> > with mailing lists.
> 
> Aside from bare diffs stuffed into plaintext mails directly (which I
> is a lot harder to set up than git send-email for new people),

Well, that is how I do it: git format-patch followed by preformatted
text insertion in evolution.  I've got to say I don't find it at all
hard, but I do understand if you use outlook or gmail it can be a pain.

>  what else is there that works with mailing lists? I'd be great if we
> have other options here, since it is a fairly annoying problem for
> us.

This is more about mail tools than actual lists, isn't it?  In which
case I find the Documentation/email-clients.txt and invaluable resource
 to point people to (wait, where is it now, ah:
Documentation/process/email-clients.rst)

James

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

[Randy Dunlap]

On 9/18/18 4:16 AM, James Bottomley wrote:
> On Tue, 2018-09-18 at 10:00 +0200, Daniel Vetter wrote:
>> On Tue, Sep 18, 2018 at 1:04 AM, James Bottomley
>> <James.Bottomley@hansenpartnership.com> wrote:
>>> On September 17, 2018 4:39:48 PM MST, Dave Airlie <airlied@gmail.co
>>> m> wrote:
>>>>> This is a valid point: whatever development process is used,
>>>>> drive-by contributors should be allowed to send e-mails without
>>>>> needing to
>>>>
>>>> subscribe
>>>>> (neither to a moderated list nor to a web-UI). I don't care how
>>>>> the maintainer will handle such patches, provided that they
>>>>> will be
>>>>
>>>> properly handled.
>>>>>
>>>>
>>>> It really depends on what type of one-off contributor they are.
>>>>
>>>> Setting up git send-email isn't trivial for everyone, if you are
>>>> a gmail user and work for a company that doesn't embrace smtp so
>>>> much, then having a webui and https git access will be a lot
>>>> easier for one-off contributions.
>>>
>>> Agree with this but that's why I don't use git-send-email
>>>
>>>> Beware of thinking our setup with email is in any way simple for
>>>> a newcomer to setup properly.
>>>
>>> Right, but there are many other ways of doing this which still work
>>> with mailing lists.
>>
>> Aside from bare diffs stuffed into plaintext mails directly (which I
>> is a lot harder to set up than git send-email for new people),
> 
> Well, that is how I do it: git format-patch followed by preformatted
> text insertion in evolution.  I've got to say I don't find it at all
> hard, but I do understand if you use outlook or gmail it can be a pain.

Ack.  I use git send-email for a series, but for single patches,
it's more of a pain than just using an email client.

>>  what else is there that works with mailing lists? I'd be great if we
>> have other options here, since it is a fairly annoying problem for
>> us.
> 
> This is more about mail tools than actual lists, isn't it?  In which
> case I find the Documentation/email-clients.txt and invaluable resource
>  to point people to (wait, where is it now, ah:
> Documentation/process/email-clients.rst)

Thanks.

-- 
~Randy

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

On Tue, Sep 18, 2018 at 01:38:09PM +0300, Laurent Pinchart wrote:

> Would there be some value in creating new git-send-gmail or git-send-outlook 
> scripts that would work around the issues with common mail providers ?

At least with Outlook the problem is partly that Outlook's model of how
e-mail works isn't really able to cope with what we need, it translates
everything into internal formats in a way that is at best fragile for
what we need.

A while ago Tim Bird (CCed) had the idea to release a VM image which
sysadmins could easily deploy inside a company providing services that'd
be needed to interact with the community - things like a mechanism to
send and recieve e-mail.  The theory was that something that was nicely
packaged, documented and auditable would be more approachable for
corporate admins who aren't experts.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Luck, Tony]

On Tue, Sep 18, 2018 at 09:02:36AM -0700, Mark Brown wrote:
> At least with Outlook the problem is partly that Outlook's model of how
> e-mail works isn't really able to cope with what we need, it translates
> everything into internal formats in a way that is at best fragile for
> what we need.

Or, shock, horror, tell one-time contributors that it is OK to
put the patch in an attachment to the e-mail.  Outlook doesn't
(usually) mess with the contents of attachments.

-Tony

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

[Dmitry Torokhov]

On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony <tony.luck@intel.com> wrote:
>
> On Tue, Sep 18, 2018 at 09:02:36AM -0700, Mark Brown wrote:
> > At least with Outlook the problem is partly that Outlook's model of how
> > e-mail works isn't really able to cope with what we need, it translates
> > everything into internal formats in a way that is at best fragile for
> > what we need.
>
> Or, shock, horror, tell one-time contributors that it is OK to
> put the patch in an attachment to the e-mail.  Outlook doesn't
> (usually) mess with the contents of attachments.

And then have maintainer having hard time trying to comment on said
patch in the attachment. I'd rather not.

Thanks.

-- 
Dmitry

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

[Tim.Bird]

> -----Original Message-----
> From: James Bottomley
> 
> On Tue, 2018-09-18 at 10:00 +0200, Daniel Vetter wrote:
> > On Tue, Sep 18, 2018 at 1:04 AM, James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > > On September 17, 2018 4:39:48 PM MST, Dave Airlie <airlied@gmail.co
> > > m> wrote:
> > > > > This is a valid point: whatever development process is used,
> > > > > drive-by contributors should be allowed to send e-mails without
> > > > > needing to
> > > >
> > > > subscribe
> > > > > (neither to a moderated list nor to a web-UI). I don't care how
> > > > > the maintainer will handle such patches, provided that they
> > > > > will be
> > > >
> > > > properly handled.
> > > > >
> > > >
> > > > It really depends on what type of one-off contributor they are.
> > > >
> > > > Setting up git send-email isn't trivial for everyone, if you are
> > > > a gmail user and work for a company that doesn't embrace smtp so
> > > > much, then having a webui and https git access will be a lot
> > > > easier for one-off contributions.
> > >
> > > Agree with this but that's why I don't use git-send-email
> > >
> > > > Beware of thinking our setup with email is in any way simple for
> > > > a newcomer to setup properly.
> > >
> > > Right, but there are many other ways of doing this which still work
> > > with mailing lists.
> >
> > Aside from bare diffs stuffed into plaintext mails directly (which I
> > is a lot harder to set up than git send-email for new people),
> 
> Well, that is how I do it: git format-patch followed by preformatted
> text insertion in evolution.  I've got to say I don't find it at all
> hard, but I do understand if you use outlook or gmail it can be a pain.
> 
> >  what else is there that works with mailing lists? I'd be great if we
> > have other options here, since it is a fairly annoying problem for
> > us.
> 
> This is more about mail tools than actual lists, isn't it?  In which
> case I find the Documentation/email-clients.txt and invaluable resource
>  to point people to (wait, where is it now, ah:
> Documentation/process/email-clients.rst)

Well, it's more than just the mail tool - it's the entire enterprise e-mail
infrastructure where problems can crop up.  Sony's IT department recently
installed a system to help prevent phishing attacks which re-writes all the URLs in
every e-mail that goes through the system.  This is patch-unfriendly, to say the least.
I'm working with IT to try to get myself exempted from this "service",
but it affects every Sony employee who wishes to use corporate
e-mail to collaborate with upstream.  Unfortunately, this type of
thing is fairly common.

For my part, I wish there were a gateway I could send through, that would
undo all the mumbo-jumbo that exchange and the like introduce (text re-flowing,
uuencoding, url-rewriting, etc.)

Mainstream e-mail infrastructure implementations are increasingly averse to just
delivering raw text from one point to another, so the fundamental assumption
that e-mail is a reliable text delivery service is increasingly unfounded.
 -- Tim

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

On Tue, 2018-09-18 at 09:02 -0700, Mark Brown wrote:
> On Tue, Sep 18, 2018 at 01:38:09PM +0300, Laurent Pinchart wrote:
> 
> > Would there be some value in creating new git-send-gmail or git-send-outlook 
> > scripts that would work around the issues with common mail providers ?
> 
> At least with Outlook the problem is partly that Outlook's model of how
> e-mail works isn't really able to cope with what we need, it translates
> everything into internal formats in a way that is at best fragile for
> what we need.

Outlook is a pile of crap, but Exchange itself works tolerably these
days. It's fairly simple to send and receive patches through Exchange
if you don't make the mistake of using Outlook.

Perhaps I should add an Exchange Web Services back end to
git-send-email so that people can use that instead of SMTP... :)

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

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

[Konstantin Ryabitsev]

On Tue, Sep 18, 2018 at 04:47:00PM +0000, Tim.Bird@sony.com wrote:
>For my part, I wish there were a gateway I could send through, that 
>would
>undo all the mumbo-jumbo that exchange and the like introduce (text re-flowing,
>uuencoding, url-rewriting, etc.)

If you have a kernel.org account (I know you don't, but I'm sure you can 
probably get one, since you used to have one in the past), you can use 
mail.kernel.org for sending outgoing mail:

https://korg.wiki.kernel.org/userdoc/mail#sending_outgoing_mail

-K

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

[Tim.Bird]

> -----Original Message-----
> From: Konstantin Ryabitsev
> On Tue, Sep 18, 2018 at 04:47:00PM +0000, Tim.Bird@sony.com wrote:
> >For my part, I wish there were a gateway I could send through, that
> >would
> >undo all the mumbo-jumbo that exchange and the like introduce (text re-
> flowing,
> >uuencoding, url-rewriting, etc.)
> 
> If you have a kernel.org account (I know you don't, but I'm sure you can
> probably get one, since you used to have one in the past), you can use
> mail.kernel.org for sending outgoing mail:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__korg.wiki.kernel.org_userdoc_mail-23sending-5Foutgoing-
> 5Fmail&d=DwICAg&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-
> GLPtvShAo4cc&r=rUvFawR4KzgZu1gSN5tuozUn7iTTP0Y-
> INWqfY8MsF0&m=90EMZrRfkvlzWBNtrJ8QnHDj3-EwehEZhQiC5YJY-
> Uk&s=xtUgBLn5bjLazevAEIdAoHAGclbgin-D9Cek15hsuZk&e=
> 

Thank you for the offer.  However, while that's a solution that might work
for me (modulo my ability to punch my way through the firewall to that mail
server), it doesn't scale or help my colleagues at Sony who I'm trying to
remove barriers for as well.   I'm senior enough at Sony to have a somewhat
different situation than other Sony Linux developers, however  I intentionally
work through the IT department and use commonly provided tools here
in order to 1) understand the hurdles other developers at Sony have, and
2) work on general solutions.
 -- Tim

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

[Tim.Bird]

> -----Original Message-----
> From: Luck, Tony 
> 
> On Tue, Sep 18, 2018 at 09:02:36AM -0700, Mark Brown wrote:
> > At least with Outlook the problem is partly that Outlook's model of how
> > e-mail works isn't really able to cope with what we need, it translates
> > everything into internal formats in a way that is at best fragile for
> > what we need.
> 
> Or, shock, horror, tell one-time contributors that it is OK to
> put the patch in an attachment to the e-mail.  Outlook doesn't
> (usually) mess with the contents of attachments.

That is what I do on my testing project.  It might be nice to have the
mail list software detect an attached text file, and incorporate it into
the body so reviews could be done in the standard fashion, or to have
git am detect attached messages.
 -- Tim

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

[Tim.Bird]

> -----Original Message-----
> From: Tim.Bird@sony.com
> > -----Original Message-----
> > From: Konstantin Ryabitsev
> > On Tue, Sep 18, 2018 at 04:47:00PM +0000, Tim.Bird@sony.com wrote:
> > >For my part, I wish there were a gateway I could send through, that
> > >would
> > >undo all the mumbo-jumbo that exchange and the like introduce (text re-
> > flowing,
> > >uuencoding, url-rewriting, etc.)
> >
> > If you have a kernel.org account (I know you don't, but I'm sure you can
> > probably get one, since you used to have one in the past), you can use
> > mail.kernel.org for sending outgoing mail:
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__korg.wiki.kernel.org_userdoc_mail-23sending-5Foutgoing-
> > 5Fmail&d=DwICAg&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-
> > GLPtvShAo4cc&r=rUvFawR4KzgZu1gSN5tuozUn7iTTP0Y-
> > INWqfY8MsF0&m=90EMZrRfkvlzWBNtrJ8QnHDj3-EwehEZhQiC5YJY-
> > Uk&s=xtUgBLn5bjLazevAEIdAoHAGclbgin-D9Cek15hsuZk&e=

And yes - I left this URL re-write here intentionally to let you-all see my pain.
Misery loves company. :-)
 -- Tim

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

[Linus Torvalds]

[ Still very much on break, but reading ksuummit-discuss and answering
this one ]

On Tue, Sep 18, 2018 at 9:35 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony <tony.luck@intel.com> wrote:
> >
> > Or, shock, horror, tell one-time contributors that it is OK to
> > put the patch in an attachment to the e-mail.  Outlook doesn't
> > (usually) mess with the contents of attachments.
>
> And then have maintainer having hard time trying to comment on said
> patch in the attachment. I'd rather not.

I actually think that *this* could be easily handled by trivial
tooling that doesn't have to be set up over and over again inside
companies or teaching people.

In fact, doesn't patchwork already do exactly that?

I have to say, there are real technical advantages to using
attachments for patches, particularly when you have odd combinations
of locales. It's gotten to be less of an issue over time and we're
still almost entirely US-ASCII with the occasional UTF-8, but we do
still have the occasional problem. Using attachments at least detaches
the email charset from the user locale, and from random other MUA
issues.

But yes, the "comment on individual parts of the patch" part is very
important too.

The main problem with having something that rewrites things is that it
breaks DKIM etc, so you can't just have a pure email gateway. It
almost needs to be something at a higher semantic level like patchwork
(that could still send out rewritten emails).

In many cases, you might want that anyway (ie wouldn't it be lovely
when the patch is also checked for "does it build" and looks up the
maintainers based on what paths it touches etc etc).

So a sane email / web-interface kind of gateway that allows people to
work the way they prefer.

But I guess "trivial" is completely the wrong word to use.

             Linus

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]

On Tue, Sep 18, 2018 at 09:35:28AM -0700, Dmitry Torokhov wrote:
> On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony <tony.luck@intel.com> wrote:
> > On Tue, Sep 18, 2018 at 09:02:36AM -0700, Mark Brown wrote:

> > > At least with Outlook the problem is partly that Outlook's model of how
> > > e-mail works isn't really able to cope with what we need, it translates
> > > everything into internal formats in a way that is at best fragile for
> > > what we need.

> > Or, shock, horror, tell one-time contributors that it is OK to
> > put the patch in an attachment to the e-mail.  Outlook doesn't
> > (usually) mess with the contents of attachments.

> And then have maintainer having hard time trying to comment on said
> patch in the attachment. I'd rather not.

Right, that can be an issue - things usually make it through without
modification which is good but depending on the e-mail client it can be
a pain to review, especially if the patch ends up not being given a text
MIME type.  It is doable but it's not great.  It also doesn't scale well
in cases where it's a company that's actively engaging and sending a lot
of stuff and participating in discussions.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 826 bytes --]

On Tue, Sep 18, 2018 at 05:50:45PM +0100, David Woodhouse wrote:
> On Tue, 2018-09-18 at 09:02 -0700, Mark Brown wrote:

> > At least with Outlook the problem is partly that Outlook's model of how
> > e-mail works isn't really able to cope with what we need, it translates
> > everything into internal formats in a way that is at best fragile for
> > what we need.

> Outlook is a pile of crap, but Exchange itself works tolerably these
> days. It's fairly simple to send and receive patches through Exchange
> if you don't make the mistake of using Outlook.

Unfortunately some people do get forced into that :(

> Perhaps I should add an Exchange Web Services back end to
> git-send-email so that people can use that instead of SMTP... :)

There's a smiley there but I'm pretty sure that'd be really useful for
some people.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Sean Paul]

On Tue, Sep 18, 2018 at 10:18:25AM -0700, Linus Torvalds wrote:
> [ Still very much on break, but reading ksuummit-discuss and answering
> this one ]
> 
> On Tue, Sep 18, 2018 at 9:35 AM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony <tony.luck@intel.com> wrote:
> > >
> > > Or, shock, horror, tell one-time contributors that it is OK to
> > > put the patch in an attachment to the e-mail.  Outlook doesn't
> > > (usually) mess with the contents of attachments.
> >
> > And then have maintainer having hard time trying to comment on said
> > patch in the attachment. I'd rather not.
> 
> I actually think that *this* could be easily handled by trivial
> tooling that doesn't have to be set up over and over again inside
> companies or teaching people.
> 
> In fact, doesn't patchwork already do exactly that?
> 
> I have to say, there are real technical advantages to using
> attachments for patches, particularly when you have odd combinations
> of locales. It's gotten to be less of an issue over time and we're
> still almost entirely US-ASCII with the occasional UTF-8, but we do
> still have the occasional problem. Using attachments at least detaches
> the email charset from the user locale, and from random other MUA
> issues.
> 
> But yes, the "comment on individual parts of the patch" part is very
> important too.
> 
> The main problem with having something that rewrites things is that it
> breaks DKIM etc, so you can't just have a pure email gateway. 

Worse yet is that the failures are silent. We had DMARC helpfully enabled
on chromium.org for 3 weeks and my mail was going to Spam folders without
me knowing.

Sean

> It
> almost needs to be something at a higher semantic level like patchwork
> (that could still send out rewritten emails).
> 
> In many cases, you might want that anyway (ie wouldn't it be lovely
> when the patch is also checked for "does it build" and looks up the
> maintainers based on what paths it touches etc etc).
> 
> So a sane email / web-interface kind of gateway that allows people to
> work the way they prefer.
> 
> But I guess "trivial" is completely the wrong word to use.
> 
>              Linus
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

[Konstantin Ryabitsev]

On Tue, Sep 18, 2018 at 05:08:02PM +0000, Tim.Bird@sony.com wrote:
>> https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__korg.wiki.kernel.org_userdoc_mail-23sending-5Foutgoing-
>> 5Fmail&d=DwICAg&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-
>> GLPtvShAo4cc&r=rUvFawR4KzgZu1gSN5tuozUn7iTTP0Y-
>> INWqfY8MsF0&m=90EMZrRfkvlzWBNtrJ8QnHDj3-EwehEZhQiC5YJY-
>> Uk&s=xtUgBLn5bjLazevAEIdAoHAGclbgin-D9Cek15hsuZk&e=

Ick.

>Thank you for the offer.  However, while that's a solution that might 
>work
>for me (modulo my ability to punch my way through the firewall to that mail
>server), it doesn't scale or help my colleagues at Sony who I'm trying to
>remove barriers for as well.   I'm senior enough at Sony to have a somewhat
>different situation than other Sony Linux developers, however  I intentionally
>work through the IT department and use commonly provided tools here
>in order to 1) understand the hurdles other developers at Sony have, and
>2) work on general solutions.

Ah, I understand your situation better now.

So, what if we imagine that there's an imaginary web tool that does 
this:

1. Allows people to generate an account
2. Verifies their email address
3. Instructs people how to generate a patch or series of patches
4. Gives a way to upload generated patches
5. Runs checkpatch to make sure there are no errors
6. Runs get_maintainer to find out where the patch(es) should be sent to
7. (Does more imaginary magic, such as looking up message-id references)
8. Mails it out

Would that be useful or solve any problems? Or would that, on the 
contrary, create more problems than it solves?

-K

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

[Tim.Bird]

> -----Original Message-----
> From: Linus Torvalds
> 
> On Tue, Sep 18, 2018 at 9:35 AM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony <tony.luck@intel.com> wrote:
> > >
> > > Or, shock, horror, tell one-time contributors that it is OK to
> > > put the patch in an attachment to the e-mail.  Outlook doesn't
> > > (usually) mess with the contents of attachments.
> >
> > And then have maintainer having hard time trying to comment on said
> > patch in the attachment. I'd rather not.
> 
> I actually think that *this* could be easily handled by trivial
> tooling that doesn't have to be set up over and over again inside
> companies or teaching people.
> 
> In fact, doesn't patchwork already do exactly that?
> 
> I have to say, there are real technical advantages to using
> attachments for patches, particularly when you have odd combinations
> of locales. It's gotten to be less of an issue over time and we're
> still almost entirely US-ASCII with the occasional UTF-8, but we do
> still have the occasional problem. Using attachments at least detaches
> the email charset from the user locale, and from random other MUA
> issues.
> 
> But yes, the "comment on individual parts of the patch" part is very
> important too.
> 
> The main problem with having something that rewrites things is that it
> breaks DKIM etc, so you can't just have a pure email gateway. It
> almost needs to be something at a higher semantic level like patchwork
> (that could still send out rewritten emails).
> 
> In many cases, you might want that anyway (ie wouldn't it be lovely
> when the patch is also checked for "does it build" and looks up the
> maintainers based on what paths it touches etc etc).
> 
> So a sane email / web-interface kind of gateway that allows people to
> work the way they prefer.

Would it suffice to have some front-end e-mail receiver, listed in 
MAINTAINERS even, where patches were sent to, that did patch
processing (including CI stuff) before sending it on to the "official"
list?  It could also automatically send responses to submitters with
things to fix.  That would be good for both the senders and the receivers.
I'm not that familiar with 0day, but it does some of this now, right,
but without the separate e-mail address?

The benefit of putting together this kind of gateway is that it clearly
delineates where the automatic patch pre-processing will occur,
and different sub-systems could opt in or out of individual checks
by the service.
 -- Tim

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

[Tim.Bird]

> -----Original Message-----
> From: Konstantin Ryabitsev 
> 
> On Tue, Sep 18, 2018 at 05:08:02PM +0000, Tim.Bird@sony.com wrote:
> >> https://urldefense.proofpoint.com/v2/url?u=https-
> >> 3A__korg.wiki.kernel.org_userdoc_mail-23sending-5Foutgoing-
> >> 5Fmail&d=DwICAg&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-
> >> GLPtvShAo4cc&r=rUvFawR4KzgZu1gSN5tuozUn7iTTP0Y-
> >> INWqfY8MsF0&m=90EMZrRfkvlzWBNtrJ8QnHDj3-EwehEZhQiC5YJY-
> >> Uk&s=xtUgBLn5bjLazevAEIdAoHAGclbgin-D9Cek15hsuZk&e=
> 
> Ick.
Thanks.  I appreciate the sympathy. :-)

> 
> >Thank you for the offer.  However, while that's a solution that might
> >work
> >for me (modulo my ability to punch my way through the firewall to that mail
> >server), it doesn't scale or help my colleagues at Sony who I'm trying to
> >remove barriers for as well.   I'm senior enough at Sony to have a somewhat
> >different situation than other Sony Linux developers, however  I
> intentionally
> >work through the IT department and use commonly provided tools here
> >in order to 1) understand the hurdles other developers at Sony have, and
> >2) work on general solutions.
> 
> Ah, I understand your situation better now.
> 
> So, what if we imagine that there's an imaginary web tool that does
> this:
> 
> 1. Allows people to generate an account
> 2. Verifies their email address
> 3. Instructs people how to generate a patch or series of patches
> 4. Gives a way to upload generated patches
> 5. Runs checkpatch to make sure there are no errors
> 6. Runs get_maintainer to find out where the patch(es) should be sent to
> 7. (Does more imaginary magic, such as looking up message-id references)
> 8. Mails it out
> 
> Would that be useful or solve any problems? Or would that, on the
> contrary, create more problems than it solves?

Konstantin,

I feel like this thread re-converged and you proposed the exact thing I just
expressed interest in to Linus.  You were probably writing your message at
the same time I was writing mine.  Wow!

Personally, I feel this would be a GREAT thing.

I'm not a kernel maintainer, and I think that there would have to be maintainer
buy-in for this.  So I'm interested what others think.
 -- Tim
 

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

[Geert Uytterhoeven]

[ To/Cc edited manually, Mail-Followup-To: seems to be weird ]

On Tue, Sep 18, 2018 at 7:31 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> On Tue, Sep 18, 2018 at 05:08:02PM +0000, Tim.Bird@sony.com wrote:
> >> https://urldefense.proofpoint.com/v2/url?u=https-
> >> 3A__korg.wiki.kernel.org_userdoc_mail-23sending-5Foutgoing-
> >> 5Fmail&d=DwICAg&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-
> >> GLPtvShAo4cc&r=rUvFawR4KzgZu1gSN5tuozUn7iTTP0Y-
> >> INWqfY8MsF0&m=90EMZrRfkvlzWBNtrJ8QnHDj3-EwehEZhQiC5YJY-
> >> Uk&s=xtUgBLn5bjLazevAEIdAoHAGclbgin-D9Cek15hsuZk&e=
>
> Ick.

Cool. And that URL actually works for me, even though wget truncated it.
Can't see any damage in the actual result.

But, is the service exploitable?

> So, what if we imagine that there's an imaginary web tool that does
> this:
>
> 1. Allows people to generate an account
> 2. Verifies their email address
> 3. Instructs people how to generate a patch or series of patches
> 4. Gives a way to upload generated patches
> 5. Runs checkpatch to make sure there are no errors
> 6. Runs get_maintainer to find out where the patch(es) should be sent to
> 7. (Does more imaginary magic, such as looking up message-id references)
> 8. Mails it out
>
> Would that be useful or solve any problems? Or would that, on the
> contrary, create more problems than it solves?

Sounds useful. Perhaps even with github integration, so you can send a
series with the work in your branch? Needs some serious safeguards, to
prevent spamming everyone with e.g. the full patch series since v2.6.12-rc2.

I'm actually surprised such an accident never happened so far with
git send-email ;-)

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: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance

[Greg KH]

On Tue, Sep 18, 2018 at 01:31:48PM -0400, Konstantin Ryabitsev wrote:
> So, what if we imagine that there's an imaginary web tool that does this:
> 
> 1. Allows people to generate an account
> 2. Verifies their email address
> 3. Instructs people how to generate a patch or series of patches
> 4. Gives a way to upload generated patches
> 5. Runs checkpatch to make sure there are no errors
> 6. Runs get_maintainer to find out where the patch(es) should be sent to
> 7. (Does more imaginary magic, such as looking up message-id references)
> 8. Mails it out

That last step might be hard, you have to "mail it out" to look like it
came from the original author, right?  Then all crud breaks out as you
can't deliver an email from "sony.com" successfully.

So you just provide them with a FOO1234@k.o account or some such
munging, to reflect back to their original email address, but what
happens when I ask for a change?  Are you now a "man in the middle"
forwarding emails around everywhere?  That could get messy quickly.

It's that feedback loop where things break down.  I only accept on
average, 1/3 of the patches sent to me, so retrys are a part of life, as
is a conversation about what went wrong to deserve a retry.

If you can incorporate that, great, we just invented gerrit!  :)

Seriously, it would be good, but no gerrit please...

greg k-h

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

[Konstantin Ryabitsev]

[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]

On Tue, Sep 18, 2018 at 05:42:57PM +0000, Tim.Bird@sony.com wrote:
>> So, what if we imagine that there's an imaginary web tool that does
>> this:
>>
>> 1. Allows people to generate an account
>> 2. Verifies their email address
>> 3. Instructs people how to generate a patch or series of patches
>> 4. Gives a way to upload generated patches
>> 5. Runs checkpatch to make sure there are no errors
>> 6. Runs get_maintainer to find out where the patch(es) should be sent to
>> 7. (Does more imaginary magic, such as looking up message-id references)
>> 8. Mails it out
>>
>> Would that be useful or solve any problems? Or would that, on the
>> contrary, create more problems than it solves?
>
>Konstantin,
>
>I feel like this thread re-converged and you proposed the exact thing I just
>expressed interest in to Linus.  You were probably writing your message at
>the same time I was writing mine.  Wow!
>
>Personally, I feel this would be a GREAT thing.

Okay, tacking on some more imaginary features on top of this, let's say 
it also had a way to add a remotely hosted git tree to your account, 
e.g.:

https://github.com/somecorp/linux-corpfidget.git alias corpfidget

It could then offer a CLI utility to issue a command like this using the 
https API:

vapor-git-thingy -g corpfidget -r 1234abcd..5678dcba -v2 -c coverletter.txt

That would do the same as the above, plus do the patch generation 
itself...

Okay, I think I might be able to scrape up funding to get this built 
once I put this into a more presentable form.

-K

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Konstantin Ryabitsev]

[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]

On Tue, Sep 18, 2018 at 07:49:13PM +0200, Greg KH wrote:
>> 1. Allows people to generate an account
>> 2. Verifies their email address
>> 3. Instructs people how to generate a patch or series of patches
>> 4. Gives a way to upload generated patches
>> 5. Runs checkpatch to make sure there are no errors
>> 6. Runs get_maintainer to find out where the patch(es) should be sent to
>> 7. (Does more imaginary magic, such as looking up message-id references)
>> 8. Mails it out
>
>That last step might be hard, you have to "mail it out" to look like it
>came from the original author, right?  Then all crud breaks out as you
>can't deliver an email from "sony.com" successfully.

We already do nasty things to work around this. E.g. if you look at the 
envelope-sender for mail delivered via mail.kernel.org you'll see that 
it all looks like this: 
SRS0=crc=stuff=orig-domain.com=orig-local@kernel.org

So, mailing it out and having it pass DKIM/SPF checks to be reliably 
delivered is something we can do. Or, we can send it from 
"vapor-git-thingy@kernel.org" and put the original sender into Reply-To, 
which is also kosher.

>So you just provide them with a FOO1234@k.o account or some such
>munging, to reflect back to their original email address, but what
>happens when I ask for a change?  Are you now a "man in the middle"
>forwarding emails around everywhere?  That could get messy quickly.

It a reality we already live in, so it's not like we'd be exposing 
ourselves to anything we aren't exposed to as it is.

>Seriously, it would be good, but no gerrit please...

We'll call it ging for "ging is not gerrit". :)

-K

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Dmitry Torokhov]

On Tue, Sep 18, 2018 at 10:49 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Sep 18, 2018 at 01:31:48PM -0400, Konstantin Ryabitsev wrote:
> > So, what if we imagine that there's an imaginary web tool that does this:
> >
> > 1. Allows people to generate an account
> > 2. Verifies their email address
> > 3. Instructs people how to generate a patch or series of patches
> > 4. Gives a way to upload generated patches
> > 5. Runs checkpatch to make sure there are no errors
> > 6. Runs get_maintainer to find out where the patch(es) should be sent to
> > 7. (Does more imaginary magic, such as looking up message-id references)
> > 8. Mails it out
>
> That last step might be hard, you have to "mail it out" to look like it
> came from the original author, right?  Then all crud breaks out as you
> can't deliver an email from "sony.com" successfully.
>
> So you just provide them with a FOO1234@k.o account or some such
> munging, to reflect back to their original email address, but what
> happens when I ask for a change?  Are you now a "man in the middle"
> forwarding emails around everywhere?  That could get messy quickly.
>
> It's that feedback loop where things break down.  I only accept on
> average, 1/3 of the patches sent to me, so retrys are a part of life, as
> is a conversation about what went wrong to deserve a retry.
>
> If you can incorporate that, great, we just invented gerrit!  :)
>
> Seriously, it would be good, but no gerrit please...

Seconded. I swear 75% of time I spend on patch reviews that I do for
Chrome OS is spent on clicking around UI, not actually commenting on
the issues I find.

Thanks.

-- 
Dmitry

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

[Sasha Levin]

On Tue, Sep 18, 2018 at 07:49:13PM +0200, Greg KH wrote:
>On Tue, Sep 18, 2018 at 01:31:48PM -0400, Konstantin Ryabitsev wrote:
>> So, what if we imagine that there's an imaginary web tool that does this:
>>
>> 1. Allows people to generate an account
>> 2. Verifies their email address
>> 3. Instructs people how to generate a patch or series of patches
>> 4. Gives a way to upload generated patches
>> 5. Runs checkpatch to make sure there are no errors
>> 6. Runs get_maintainer to find out where the patch(es) should be sent to
>> 7. (Does more imaginary magic, such as looking up message-id references)
>> 8. Mails it out
>
>That last step might be hard, you have to "mail it out" to look like it
>came from the original author, right?  Then all crud breaks out as you
>can't deliver an email from "sony.com" successfully.

Why do we need to make it look like it came from the original author? If
we include a "From:" field in the patch then git will do the right
thing, and if we just Cc the original author then any
questions/reviews/comments will be directed to the author without going
through this system.

--
Thanks,
Sasha

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

[Tim.Bird]

> -----Original Message-----
> From: Konstantin Ryabitsev 
> On Tue, Sep 18, 2018 at 05:42:57PM +0000, Tim.Bird@sony.com wrote:
> >> So, what if we imagine that there's an imaginary web tool that does
> >> this:
> >>
> >> 1. Allows people to generate an account
> >> 2. Verifies their email address
> >> 3. Instructs people how to generate a patch or series of patches
> >> 4. Gives a way to upload generated patches
> >> 5. Runs checkpatch to make sure there are no errors
> >> 6. Runs get_maintainer to find out where the patch(es) should be sent to
> >> 7. (Does more imaginary magic, such as looking up message-id references)
> >> 8. Mails it out
> >>
> >> Would that be useful or solve any problems? Or would that, on the
> >> contrary, create more problems than it solves?
> >
> >Konstantin,
> >
> >I feel like this thread re-converged and you proposed the exact thing I just
> >expressed interest in to Linus.  You were probably writing your message at
> >the same time I was writing mine.  Wow!
> >
> >Personally, I feel this would be a GREAT thing.
> 
> Okay, tacking on some more imaginary features on top of this, let's say
> it also had a way to add a remotely hosted git tree to your account,
> e.g.:
> 
> https://github.com/somecorp/linux-corpfidget.git alias corpfidget
> 
> It could then offer a CLI utility to issue a command like this using the
> https API:
> 
> vapor-git-thingy -g corpfidget -r 1234abcd..5678dcba -v2 -c coverletter.txt
> 
> That would do the same as the above, plus do the patch generation
> itself...
> 
> Okay, I think I might be able to scrape up funding to get this built
> once I put this into a more presentable form.
That would be great!

This could help solve a lot of e-mail issues that contributors have, but also
I'm very interested in step 5 - the testing aspect.  I would like to be involved in
discussions of the design of that step, so we could plug lots of different tests
in, at the request of various sub-system maintainers.  I maintain the Fuego
test system, so I'd be interested in making available our test suites for that
step.

Please let me know if there's some opportunity to follow up with you on this
( ie, a list where this might be discussed in more detail, or an event where we
could talk face-to-face).

Thanks,
 -- Tim

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

[Theodore Y. Ts'o]

On Tue, Sep 18, 2018 at 11:22:15AM -0700, Dmitry Torokhov wrote:
> > Seriously, it would be good, but no gerrit please...
> 
> Seconded. I swear 75% of time I spend on patch reviews that I do for
> Chrome OS is spent on clicking around UI, not actually commenting on
> the issues I find.

Heh.  I don't know if I'm an outlier, but I actually *like* Gerrit.
(I use it at work for reviewing changes to Google's data center,
Chrome OS, and Android kernels.)

For small changes, being able to directly see the context of a change
via the web UI is really nice.  Also being able to make a comment
in-line where the change is, and then seeing the replies chained off
of it, right next to the code, is also really nice.  I also really
like being able to trivially look at differences between the -v3 and
-v5 version of the commit via the web UI.

It doesn't work as well for large patch series, certainly.  For that
what I tend to do is to download the branch from gerrit into the my
local git repo, and look at all of the changes using standard git
tools (e.g., git grep, git blame, etc.)

So while Gerrit does have some shortcomings, it definitely does have
some things that it does do very well.  For large patch series and for
the sort of things that I need to deal with for upstream development,
I still use e-mail a lot, obviously.  But if we're talking about the
platonic ideal of large-scale distributed development, we shouldn't
dismiss all of Gerrit's functionality out of hand.

Cheers,

						- Ted

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

On Tue, 2018-09-18 at 10:24 -0700, Mark Brown wrote:
> On Tue, Sep 18, 2018 at 05:50:45PM +0100, David Woodhouse wrote:
> > On Tue, 2018-09-18 at 09:02 -0700, Mark Brown wrote:
> > > At least with Outlook the problem is partly that Outlook's model of how
> > > e-mail works isn't really able to cope with what we need, it translates
> > > everything into internal formats in a way that is at best fragile for
> > > what we need.
> > Outlook is a pile of crap, but Exchange itself works tolerably these
> > days. It's fairly simple to send and receive patches through Exchange
> > if you don't make the mistake of using Outlook.
> 
> Unfortunately some people do get forced into that :(

Into using Exchange sure... but *Outlook*? 

> > Perhaps I should add an Exchange Web Services back end to
> > git-send-email so that people can use that instead of SMTP... :)
> 
> There's a smiley there but I'm pretty sure that'd be really useful for
> some people.

Seriously though, what James and I do with git-format-patch into
Evolution's Drafts folder and then just sending from there, should work
for fairly much anyone.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

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

[Konstantin Ryabitsev]

[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]

On Tue, Sep 18, 2018 at 06:58:45PM +0000, Tim.Bird@sony.com wrote:
>> >> 1. Allows people to generate an account
>> >> 2. Verifies their email address
>> >> 3. Instructs people how to generate a patch or series of patches
>> >> 4. Gives a way to upload generated patches
>> >> 5. Runs checkpatch to make sure there are no errors
>> >> 6. Runs get_maintainer to find out where the patch(es) should be sent to
>> >> 7. (Does more imaginary magic, such as looking up message-id references)
>> >> 8. Mails it out
>This could help solve a lot of e-mail issues that contributors have, 
>but also
>I'm very interested in step 5 - the testing aspect.  I would like to be involved in
>discussions of the design of that step, so we could plug lots of different tests
>in, at the request of various sub-system maintainers.  I maintain the Fuego
>test system, so I'd be interested in making available our test suites for that
>step.

I'm not sure this is going to be the right tool for test-suite 
integration -- in fact, I'd argue that CI stuff should remain wholly 
outside of its scope. The goal is to make it easier to send good, 
acceptable patches (even if their content is no good). CI and any other 
automated testing should happen after these patches have hit LKML (and 
any other lists), if only because there is no One True Place That Does 
CI, and things like 0daybot/syzbot/etc are already honed to work via the 
mailing list.

That said, I'm open to be convinced otherwise if others want this to 
happen *before* patches land on the mailing lists. If that is the case, 
we will want to rope kernelci folks into this discussion.

>Please let me know if there's some opportunity to follow up with you on 
>this
>( ie, a list where this might be discussed in more detail, or an event where we
>could talk face-to-face).

I'll be at the Kernel Summit in Vancouver, and I believe at least Kevin 
of KernelCI fame will be there, too.

-K

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Sasha Levin]

On Tue, Sep 18, 2018 at 08:22:59PM +0100, David Woodhouse wrote:
>On Tue, 2018-09-18 at 10:24 -0700, Mark Brown wrote:
>> On Tue, Sep 18, 2018 at 05:50:45PM +0100, David Woodhouse wrote:
>> > On Tue, 2018-09-18 at 09:02 -0700, Mark Brown wrote:
>> > > At least with Outlook the problem is partly that Outlook's model of how
>> > > e-mail works isn't really able to cope with what we need, it translates
>> > > everything into internal formats in a way that is at best fragile for
>> > > what we need.
>> > Outlook is a pile of crap, but Exchange itself works tolerably these
>> > days. It's fairly simple to send and receive patches through Exchange
>> > if you don't make the mistake of using Outlook.
>>
>> Unfortunately some people do get forced into that :(
>
>Into using Exchange sure... but *Outlook*?

Yes, an example is when corp policy forces 2FA auth for exachange. I'm
not aware of any non-outlook apps that support that.


--
Thanks,
Sasha

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

[Josh Triplett]

On Tue, Sep 18, 2018 at 07:30:41PM +0000, Sasha Levin via Ksummit-discuss wrote:
> On Tue, Sep 18, 2018 at 08:22:59PM +0100, David Woodhouse wrote:
> >On Tue, 2018-09-18 at 10:24 -0700, Mark Brown wrote:
> >> On Tue, Sep 18, 2018 at 05:50:45PM +0100, David Woodhouse wrote:
> >> > On Tue, 2018-09-18 at 09:02 -0700, Mark Brown wrote:
> >> > > At least with Outlook the problem is partly that Outlook's model of how
> >> > > e-mail works isn't really able to cope with what we need, it translates
> >> > > everything into internal formats in a way that is at best fragile for
> >> > > what we need.
> >> > Outlook is a pile of crap, but Exchange itself works tolerably these
> >> > days. It's fairly simple to send and receive patches through Exchange
> >> > if you don't make the mistake of using Outlook.
> >>
> >> Unfortunately some people do get forced into that :(
> >
> >Into using Exchange sure... but *Outlook*?
> 
> Yes, an example is when corp policy forces 2FA auth for exachange. I'm
> not aware of any non-outlook apps that support that.

At that point, I wonder if the best bet would be "don't use that email
account for patches".

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]

On Tue, 2018-09-18 at 19:30 +0000, Sasha Levin wrote:
> On Tue, Sep 18, 2018 at 08:22:59PM +0100, David Woodhouse wrote:
> > On Tue, 2018-09-18 at 10:24 -0700, Mark Brown wrote:
> > > On Tue, Sep 18, 2018 at 05:50:45PM +0100, David Woodhouse wrote:
> > > > On Tue, 2018-09-18 at 09:02 -0700, Mark Brown wrote:
> > > > > At least with Outlook the problem is partly that Outlook's model of how
> > > > > e-mail works isn't really able to cope with what we need, it translates
> > > > > everything into internal formats in a way that is at best fragile for
> > > > > what we need.
> > > > 
> > > > Outlook is a pile of crap, but Exchange itself works tolerably these
> > > > days. It's fairly simple to send and receive patches through Exchange
> > > > if you don't make the mistake of using Outlook.
> > > 
> > > Unfortunately some people do get forced into that :(
> > 
> > Into using Exchange sure... but *Outlook*?
> 
> Yes, an example is when corp policy forces 2FA auth for exachange. I'm
> not aware of any non-outlook apps that support that.

https://wiki.gnome.org/Apps/Evolution/EWS/OAuth2

That seems harder than it should be, but apparently works for some.

cf. https://bugzilla.gnome.org/show_bug.cgi?id=775690

If you have suggestions to improve it, I'm sure they would be
welcomed...

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

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

[Takashi Iwai]

On Tue, 18 Sep 2018 18:32:34 +0200,
Luck, Tony wrote:
> 
> On Tue, Sep 18, 2018 at 09:02:36AM -0700, Mark Brown wrote:
> > At least with Outlook the problem is partly that Outlook's model of how
> > e-mail works isn't really able to cope with what we need, it translates
> > everything into internal formats in a way that is at best fragile for
> > what we need.
> 
> Or, shock, horror, tell one-time contributors that it is OK to
> put the patch in an attachment to the e-mail.  Outlook doesn't
> (usually) mess with the contents of attachments.

Yeah, that's what I usually ask as the last resort if anything else
can't help.  It's a bit of pain to expand the attachment in the reply,
but, hey, I'm using Emacs, the great OS itself :)


Takashi

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

[Steven Rostedt]

On Tue, 18 Sep 2018 09:35:28 -0700
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony <tony.luck@intel.com> wrote:
> >
> > On Tue, Sep 18, 2018 at 09:02:36AM -0700, Mark Brown wrote:  
> > > At least with Outlook the problem is partly that Outlook's model of how
> > > e-mail works isn't really able to cope with what we need, it translates
> > > everything into internal formats in a way that is at best fragile for
> > > what we need.  
> >
> > Or, shock, horror, tell one-time contributors that it is OK to
> > put the patch in an attachment to the e-mail.  Outlook doesn't
> > (usually) mess with the contents of attachments.  
> 
> And then have maintainer having hard time trying to comment on said
> patch in the attachment. I'd rather not.
> 

This is why I use claws-mail. One of the nice features to it, is if you
receive a patch as an attachment, you open it up, select all the text
(right-click->select all), and then hit "reply". It makes it just as if
the patch was the email. Then you can easily make your inline comments
as usual.

-- Steve

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

[Alexandre Belloni]

On 18/09/2018 14:03:24-0400, Konstantin Ryabitsev wrote:
> On Tue, Sep 18, 2018 at 07:49:13PM +0200, Greg KH wrote:
> > > 1. Allows people to generate an account
> > > 2. Verifies their email address
> > > 3. Instructs people how to generate a patch or series of patches
> > > 4. Gives a way to upload generated patches
> > > 5. Runs checkpatch to make sure there are no errors
> > > 6. Runs get_maintainer to find out where the patch(es) should be sent to
> > > 7. (Does more imaginary magic, such as looking up message-id references)
> > > 8. Mails it out
> > 
> > That last step might be hard, you have to "mail it out" to look like it
> > came from the original author, right?  Then all crud breaks out as you
> > can't deliver an email from "sony.com" successfully.
> 
> We already do nasty things to work around this. E.g. if you look at the
> envelope-sender for mail delivered via mail.kernel.org you'll see that it
> all looks like this: SRS0=crc=stuff=orig-domain.com=orig-local@kernel.org
> 
> So, mailing it out and having it pass DKIM/SPF checks to be reliably
> delivered is something we can do. Or, we can send it from
> "vapor-git-thingy@kernel.org" and put the original sender into Reply-To,
> which is also kosher.
> 

Wouldn't that break patchwork? I remember having to edit patches because
it changed the name of the author to its previous named based on the
email address (the name changed but not the email).

Else, I find that a generally good idea.

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[Laurent Pinchart]

Hi Konstantin,

On Tuesday, 18 September 2018 20:31:48 EEST Konstantin Ryabitsev wrote:
> On Tue, Sep 18, 2018 at 05:08:02PM +0000, Tim.Bird@sony.com wrote:
> >> https://urldefense.proofpoint.com/v2/url?u=https-> >> 3A__korg.wiki.kernel.org_userdoc_mail-23sending-5Foutgoing-
> >> 5Fmail&d=DwICAg&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-
> >> GLPtvShAo4cc&r=rUvFawR4KzgZu1gSN5tuozUn7iTTP0Y-
> >> INWqfY8MsF0&m=90EMZrRfkvlzWBNtrJ8QnHDj3-EwehEZhQiC5YJY-
> >> Uk&s=xtUgBLn5bjLazevAEIdAoHAGclbgin-D9Cek15hsuZk&e=
> 
> Ick.
> 
> > Thank you for the offer.  However, while that's a solution that might
> > work for me (modulo my ability to punch my way through the firewall to
> > that mail server), it doesn't scale or help my colleagues at Sony who I'm
> > trying to remove barriers for as well.   I'm senior enough at Sony to have
> > a somewhat different situation than other Sony Linux developers, however 
> > I intentionally work through the IT department and use commonly provided
> > tools here in order to 1) understand the hurdles other developers at Sony
> > have, and 2) work on general solutions.
> 
> Ah, I understand your situation better now.
> 
> So, what if we imagine that there's an imaginary web tool that does
> this:
> 
> 1. Allows people to generate an account
> 2. Verifies their email address
> 3. Instructs people how to generate a patch or series of patches
> 4. Gives a way to upload generated patches
> 5. Runs checkpatch to make sure there are no errors
> 6. Runs get_maintainer to find out where the patch(es) should be sent to
> 7. (Does more imaginary magic, such as looking up message-id references)
> 8. Mails it out
> 
> Would that be useful or solve any problems? Or would that, on the
> contrary, create more problems than it solves?

What if that imaginary web tool accepted a git push fo steps 3 and 4 ? It 
would be nice if the git push could be unauthenticated, but I understand that 
could cause spam and other related issues.

-- 
Regards,

Laurent Pinchart

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

[Laurent Pinchart]

On Wednesday, 19 September 2018 00:01:47 EEST Steven Rostedt wrote:
> On Tue, 18 Sep 2018 09:35:28 -0700 Dmitry Torokhov wrote:
> > On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony wrote:
> >> On Tue, Sep 18, 2018 at 09:02:36AM -0700, Mark Brown wrote:
> >>> At least with Outlook the problem is partly that Outlook's model of
> >>> how e-mail works isn't really able to cope with what we need, it
> >>> translates everything into internal formats in a way that is at best
> >>> fragile for what we need.
> >> 
> >> Or, shock, horror, tell one-time contributors that it is OK to
> >> put the patch in an attachment to the e-mail.  Outlook doesn't
> >> (usually) mess with the contents of attachments.
> > 
> > And then have maintainer having hard time trying to comment on said
> > patch in the attachment. I'd rather not.
> 
> This is why I use claws-mail. One of the nice features to it, is if you
> receive a patch as an attachment, you open it up, select all the text
> (right-click->select all), and then hit "reply". It makes it just as if
> the patch was the email. Then you can easily make your inline comments
> as usual.

I wouldn't mind patches sent as attachments if I could just hit a reply-as-
inline shortcut that would take all attachments and properly inline them, 
quoting the result and opening the reply window. That should be fairly easy to 
implement in <insert-mail-client-here> but more difficult if we wanted to 
patch all popular (and less popular) mail clients.

-- 
Regards,

Laurent Pinchart

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 656 bytes --]

On Tue, Sep 18, 2018 at 05:01:47PM -0400, Steven Rostedt wrote:

> This is why I use claws-mail. One of the nice features to it, is if you
> receive a patch as an attachment, you open it up, select all the text
> (right-click->select all), and then hit "reply". It makes it just as if
> the patch was the email. Then you can easily make your inline comments
> as usual.

mutt's even nicer here, if the attachment has a text MIME type it'l just
include it in the reply (possibly this is configurable but it's what I
want and it does it by default for me).  This does get broken if the
sender flags the message with a non-text type for some reason though :(

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Christoph Hellwig]

On Tue, Sep 18, 2018 at 04:54:12PM -0700, Mark Brown wrote:
> > This is why I use claws-mail. One of the nice features to it, is if you
> > receive a patch as an attachment, you open it up, select all the text
> > (right-click->select all), and then hit "reply". It makes it just as if
> > the patch was the email. Then you can easily make your inline comments
> > as usual.
> 
> mutt's even nicer here, if the attachment has a text MIME type it'l just
> include it in the reply (possibly this is configurable but it's what I
> want and it does it by default for me).  This does get broken if the
> sender flags the message with a non-text type for some reason though :(

I was just going to say that I rarely had problems with attached
patched recently as mutt seems to handle them right in replies
transparently. 

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

[James Bottomley]

On Tue, 2018-09-18 at 09:35 -0700, Dmitry Torokhov wrote:
> On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony <tony.luck@intel.com>
> wrote:
> > 
> > On Tue, Sep 18, 2018 at 09:02:36AM -0700, Mark Brown wrote:
> > > At least with Outlook the problem is partly that Outlook's model
> > > of how
> > > e-mail works isn't really able to cope with what we need, it
> > > translates
> > > everything into internal formats in a way that is at best fragile
> > > for
> > > what we need.
> > 
> > Or, shock, horror, tell one-time contributors that it is OK to
> > put the patch in an attachment to the e-mail.  Outlook doesn't
> > (usually) mess with the contents of attachments.
> 
> And then have maintainer having hard time trying to comment on said
> patch in the attachment. I'd rather not.

We've long accepted attached patches from exchange people in SCSI
(usually we request them when the whitespace damage can't be fixed any
other way).  It's a pain to reply to because you have to cut and paste
from the attachment in the reply but it's not impossible and if it's
the only way to get the patch out of the corporation in the first
place, I think the pain is acceptable.

James

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

[Joe Perches]

On Tue, 2018-09-11 at 17:02 +0200, Daniel Vetter wrote:
> - Talk about the maintainer. If no one wants to help out, but it's a
> generally active area, there's a problem. Fairly often it's a human
> problem, and the maintainer is blind to their own short-comings. This
> is very tricky, and requires enormous amounts of empathy and time, but
> can be rectified.

Somewhat dubious assertion.  Perhaps more often it is a
generally active but somewhat isolated subsystem that few
take an interest in.

> Looking at drivers/rtc over the past 2-3 years it seems like a
> decently active subsystem. Probably on the small side of things, but
> not catastrophically so. But looking at contributor stats the picture
> is totally different:
> 
>    241  Alexandre Belloni
>     28  Linus Torvalds
>     27  Arnd Bergmann
>     25  Javier Martinez Canillas
>     20  Uwe Kleine-König
> 
> That kind of skewed contribution statistics is indeed not sustainable,
> and indicates some serious problem imo.

It's not necessarily serious.

A single active maintainer is well capable of maintaining
a subsystem as long as it's somewhat contained.

It is curious though that one of the nominal maintainers,
Alessandro Zummo, has not signed any single commit since
2015 though.

> What exactly goes wrong, and
> how to best fix it I can't tell without more information though. From
> my experience in drm, where we also have some areas with highly skewed
> contribution statistics, it could be the maintainer driving people
> away, ensuring that there's only one-off contributions. Usually
> unkowningly.

Possible, but one-off contributions skew noisily today to
trivial whitespace and checkpatch/clang warning updates.

It generally requires an advanced knowledge of a subsystem
to be able to make substantive or even non-trivial changes.

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

[Olof Johansson]

On Tue, Sep 18, 2018 at 6:18 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> [ Still very much on break, but reading ksuummit-discuss and answering
> this one ]
>
> On Tue, Sep 18, 2018 at 9:35 AM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>> On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony <tony.luck@intel.com> wrote:
>> >
>> > Or, shock, horror, tell one-time contributors that it is OK to
>> > put the patch in an attachment to the e-mail.  Outlook doesn't
>> > (usually) mess with the contents of attachments.
>>
>> And then have maintainer having hard time trying to comment on said
>> patch in the attachment. I'd rather not.
>
> I actually think that *this* could be easily handled by trivial
> tooling that doesn't have to be set up over and over again inside
> companies or teaching people.
>
> In fact, doesn't patchwork already do exactly that?
>
> I have to say, there are real technical advantages to using
> attachments for patches, particularly when you have odd combinations
> of locales. It's gotten to be less of an issue over time and we're
> still almost entirely US-ASCII with the occasional UTF-8, but we do
> still have the occasional problem. Using attachments at least detaches
> the email charset from the user locale, and from random other MUA
> issues.
>
> But yes, the "comment on individual parts of the patch" part is very
> important too.
>
> The main problem with having something that rewrites things is that it
> breaks DKIM etc, so you can't just have a pure email gateway. It
> almost needs to be something at a higher semantic level like patchwork
> (that could still send out rewritten emails).
>
> In many cases, you might want that anyway (ie wouldn't it be lovely
> when the patch is also checked for "does it build" and looks up the
> maintainers based on what paths it touches etc etc).
>
> So a sane email / web-interface kind of gateway that allows people to
> work the way they prefer.
>
> But I guess "trivial" is completely the wrong word to use.

We're already starting to use some bots that sit on the mailing lists
and monitor incoming material.

This could be solved with something as simple as a bot that takes the
patch-as-attachment, does a few useful things like runs checkpatch and
makes sure it applies cleanly (maybe report what trees it applies
cleanly to, such as current mainline and next), and then inlines the
whole patch. All as a reply-all to the sender + original recipients.

That way, anyone looking to do an inline review can do it on the bot
version, and the originator will still receive the feedback, etc. It'd
also solve the DKIM-related aspects, if I'm not mistaken.

People who get distracted by the bot emails can easily choose to filter it.


-Olof

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

[Mauro Carvalho Chehab]

Em Fri, 21 Sep 2018 17:46:13 +0100
Olof Johansson <olof@lixom.net> escreveu:

> On Tue, Sep 18, 2018 at 6:18 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > [ Still very much on break, but reading ksuummit-discuss and answering
> > this one ]
> >
> > On Tue, Sep 18, 2018 at 9:35 AM Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:  
> >> On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony <tony.luck@intel.com> wrote:  
> >> >
> >> > Or, shock, horror, tell one-time contributors that it is OK to
> >> > put the patch in an attachment to the e-mail.  Outlook doesn't
> >> > (usually) mess with the contents of attachments.  
> >>
> >> And then have maintainer having hard time trying to comment on said
> >> patch in the attachment. I'd rather not.  
> >
> > I actually think that *this* could be easily handled by trivial
> > tooling that doesn't have to be set up over and over again inside
> > companies or teaching people.
> >
> > In fact, doesn't patchwork already do exactly that?
> >
> > I have to say, there are real technical advantages to using
> > attachments for patches, particularly when you have odd combinations
> > of locales. It's gotten to be less of an issue over time and we're
> > still almost entirely US-ASCII with the occasional UTF-8, but we do
> > still have the occasional problem. Using attachments at least detaches
> > the email charset from the user locale, and from random other MUA
> > issues.
> >
> > But yes, the "comment on individual parts of the patch" part is very
> > important too.
> >
> > The main problem with having something that rewrites things is that it
> > breaks DKIM etc, so you can't just have a pure email gateway. It
> > almost needs to be something at a higher semantic level like patchwork
> > (that could still send out rewritten emails).
> >
> > In many cases, you might want that anyway (ie wouldn't it be lovely
> > when the patch is also checked for "does it build" and looks up the
> > maintainers based on what paths it touches etc etc).
> >
> > So a sane email / web-interface kind of gateway that allows people to
> > work the way they prefer.
> >
> > But I guess "trivial" is completely the wrong word to use.  
> 
> We're already starting to use some bots that sit on the mailing lists
> and monitor incoming material.
> 
> This could be solved with something as simple as a bot that takes the
> patch-as-attachment, does a few useful things like runs checkpatch and
> makes sure it applies cleanly (maybe report what trees it applies
> cleanly to, such as current mainline and next), and then inlines the
> whole patch. All as a reply-all to the sender + original recipients.
> 
> That way, anyone looking to do an inline review can do it on the bot
> version, and the originator will still receive the feedback, etc. It'd
> also solve the DKIM-related aspects, if I'm not mistaken.
> 
> People who get distracted by the bot emails can easily choose to filter it.

Seems to work.

Still, there are some issues with that. Depending on the email client,
it may not recognize the patch as is, and use a wrong mime-type.
If the mail server doesn't recognize the mime-type, or considers it
evil, it may reject the e-mail, and the bot will get nothing.
Not sure what's the current status of e-mailers and patches, but on
my past experiences on another company (lots of years ago), usually
webmail solutions are worse[1], and don't properly tag certain types
of attachments.

[1] I know places where only a corporate webmail solution is allowed
by default, and using any other solution would require an special
security approval. Not sure if is worth to consider such scenario,
though.

Another problem is that bots will receive the same e-mail twice
(the original one and the inlined one). We may start having
multiple kernel-test robots reply for such emails, with is not
a good thing. So, if done this way, it is probably worth to add
some meta-tags to avoid the new e-mail with the same patch
to be parsed again by (other) robots.


Thanks,
Mauro

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

[Olof Johansson]

On Fri, Sep 21, 2018 at 6:08 PM, Mauro Carvalho Chehab
<mchehab@kernel.org> wrote:
> Em Fri, 21 Sep 2018 17:46:13 +0100
> Olof Johansson <olof@lixom.net> escreveu:
>
>> On Tue, Sep 18, 2018 at 6:18 PM, Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:
>> > [ Still very much on break, but reading ksuummit-discuss and answering
>> > this one ]
>> >
>> > On Tue, Sep 18, 2018 at 9:35 AM Dmitry Torokhov
>> > <dmitry.torokhov@gmail.com> wrote:
>> >> On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony <tony.luck@intel.com> wrote:
>> >> >
>> >> > Or, shock, horror, tell one-time contributors that it is OK to
>> >> > put the patch in an attachment to the e-mail.  Outlook doesn't
>> >> > (usually) mess with the contents of attachments.
>> >>
>> >> And then have maintainer having hard time trying to comment on said
>> >> patch in the attachment. I'd rather not.
>> >
>> > I actually think that *this* could be easily handled by trivial
>> > tooling that doesn't have to be set up over and over again inside
>> > companies or teaching people.
>> >
>> > In fact, doesn't patchwork already do exactly that?
>> >
>> > I have to say, there are real technical advantages to using
>> > attachments for patches, particularly when you have odd combinations
>> > of locales. It's gotten to be less of an issue over time and we're
>> > still almost entirely US-ASCII with the occasional UTF-8, but we do
>> > still have the occasional problem. Using attachments at least detaches
>> > the email charset from the user locale, and from random other MUA
>> > issues.
>> >
>> > But yes, the "comment on individual parts of the patch" part is very
>> > important too.
>> >
>> > The main problem with having something that rewrites things is that it
>> > breaks DKIM etc, so you can't just have a pure email gateway. It
>> > almost needs to be something at a higher semantic level like patchwork
>> > (that could still send out rewritten emails).
>> >
>> > In many cases, you might want that anyway (ie wouldn't it be lovely
>> > when the patch is also checked for "does it build" and looks up the
>> > maintainers based on what paths it touches etc etc).
>> >
>> > So a sane email / web-interface kind of gateway that allows people to
>> > work the way they prefer.
>> >
>> > But I guess "trivial" is completely the wrong word to use.
>>
>> We're already starting to use some bots that sit on the mailing lists
>> and monitor incoming material.
>>
>> This could be solved with something as simple as a bot that takes the
>> patch-as-attachment, does a few useful things like runs checkpatch and
>> makes sure it applies cleanly (maybe report what trees it applies
>> cleanly to, such as current mainline and next), and then inlines the
>> whole patch. All as a reply-all to the sender + original recipients.
>>
>> That way, anyone looking to do an inline review can do it on the bot
>> version, and the originator will still receive the feedback, etc. It'd
>> also solve the DKIM-related aspects, if I'm not mistaken.
>>
>> People who get distracted by the bot emails can easily choose to filter it.
>
> Seems to work.
>
> Still, there are some issues with that. Depending on the email client,
> it may not recognize the patch as is, and use a wrong mime-type.
> If the mail server doesn't recognize the mime-type, or considers it
> evil, it may reject the e-mail, and the bot will get nothing.
> Not sure what's the current status of e-mailers and patches, but on
> my past experiences on another company (lots of years ago), usually
> webmail solutions are worse[1], and don't properly tag certain types
> of attachments.
>
> [1] I know places where only a corporate webmail solution is allowed
> by default, and using any other solution would require an special
> security approval. Not sure if is worth to consider such scenario,
> though.

All of these sound like solvable problems to me, by having the bot be
lenient about what it accepts. It might get a bit messy and might need
tuning over time, but that's fine.

> Another problem is that bots will receive the same e-mail twice
> (the original one and the inlined one). We may start having
> multiple kernel-test robots reply for such emails, with is not
> a good thing. So, if done this way, it is probably worth to add
> some meta-tags to avoid the new e-mail with the same patch
> to be parsed again by (other) robots.

With only a couple of active bots, making them filter each other would
be a trivial initial approach.


-Olof