On 09/07/2014 11:42, Ian Campbell
wrote:
On Tue, 2014-07-01 at 10:53 +0100, Lars Kurth wrote:
Hi all,
the "Embedded and Automotive PV Drivers Sub-Project Proposal" (see
http://wiki.xenproject.org/wiki/Embedded_and_Automotive_PV_Drivers_Project_Proposal)
is now open for community review. Please provide feedback by replying to
this thread
I think you should avoid the word "staging" entirely in this document.
A staging tree in Xen terminology is something completely different to
how you use it here: it's the tree where the committers push things which
serves as the input to our automated test. How about "development" tree?
Or just avoid them altogether by using the individual developer's own
trees and the lists.
Either approach works for me.
I replaced "staging" with "development" for now and made it
optional. We can leave a final decision open. It shouldn't block the
proposal
Andrii requested a personal repo, which has not been created yet,
but Ian Jackson is doing this as we speak
WRT xen-devel being busy and the subproject's own lists, it might be
wise to have upstream exposure from early on, which would imply ccing
xen-devel/lkml etc in addition to the subproject list. Otherwise you get
into the issue where the subproject has accepted something (perhaps into
a "staging" tree) but when it gets sent upstream it requires major
reworking (and the developer is long gone, etc etc). Whether that needs
to be part of the charter though I don't know.
Agreed. CCing other relevant lists (aka xen-devel/lkml) is common
practice and we should just continue doing this. I can stated this
in the proposal.
More minor thoughts:
"it is likely and desirable that the project may be useful for other"
I'm not sure if this sentence has the end missing or if you
intended other to be "others".
Should read "other use-cases".
(fixed)
"Part of the reason for this is that some of the hardware to test is
also not yet available to open source communities."
This is not (and should not be) a barrier to sending patches to
the right place. We have reviewed and accepted plenty of patches
for which we have no access to the h/w.
You are correct. I deleted this sentence as it doesn't add anything
"To build these drivers, the QNX GNU libc variant is used (licensed
under GPL)."
Not LGPL? QNX using GPL for it's libc seems like an odd choice
for them, since it requires anything linking against it to be
GPL compatible. I suspect this a typo.
Corrected
"Must have OSI approved licenses that are required to link with and
usage the drivers within the native OS."
I can't parse this sentence. I think s/usage/use might be what
was meant but I'm not sure.
Fixed. Meant "use"
"upstreamns"
Typo
Fixed
WRT graduation -- can we include a requirement that any "staging" trees
have been retired (e.g. merged upstream or otherwise obsolete).
Done
Ian.
