From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [Need Input] (informal) Automotive PV drivers subproject request Date: Sat, 7 Jun 2014 00:01:44 +0200 Message-ID: <1402092104.29895.18.camel@Abyss> References: <538F2BA7.8060806@xen.org> <1401899758.6866.44.camel@Solace> <1402045192.29759.31.camel@kazak.uk.xensource.com> <5391BC9C.40503@xen.org> <1402067321.1313.95.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7369555664568289573==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Artem Mygaiev Cc: Ian Campbell , Ian Jackson , "xen-devel@lists.xen.org" , Lars Kurth , David Vrabel , Andrii Tseglytskyi List-Id: xen-devel@lists.xenproject.org --===============7369555664568289573== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-uhiUpIYORIAVG78gVQki" --=-uhiUpIYORIAVG78gVQki Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 o= f > > 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 cause= d > > me to bring up my concern about forking. >=20 > Well, we do not have enough manpower to support "forks", otherwise we > would create one somewhere long time ago.=20 > 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... >=20 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" <>, 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? >=20 > 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 >=20 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. >=20 > 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.=20 > 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 --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-uhiUpIYORIAVG78gVQki Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEABECAAYFAlOSOkkACgkQk4XaBE3IOsTP1gCfd7LoRmcjL14XMN+J4SNcHuL1 cI8AniYPaVHAm8zMGaEvspDzEpfQ7es+ =Z7R3 -----END PGP SIGNATURE----- --=-uhiUpIYORIAVG78gVQki-- --===============7369555664568289573== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7369555664568289573==--