[Xen-devel] Notes from Design Session: Solving Community Problems: Patch Volume vs Review Bandwidth, Community Meetings ... and other problems

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

Hi all,
please find attached my notes. 
Lars

Session URL: http://sched.co/AjB3

ACTIONS on Lars, Andy and Juergen
ACTIONS on Stefano and Julien

Community Call
==============
This was a discussion about whether we should do more community calls, 
in critical areas. The background was whether we should have an x86 call 
to mirror the ARM call.

Jan and Andy asked whether the ARM calls are useful

Julien: 
They are very useful. On average about 10 people attend.
On ARM we don't yet have a real plan of what's needed for the future.
We are hoping to use the call to establish a firmer plan.

Lars:
Was asking whether we always have an agenda at the beginning.

Julien:
Sometimes, but often the agenda is established/refined in the first
5 minutes at the beginning of the call. Typically Julien or Stefano
handle this at the beginning

Lars asks whether we need one for tools
Ian: there is currently not much a need for technical coordination

Lars: it feels that a call on x86 would be helpful
But we can only cover non-NDA information as with the other calls

Jan and Andy agree that they are happy to try this, but are concerned
that it may fizzle out. Also neither want to own agenda and note-taking
(notes and call info are posted on xen-devel@)

ACTION: Lars to work with Intel on setting this up
(note, I was asked by Susie Li to include John Ji and Chao Peng on this
thread and discuss with them at a separate call)

Timing wise, a call at from 9-10 UK time once a month should work. 

Example of ARM call minutes:
* http://markmail.org/message/myjllcngy3lqveji
* http://markmail.org/message/d4kuqxxhj6dfnf23
* There also ought to be a reminder of call details (someone to
  highlight an example)

Contributions vs. Review Bandwidth 
==================================

A potential bottleneck issue was raised in the area of ARM and x86
 
ARM
---
Lars asks what issue have been observed

Julien: 
Lots of new features and lots of design discussion

Stefano: 
Design discussions are creating trouble: sometimes we have complex 
proposals without a clear answer on the right way forward.

Complicated design 
=> 2/3 options 
=> not clear which way is the best forward 
=> ARM maintainers can provide advice, can say what is going to work

Right now ARM maintainers expect the contributor has to lead and 
drive it (e.g. an example where we were stuck was BIG.Little support)

A pattern we have seen is:
- Complex problem
- Not an obviously clear answer
- Gets stuck
- Design discussion fizzles out without an artefact in the codebase
  (in other words, there is an unfinished mail thread)

Lars:
Asks whether maybe the issue is one of sufficient confidence by the
contributor to move the discussion further or whether expectations 
were not communicated clearly (e.g. tell contributors to pick a
solution and move forward).

Stefano and Julien: 
Agree that this may indeed be the case

It is unusual to be in a technical leadership position when it comes
to driving designs and new solutions, but not from a process perspective.
Contributors need to be reminded of that.

It is also possible that embedded vendors may want to contribute,
but have only a small time window to do this.

Agreements:
* Create a couple of boilerplate mails or checklists to set 
  expectations better

ACTION: on ARM maintainers to trial

* Agreed to allow draft design into the git tree, as long as 
  interface status (Draft and unresolved issues) are clearly 
  documented. In that case, contributors can show progress
  and others - even if a design is not finished - can build on
  it. Feature docs already allow for that and so do Design
  Docs (although there is no example).

ACTION: on ARM maintainers to trial and pick a suitable
location in tree.

x86
---

Lars prompts Jan, Andy on some of the challenges

Jan, Andy:
A Typically series are large and fully formed 
  (e.g. 30 size series)
B Often we don't have enough context to understand design behind code
  This has improved through Hackathons, meetings under NDA, ...
C In the past, series have existed for 2 years earlier in private
  (e.g. SGX was developed against 4.6) and is posted against a newer version.
  At that point, some assumptions may have changed: e.g. on 5-level-paging
  we agreed at the summit that PV support is not needed (only HVM and PVH)
D There is not normally lack of driving and managing the submission of an issue

Roger: 
feels that when he is reviewing x86 stuff it does not actually take work off 
Jan or Andrew, as sometimes one of them will pick up and re-reviews. That 
sometimes puts him off.

Jan: that is a risk to take and shouldn't put you off. 

Wei: says that when his responsibility on a patch is not clear, he says 
"subject to the agreement of XXX". That sets expectations with other 
maintainers and contributors.

Then we went a little bit onto reasons behind bandwidth issues

Jan: large series are often hard to understand and consume. Also, sometimes
there is a lack of understanding that there is limited bandwidth

Andrew, Jan, George, Ian: spent 6 solid weeks in June on set of XSAs

Ian: 
Other people feel that they are not relieving Jan of work when reviewing 
patches. Can I make a radical suggestion: divide the work better between
Andy and Jan and also leave opportunities for others to review

Jan: we are already doing this. Right now I have 200 patches sitting in 
the queue
 
Jan and Andy do not normally coordinate on IRC as to who reviews what,
but in practice we hardly step on each others toes

Ian: would highlighting bottlenecks and make non-maintainer review a 
requirement work?

Andy: non-trivial changes are hard and would just be stalled indefinitely 
if we would have this as a requirement. So no. 
Jan: This is probably too formal and also too easy to game 

Summary: this line of enquiry did not lead anywhere

Lars: I think the only areas, in absence of having more x86 maintainers,
would be to focus a bit more on B (already a focus area, community calls
may also help) and C. C we don't have control over and requires someone
in the contributor to understand our issues better and drive changes from
within the contributor org.

Andy: 
We desperately need something like qemu-bot for style issues
That would free up a significant amount of bandwidth
There are two steps needed

Step 1: perl script like checkpatch.pl which checks style
Step 2: build-bot

Then there was a little discussion about different coding styles, but
it was felt that if we had a working checkpatch.pl, this could be 
resolved relatively easily. Assume Xen style and list exceptions 
in a central file.

Andy: highlights that we have an agreement with clang-format maintainers
to get any Xen related changes upstreamed

Lars: noticed that we had a potential GSoC/Outreachy project
(Attaches URL to proposal at
https://docs.google.com/document/d/10NJn-QvO1TvyJJJGE2PD6FtElYCT3neBAffIqeWHdiE/edit)

Agreement was not to rely on students for this

ACTION: Lars to remind Andy about this next week (will need to be the following 
week)

ACTION: Juergen, happy to do something g to the build system with no action 
behind it (file markers)
ACTION: Andy to look at something like checkpatch.pl for Linux





_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel