[Ksummit-discuss] Maintainer's Summit 2017 Feedback Thread

[Ksummit-discuss] Maintainer's Summit 2017 Feedback Thread

[Theodore Ts'o]

Hi,

Please reply to this thread if you have any comments about how we can
organize the Maintainer's Summit for next year.  Given that Linus
seemed fairly happy with how things went, it's likely we will stick
with the same format for next year, but if there are any details about
how we could do things better, I'd greatly appreciate them.

Thanks!!

					- Ted

Re: [Ksummit-discuss] Maintainer's Summit 2017 Feedback Thread

[Bart Van Assche]

On Sun, 2017-10-29 at 06:08 -0400, Theodore Ts'o wrote:
> Please reply to this thread if you have any comments about how we can
> organize the Maintainer's Summit for next year.  Given that Linus
> seemed fairly happy with how things went, it's likely we will stick
> with the same format for next year, but if there are any details about
> how we could do things better, I'd greatly appreciate them.

Hello Ted,

Something that surprised me is although I'm reading Linus' replies to pull
requests that appear on the LKML mailing list that during the maintainer
summit I learned more about what Linus expects from maintainers than by
reading Linus' e-mails. I think this shows that reading Linus' e-mails is
not enough to learn what Linus expects from maintainers. This made me wonder
how maintainers are informed about what is expected from them, especially
new maintainers? Do we perhaps need a document in the kernel tree that
explains what is expected from maintainers?

Thanks,

Bart.

Re: [Ksummit-discuss] Maintainer's Summit 2017 Feedback Thread

[Dan Williams]

On Mon, Oct 30, 2017 at 9:29 AM, Bart Van Assche <Bart.VanAssche@wdc.com> wrote:
> On Sun, 2017-10-29 at 06:08 -0400, Theodore Ts'o wrote:
>> Please reply to this thread if you have any comments about how we can
>> organize the Maintainer's Summit for next year.  Given that Linus
>> seemed fairly happy with how things went, it's likely we will stick
>> with the same format for next year, but if there are any details about
>> how we could do things better, I'd greatly appreciate them.
>
> Hello Ted,
>
> Something that surprised me is although I'm reading Linus' replies to pull
> requests that appear on the LKML mailing list that during the maintainer
> summit I learned more about what Linus expects from maintainers than by
> reading Linus' e-mails. I think this shows that reading Linus' e-mails is
> not enough to learn what Linus expects from maintainers. This made me wonder
> how maintainers are informed about what is expected from them, especially
> new maintainers? Do we perhaps need a document in the kernel tree that
> explains what is expected from maintainers?

Yes, we do. Especially with the number of people that are sending pull
requests directly to Linus. I am taking a look at putting a first
draft of such a document together in the next week or so.

Re: [Ksummit-discuss] Maintainer's Summit 2017 Feedback Thread

[Mimi Zohar]

On Mon, 2017-10-30 at 09:32 -0700, Dan Williams wrote:
> On Mon, Oct 30, 2017 at 9:29 AM, Bart Van Assche <Bart.VanAssche@wdc.com> wrote:
> > On Sun, 2017-10-29 at 06:08 -0400, Theodore Ts'o wrote:
> >> Please reply to this thread if you have any comments about how we can
> >> organize the Maintainer's Summit for next year.  Given that Linus
> >> seemed fairly happy with how things went, it's likely we will stick
> >> with the same format for next year, but if there are any details about
> >> how we could do things better, I'd greatly appreciate them.
> >
> > Hello Ted,
> >
> > Something that surprised me is although I'm reading Linus' replies to pull
> > requests that appear on the LKML mailing list that during the maintainer
> > summit I learned more about what Linus expects from maintainers than by
> > reading Linus' e-mails. I think this shows that reading Linus' e-mails is
> > not enough to learn what Linus expects from maintainers. This made me wonder
> > how maintainers are informed about what is expected from them, especially
> > new maintainers? Do we perhaps need a document in the kernel tree that
> > explains what is expected from maintainers?

Is there a summary of what Linus said?

> Yes, we do. Especially with the number of people that are sending pull
> requests directly to Linus. I am taking a look at putting a first
> draft of such a document together in the next week or so.

Much appreciated!  Any chance it will be out before the next open window?

Mimi

Re: [Ksummit-discuss] Maintainer's Summit 2017 Feedback Thread

[Bart Van Assche]

On Sun, 2017-10-29 at 06:08 -0400, Theodore Ts'o wrote:
> Please reply to this thread if you have any comments about how we can
> organize the Maintainer's Summit for next year.  Given that Linus
> seemed fairly happy with how things went, it's likely we will stick
> with the same format for next year, but if there are any details about
> how we could do things better, I'd greatly appreciate them.

Something Linus was very clear about is that regressions are not acceptable.
The best way I know to reduce the number of regressions is to increase the
efforts on automatic testing. Should the number of tests that is run by the
zero-day testing infrastructure be increased? Should more tests be added?
Should the documentation that is available on
https://01.org/lkp/documentation/0-day-test-service perhaps be moved
elsewhere, e.g. inside that repository? Do we need a link on kernel.org or
in the kernel documentation to that project?

Thanks,

Bart.

Re: [Ksummit-discuss] Maintainer's Summit 2017 Feedback Thread

[Theodore Ts'o]

On Mon, Oct 30, 2017 at 05:42:33PM +0000, Bart Van Assche wrote:
> On Sun, 2017-10-29 at 06:08 -0400, Theodore Ts'o wrote:
> > Please reply to this thread if you have any comments about how we can
> > organize the Maintainer's Summit for next year.  Given that Linus
> > seemed fairly happy with how things went, it's likely we will stick
> > with the same format for next year, but if there are any details about
> > how we could do things better, I'd greatly appreciate them.
> 
> Something Linus was very clear about is that regressions are not acceptable.
> The best way I know to reduce the number of regressions is to increase the
> efforts on automatic testing. Should the number of tests that is run by the
> zero-day testing infrastructure be increased?

The 0-day system has sent a whole series of reports in response to
Linus's v4.14-rc6 announcement.  So it sounds like Fengguang is
already on it.  :-)

At least, for those things where we have tests and where the 0-day
hardware tickles the code paths of various arch-specific and drivers.

The good news is that we've picked a lot of the low-hanging fruit.
The bad news is that a lot of what is left is hardware-specific driver
issues, where fixing a bug for the current generation of devices might
break some device from an older generation.  I recall one change to
the Intel Wireless which only regressed when talking to an Aruba
Enterprise-grade Access Point, for which the Intel wireless driver
folks did not have in their hardware test library.

I would hope that most maintainers are doing testing on their own
subsystems.  I certainly do a large amount of exhaustive testing of
ext4 before I send a pull request (including most cases doing a trial
merge before launching a gce-xfstests run).  And I would assume (for
example), that Damien does a large amount of test of his ZBC support
code against SMR HDD's (bonus points if he tests SMR drives from both
WDC and Seagate :-) before he does he submits patches for review, and
as they get merged into Linus's tree.

