[Xen-devel] [Hackathon 16] Notes from "Clarifying Maintainership" discussion

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

= Topics Discussed =
- Clarifying ACKing rules and conventions
- ACK on Xen and Linux have different meaning : or do they?
- Patches sent by a maintainer (with no ACK from another maintainer)
- Explain tooling / working patterns which make it easier for contributors see 
whether a patch made it in 
- Rest MAINTAINERS
- Encouraging More Reviewers
- Coding checking tools

== Maintainership Discussion ==

Jan:
I am confused what the meaning of a MAINTAINER is
The MAINTAINERS file does not clearly specifics of how the file works
For example, if I write a file for shadow code, I can interpret the maintainer 
file 
- such that only Tim can ACK it
- such that x86 may ACK it
- such that arch 86/mm may ACK it

Some of this needs to be spelled out
Also the stricter view (aka there is no flexibility and ACKs always need to be 
achieved), leads to delays

George:
Is doing more reviews, than in the past because he is now maintainer
So, thus being clearer as to who has to do what, means people are more 
motivated to review

Julien:
Sometimes the Maintainers file isn't granular enough (e.g. on ARM code 
sometimes existing maintainers do not have a board to verify a piece of code)

Stefano: Sometimes we may not need, but need somebody who tests and verifies 
the board during the release cycle and can be CC'ed if there is an issue on an 
unusual board

Andy: more patches than not on x86, require 3 or more ACKs (it is thus 
moderately difficult to do changes which require less than 3 people maintainers 
to get engaged)
George: Is this a problem?

David: Do we need to formalise or can we rely more on trust, e.g. if for 
example something in MM code looks trivial, we could let x86 maintainers in a 
more relaxed interpretation). But for more intrusive things we we would always 
refer to a specialist. We would allow a higher level maintainer to be 
sufficient.

George: We could follow a lazy consensus model, e.g. if there wasn't a response 
in a week / 2 weeks 

Andy: We had a clear example with APIC when the sub maintainer was away on 
holidays and we had a critical issue

Andy: The default state of the tree should be working, because if it isn't 
development stops. Thus we do 

Lars: How do other communities deal with this?
Stefano: In Linux, there is a person for the whole thing, then one for the 
subset. Default is that person for the subset ACKs the subset and the super 
maintainer can override. 

E.g. Sarah > Greg > Linux (if the change breaks you can skip an chain element)

Andy: You can do this in Linux by collecting ACKs 
David: This happens in parallel

Andy: Do we have a problem?

Way forward: 
* Checking something in without a subsystem maintainers ACK should be 
exceptional
* BUT, we should have a way forward in exceptional cases (e.g. non-response by 
sub maintainer, people being on holidays, active delegation, ...)

Konrad: ACK on Xen and Linux have different meaning
Stefano: No it is the same
Stefano: Linux => Reviewed-by implies ACK-ed by, ACK-ed by could mean that 
maintainer trusts 
Jan: Normally don't ACK patches I didn't review 
Jan: If there is a submaintainer, I don't need to ACK

** Seems we have a way forward **
Lars: Who is going to make a concrete proposal to the list

ACTION: maybe add a paragraph in the maintainers file explaining (George 
volunteered)

Konrad: What if a maintainer sends out a patch and it didn't get an ACK by 
another maintainer
Stefano/Andy/George: Give it a week, a committer should be able to check it in 
Lars: comes down to the exceptional thing

Julien: It is not easy to see whether a patch made it in - there is no easy way 
to find it out
Jan: For the ARM side it is difficult right now
Jan: Once you realise that a series is ready to go in and CC one or two 
committers
Lars: The dashboard allows you to track through searches
Andy: There is a mailing list (see 
http://lists.xenproject.org/archives/html/xen-changelog)
Andy: Takes the RSS feed

ACTION: Lars to bring up with Birin

Stefano: should we have people who own or have an interest in special ARM 
boards with contact addresses
Andy: This is exactly what a feature in-tree doc would work and we could link 
to it in the Wiki
Konrad: is there a dynamic ETB which supports lots of boards
Julian/Andre: No


Open Questions / requires Isn
* Can an ACK be removed after the code has been changed

More reviewers:
- What does a review really mean?
- It's a way to build trust
- David: wait for something which is worthwhile and by pointing it out you 
build trust
- Would it reduce the workload 
- Maybe not initially: but it's a long-time game
- David: I trust people more who do significant contributions than pure reviewer

Do we have guidelines on REST maintainers
Jan: All the committers should be REST maintainers
Julien: Script to get CC's isn't working (REST maintainers part isn't working)
Julien: That needs to be fixed

Coding checking tools
Andy: Did take a look at - (clang-format) from LLVM
Andy: Also seems to be happy to upstream Xen style's
Andy: Need to talk to Doug



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