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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Fri, 2014-06-06 at 22:49 +0300, Artem Mygaiev wrote:
> > Perhaps should be the subject of this discussion, but we had somehow
> > ended up talking about Xen core changes. In particular there was talk of
> > putting things into these staging trees which it was known would not go
> > upstream ("things which should not leave staging tree"). At that point
> > they are no longer a staging tree, they are a fork. That was what caused
> > me to bring up my concern about forking.
> 
> Well, we do not have enough manpower to support "forks", otherwise we
> would create one somewhere long time ago. 
>
Well... I can't comment on the amount of manpower, but I'm happy that
there's not a Xen-automotive fork, and that we're discussing this here,
at least! :-D

> We want to a single work
> tree which we can use for development so it may have some _temporary_
> hacks - and this is something we want to avoid! but it is not always
> possible. And we need a single tree since we are adding continuous
> integration and automated testing of xen on embedded platform(s). Of
> course, we will need to synchronise frequently, and we have someone to
> be responsible for this to not deviate from the mainline. Having said
> that, I perfectly understand your concerns - there are thousands of
> useless abandoned project forks in OSS world...
> 
Exactly. So, as I already first suggested and as Ian restated, I don't
see the problem if this stating/temporary/integration/whatever tree is
someone's personal tree.

And I'm not saying that we should have subproject repo(s) under
xenbits.org/people, I'm saying that, to get the bleeding edge of Xen for
automotive, the version that supports all the feature and all the
pvdrivers on all OSes, etc, you should clone and build Artem's git tree,
or Andrii's one, or whatever other one...

After all, although this predates my involvement in Xen, it's not long
ago that, if one wanted to use Xen as Dom0, with all the coolest
features, he needed to clone and track Jeremy's tree, or Konrad's one,
is it?

The only thing that needs, IMHO, to be clear, is whether or not there
are non-upstreamable bits, and I'm talking about non-upstreamable in the
long term. If there are, we've got a problem (and perhaps we should
store the patches somewhere, as Ian was also said, or something like
that). If there are not, if the goal is to upstream everything in
xen.git and if we think such goal to be reasonable, and the problem is
"only" <<but what about in the meantime>>, well, xenbits.org/people/xxx
seems fine to me.

After all, it's all a matter of what you tell people to clone and track,
and on how you manage such tree yourself, deal with contributions from
others, etc.

What's wrong with this approach?

> >> 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

> > 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. 
>
Right. And if we call the pvdrivers the subproject, and put it somewhere
else than /people, but we keep the xen tree under people --and not call
it a subproject-- what's the problem your clients would face?

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

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