More test in the zero-day testing infrastructure is good, but this
can't be a substitute for maintainers testing their own subsystems.
That's the only thing that can possibly scale.

	     	    	     	   	    - Ted

Re: [Ksummit-discuss] Maintainer's Summit 2017 Feedback Thread

[Greg KH]

On Mon, Oct 30, 2017 at 05:42:33PM +0000, Bart Van Assche wrote:
> On Sun, 2017-10-29 at 06:08 -0400, Theodore Ts'o wrote:
> > Please reply to this thread if you have any comments about how we can
> > organize the Maintainer's Summit for next year.  Given that Linus
> > seemed fairly happy with how things went, it's likely we will stick
> > with the same format for next year, but if there are any details about
> > how we could do things better, I'd greatly appreciate them.
> 
> Something Linus was very clear about is that regressions are not acceptable.
> The best way I know to reduce the number of regressions is to increase the
> efforts on automatic testing. Should the number of tests that is run by the
> zero-day testing infrastructure be increased? Should more tests be added?

Are there tests out there that 0-day does not currently run?  If there
are any out there that 0-day should run that it does not, you can always
add new ones, the 0-day client code is on github...

> Should the documentation that is available on
> https://01.org/lkp/documentation/0-day-test-service perhaps be moved
> elsewhere, e.g. inside that repository? Do we need a link on kernel.org or
> in the kernel documentation to that project?

