On Mon, Apr 19, 2021 at 12:48:25PM +0200, Thomas Huth wrote:
> On 19/04/2021 12.36, Daniel P. Berrangé wrote:
> > On Mon, Apr 19, 2021 at 12:20:55PM +0200, Thomas Huth wrote:
> > > On 19/04/2021 12.10, Erik Skultety wrote:
> > > > On Mon, Apr 19, 2021 at 10:40:53AM +0100, Daniel P. Berrangé wrote:
> > > > > On Mon, Apr 19, 2021 at 01:34:47AM +0200, Philippe Mathieu-Daudé
> > > > > wrote:
> > > > > > Forks run the same jobs than mainstream, which might be overkill.
> > > > > > Allow them to easily rebase their custom set, while keeping using
> > > > > > the mainstream templates, and ability to pick specific jobs from
> > > > > > the mainstream set.
> > > > > >
> > > > > > To switch to your set, simply add your .gitlab-ci.yml as
> > > > > > .gitlab-ci.d/${CI_PROJECT_NAMESPACE}.yml (where CI_PROJECT_NAMESPACE
> > > > > > is your gitlab 'namespace', usually username). This file will be
> > > > > > used instead of the default mainstream set.
> > > > >
> > > > > I find this approach undesirable, because AFAICT, it means you have
> > > > > to commit this extra file to any of your downstream branches that
> > > > > you want this to be used for. Then you have to be either delete it
> > > > > again before sending patches upstream, or tell git-publish to
> > > > > exclude the commit that adds this.
> > > > >
> > > > > IMHO any per-contributor overhead needs to not involve committing
> > > > > stuff to their git branches, that isn't intended to go upstream.
> > > >
> > > > Not just that, ideally, they should also run all the upstream workloads
> > > > before
> > > > submitting a PR or posting patches because they'd have to respin
> > > > because of a
> > > > potential failure in upstream pipelines anyway.
> > >
> > > It's pretty clear that you want to run the full QEMU CI before submitting
> > > patches to the QEMU project, but I think we are rather talking about forks
> > > here that are meant not meant for immediately contributing to upstream
> > > again, like RHEL where we only build the KVM-related targets and certainly
> > > do not want to test other things like CPUs that are not capable of KVM,
> > > or a
> > > branch where Philippe only wants to check his MIPS-related work during
> > > development.
> > > For contributing patches to upstream, you certainly have to run the full
> > > CI,
> > > but for other things, it's sometimes really useful to cut down the CI
> > > machinery (I'm also doing this in my development branches manually some
> > > times to speed up the CI), so I think this series make sense, indeed.
> >
> > For a downstream like RHEL, I'd just expect them to replace the main
> > .gitlab-ci.yml entirely to suit their downstream needs.
>
> But that still means that we should clean up the main .gitlab-ci.yml file
> anyway, like it is done in this series, to avoid that you always get
> conflicts in this big file with your downstream-only modifications. So at
> least up to patch 11 or 12, I think this is a very valuable work that
> Philippe is doing here.
I don't see a real issue with downstream conflicts. They'll just
periodically pick a release to base themselves off and change once
every 6 months or more.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
