Re: [Xen-devel] [Need Input] (informal) Automotive PV drivers subproject request

[Lars Kurth <lars.kurth@xxxxxxx>]

On 06/06/2014 20:49, Artem Mygaiev wrote:
> > > > > > > [need input] Should these be owned by a separate subproject or
> > > > > > > attached to an existing subproject (e.g. the Hypervisor project)
[snip]
> > There seems to be a lot of mixing the concept of personal git trees with
> > git trees related to subprojects, or at least it isn't always clear
> > which one people are talking about. The two are very different things
> > IMHO and it's not clear to me how any of the proposals you make above
> > other than the first (the Andrii has a personal tree option) relates to
> > the proposed new project being discussed in this thread.
> >
> > Putting subproject trees under /people/, which I'm not sure if you are
> > proposing or not in some of the above options, is confusing.
> It seem to me that use of /people/ for subprojects may be misleading,
> too... The goal of our integration tree is to serve as a staging tree
> before upstreaming, hold all temporary hacks to support platforms and
> specific use cases and also for the needs of ci and qa... Having that
> code tested and working on automotive platforms like J6 we could be
> able to involve our clients to xen. Would something like
> xen.org/automotive.git or whatever similar be possible?
Sorry for the confusion. What I was trying to say:
* We would have an official tree pvdrivers.git tree owned by the 
subproject aka xenbits/pvdrivers.git alongside xenbits/xen, which works 
with upstream linux and xen.git. No hacks allowed in there.
* In *addition* we would need integration or personal repos (however we 
want to call them) as work-in-progress and development branches for 
linux, xen and pvdrivers.git - these could contain some hacks for a 
limited period. The reason is because the code as it is contains some 
dependencies on hacks elsewhere. This discussion was about the naming of 
the best naming convention for this integration tree.
I wasn't arguing for moving the official tree of the subproject into the 
people directory
> > > Can someone enlighten me why Linux user-space drivers may be
> > > different?
> > There is no "upstream Linux user-space driver" project which these
> > drivers can be contributed to. So either we become that upstream for Xen
> > related drivers, or a new pvdrivers project does.
> We would not mix userspace or non-Linux drivers with xen repo or Linux
> repo. We do believe that this shall be a separate project.
OK. This makes sense. So if we are all agreed pvdrivers.git can contain 
"user-space Linux drivers", but maybe we can label them by calling the 
directory in which these sit as linux-user or some other terminology 
that makes this clear (and avoids debate)
Regards
Lars

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