0-day is just one of the many different test systems for the kernel,
should we add links to them all?  :)

thanks,

greg k-h

Re: [Ksummit-discuss] Maintainer's Summit 2017 Feedback Thread

[Konstantin Ryabitsev]

On Mon, Oct 30, 2017 at 10:20:57PM +0100, Greg KH wrote:
> > Should the documentation that is available on
> > https://01.org/lkp/documentation/0-day-test-service perhaps be moved
> > elsewhere, e.g. inside that repository? Do we need a link on kernel.org or
> > in the kernel documentation to that project?
> 
> 0-day is just one of the many different test systems for the kernel,
> should we add links to them all?  :)

Worth pointing out that there's https://bottest.wiki.kernel.org/ that is
probably a good place for this.

-K

Re: [Ksummit-discuss] Maintainer's Summit 2017 Feedback Thread

[James Bottomley]

On October 30, 2017 9:24:21 PM GMT, Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
>On Mon, Oct 30, 2017 at 10:20:57PM +0100, Greg KH wrote:
>> > Should the documentation that is available on
>> > https://01.org/lkp/documentation/0-day-test-service perhaps be
>moved
>> > elsewhere, e.g. inside that repository? Do we need a link on
>kernel.org or
>> > in the kernel documentation to that project?
>> 
>> 0-day is just one of the many different test systems for the kernel,
>> should we add links to them all?  :)
>
>Worth pointing out that there's https://bottest.wiki.kernel.org/ that
>is
>probably a good place for this.

Actually,adding what runs automatically, what you have to request coverage for and what you have to run yourself would be useful info for the wiki.

James

>-K
>_______________________________________________
>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's Summit 2017 Feedback Thread

[Bart Van Assche]

On Mon, 2017-10-30 at 22:20 +0100, Greg KH wrote:
> On Mon, Oct 30, 2017 at 05:42:33PM +0000, Bart Van Assche wrote:
> > On Sun, 2017-10-29 at 06:08 -0400, Theodore Ts'o wrote:
> > > Please reply to this thread if you have any comments about how we can
> > > organize the Maintainer's Summit for next year.  Given that Linus
> > > seemed fairly happy with how things went, it's likely we will stick
> > > with the same format for next year, but if there are any details about
> > > how we could do things better, I'd greatly appreciate them.
> > 
> > Something Linus was very clear about is that regressions are not acceptable.
> > The best way I know to reduce the number of regressions is to increase the
> > efforts on automatic testing. Should the number of tests that is run by the
> > zero-day testing infrastructure be increased? Should more tests be added?
> 
> Are there tests out there that 0-day does not currently run?  If there
> are any out there that 0-day should run that it does not, you can always
> add new ones, the 0-day client code is on github...

0-day is the only test infrastructure of which I know that it is run
automatically for the Linux kernel. How should a developer decide which project
to add new tests to: 0-day, ltp (Linux Test Project), ktest, xfstests, blktests
or any other Linux kernel testing project that I am not aware of?

Thanks,

Bart.

Re: [Ksummit-discuss] Maintainer's Summit 2017 Feedback Thread

[greg]

