Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages] [and 2 more messages]

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 2 Nov 2018, Julien Grall wrote:
> On 02/11/2018 17:56, Stefano Stabellini wrote:
> > On Fri, 2 Nov 2018, Ian Jackson wrote:
> > > Ie the biggest work here of all kinds is is glue.  Adding more
> > > entities to the problem will increase rather than reduce the amount of
> > > glue code that needs to be written.
> > 
> > Basically, you are saying that even if had a well maintained deb
> > repository of kernel packages for OSSTest to use, doesn't matter how we
> > achieve this goal, it would still require a non trivial amount of work
> > to do the integration with OSSTest.
> 
> This is not how I understood the thread. I believe this was related to use an
> external CI loop.
> 
> In our case, once we have a deb package. Then this is not much different than
> using a backport kernel. We already have such support in Osstest, so it should
> not be too difficult to adapt it for a different repo.

OK, I misunderstood Ian, thanks for stepping in. If that is the case, then:

1) We already have a Xen ARM Linux tree which we have to maintain for Dom0
The maintenance model and testing of this tree doesn't change regardless.

2) We already have Dockerfiles and scripts by Doug and ViryaOS to build kernels 
on gitlab
We could improve them to build a full deb repository.

What's stopping us from using (2) to setup up a Xen Project deb repo?

Does it really matter who executes scripts (2) and whether they are run
on your laptop or in the cloud as long as the build is fully
reproducible? We are not talking about hacking config files around and
using who knows what compiler to build something. docker build will give
you the same output no matter the host.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel