[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Maintainer nomination for the embedded and automotive subproject



Hi all,

as we are starting to get ready for putting the infrastructure in place for the 
embedded and automotive subproject, we do need to look at an initial set of 
maintainers and reviewers for the project. In particular with a view of scaling 
up quickly and avoiding any bottlenecks in the future.

I talked to Artem, the project lead of the embedded and automotive subproject 
and he proposes that 
* Andrii Tseglytskyi and 
* Andrii Anisov 
be initial maintainers for the PV driver repos (the QNX and Linux user driver 
repos). Now as the nomination is local to the subproject, it is OK for Artem 
the project lead to nominate an initial set of maintainers. However, both have 
made submissions to xen-devel in the past and should have a standing in the 
wider community. So I wanted to open the floor for supporting votes.

Alex and I would also like to invite other members on xen-devel who are 
interested in becoming maintainers for this new subproject to get in touch with 
me and/or Artem.

Alex wanted to follow exactly the same review and code submission process as 
the hypervisor subproject does. I do think we need an exception for the initial 
driver contributions though (see below). The maintainers file for the new 
subproject is naturally not in place yet, as we do not have the repos yet.

So I will copy links to the respective documents from the to be created 
developer wiki pages. I do believe that this also means that we probably will 
need to document some of the best practice on release management, making 
releases, … and other areas which are poorly documented.

== Import of large initial code contributions ==

I do have a question though: how have we handled imports of larger new 
codebases in the past? I can’t find a consistent pattern anywhere on the list: 
we seem to have done anything from a straight import by the project lead to a 
full review of new code. 

Note that the new code in question will be drivers that are owned by the new 
subproject, everything else will be handled as usual. So the embedded and 
automotive subproject is really interested in best practice and experience from 
xen-devel.

There are a small number of Linux Foundation requirements:
* code contributions must have gone through suitable IP checking by the initial 
contributor
* code must be buildable, build docs must exist, etc.

Of course there is always a chicken and egg problem in that we do not have 
anyone in the community yet, who understands the code outside the contributing 
company. So a strong review requirement will slow things down. On the other 
hand, review is good and sets the project on the best possible path. I will 
leave this question open for now : I do have some ideas, but don’t want to 
influence any debate.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.