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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Sat, 7 Jun 2014, Dario Faggioli wrote:
> > >> Officially supported Xen Project repositories should only depend on
> > >> *upstreams* (Xen, Linux, ...). As we are talking about
> > >> git://xenbits.xen.org/pvdrivers.git here (as suggested by Aertem),
> > >> whatever is in that repo (owned by a subproject) should build and work
> > >> with vanilla Xen and Linux.
> > >
> > > Is this pvdrivers.git going to be a descendent (e.g. a git clone) of
> > > xen.git? Or is it a fresh repository which contains this new set of
> > > drivers which do not have a home in xen.git?
> > 
> > pvdrivers.git shall not be a clone for xen.git. Indeed, it is a set of
> > drivers that, as you said, do not have a home in xen.git or kernel.git
> > 
> Indeed. What I've got in mind is something like the following:
> 
> xenbits.org/[artem?]/xen-automotive.git  integration tree
> xenbits.org/pvdrivers.git    'additional pvdrivers' (subproject?) tree
> 
> I concur with Ian that the latter should host everything that does not
> have any proper upstream (like linux userspace components), or that
> can't be upstreamed for non technical reasons (like QNX components).
> What I'd allow is probably for some Linux *kernel* components, just out
> of convenience, although, again, I think the goal there should be
> similar to what we said wrt Xen: *upstream them all*!! :-D

It sounds like we are heading toward creating both personal trees and
pvdrivers.git.

The personal trees would be personal trees like everybody else's: they
could be used for WIP patch series and pull requests. They are no
different from mine and yours.

pvdrivers.git is the interesting one because it would be the upstream
git repository for otherwise homeless pv drivers, such us userspace and
QNX PV drivers.

In my opinion Linux kernel drivers should stay in their personal git
trees as WIP patch series until upsteamed.


On Fri, 6 Jun 2014, Artem Mygaiev wrote:
> > 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?

Given that the staging tree would be a Linux tree plus a collection of
non-upstreamable changes, I would keep it as a branch on one of your
personal repositories. After all in the Linux world it is common to keep
this kind of things as personal trees as you can see from
git.kernel.org.
Even the Linux tree that we used for OSSTests with Xen on ARM is just a
branch on my personal Linux git repository for example.

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