On Mon, Oct 30, 2017 at 09:27:37PM +0000, Bart Van Assche wrote:
> On Mon, 2017-10-30 at 22:20 +0100, Greg KH wrote:
> > On Mon, Oct 30, 2017 at 05:42:33PM +0000, Bart Van Assche wrote:
> > > On Sun, 2017-10-29 at 06:08 -0400, Theodore Ts'o wrote:
> > > > Please reply to this thread if you have any comments about how we can
> > > > organize the Maintainer's Summit for next year.  Given that Linus
> > > > seemed fairly happy with how things went, it's likely we will stick
> > > > with the same format for next year, but if there are any details about
> > > > how we could do things better, I'd greatly appreciate them.
> > > 
> > > Something Linus was very clear about is that regressions are not acceptable.
> > > The best way I know to reduce the number of regressions is to increase the
> > > efforts on automatic testing. Should the number of tests that is run by the
> > > zero-day testing infrastructure be increased? Should more tests be added?
> > 
> > Are there tests out there that 0-day does not currently run?  If there
> > are any out there that 0-day should run that it does not, you can always
> > add new ones, the 0-day client code is on github...
> 
> 0-day is the only test infrastructure of which I know that it is run
> automatically for the Linux kernel.

There are many others, kernel.ci is one of them, the link Konstantin
pointed to has a larger list.

> How should a developer decide which project
> to add new tests to: 0-day, ltp (Linux Test Project), ktest, xfstests, blktests
> or any other Linux kernel testing project that I am not aware of?

It depends on what type of test you are wanting to add.  And you forgot
kselftest :)

thanks,

greg k-h

Re: [Ksummit-discuss] Maintainer's Summit 2017 Feedback Thread

[Julia Lawall]

> > How should a developer decide which project
> > to add new tests to: 0-day, ltp (Linux Test Project), ktest, xfstests, blktests
> > or any other Linux kernel testing project that I am not aware of?
>
> It depends on what type of test you are wanting to add.  And you forgot
> kselftest :)

I think that 0-day takes tests from elsewhere.  You don't add tests to it.

julia

Re: [Ksummit-discuss] Maintainer's Summit 2017 Feedback Thread

[Takashi Iwai]

On Sun, 29 Oct 2017 11:08:16 +0100,
Theodore Ts'o wrote:
> 
> Hi,
> 
> Please reply to this thread if you have any comments about how we can
> organize the Maintainer's Summit for next year.  Given that Linus
> seemed fairly happy with how things went, it's likely we will stick
> with the same format for next year, but if there are any details about
> how we could do things better, I'd greatly appreciate them.

I find such a small group is suitable for discussions, too, as the
atmosphere there was a kind of extended hallway sessions.  Especially
I felt it after the tables were gathered and the mic got off.  A
slightly more attendees would still work, too, though.

But the room assignment needs more consideration: not only pillars in
the middle, the room was too large for a small group, and the constant
noise for preparing the lunch was a bit annoying.

With my distro maintainer hat on, I believe that it would have been
better if we had an open session for things like "bash distro kernels
(or vice versa)" before the maintainers summit.  The "regression
tracking" and "bash kernel maintainers" topics went well in the
maintainers summit since we had sorted out the focused points
beforehand.  Otherwise the discussion will be blurred.


thanks,

Takashi

Re: [Ksummit-discuss] Maintainer's Summit 2017 Feedback Thread

[Jiri Kosina]

On Sun, 29 Oct 2017, Theodore Ts'o wrote:

> Please reply to this thread if you have any comments about how we can 
> organize the Maintainer's Summit for next year.  Given that Linus seemed 
> fairly happy with how things went, it's likely we will stick with the 
> same format for next year, but if there are any details about how we 
> could do things better, I'd greatly appreciate them.

I think the format generally proved to make sense; it really helped the 
conversation to flow in an informal but still productive fashion.

The two downsides from my personal POV:

- room choice; I guess that's pretty obvious and not really worth too 
  much discussion (especially the pillars and the constant noise being 
  generated by the staff in the background)

- I can't help it, but the overall number of attendees seemed to be a 
  little bit *too* small. I'm not asking for a revival of a 90+ people
  on the kernel summit (that absolutely doesn't fit the nature of 
  discussions and the format), but perhaps 40 would make sense? There 
  definitely were a few moments when I felt that the discussion came to 
  a point where having one particular missing person would be helpful.

  I guess that given this was the first time we've had this limited
  setup, we are still converging to the "best" group size?

Thanks,

-- 
Jiri Kosina
SUSE Labs