Re: Obstacles for using GitLab CI

[Jonas Hahnfeld]

Am Donnerstag, den 14.05.2020, 08:20 +0200 schrieb Urs Liska:
> Am Mittwoch, den 13.05.2020, 22:33 -0400 schrieb Dan Eble:
> > On May 13, 2020, at 17:13, David Kastrup <address@hidden> wrote:
> > > > > At the current point of time, our pipeline does not tend to be
> > > > > all that full I think.  We are not at Linux kernel levels of
> > > > > participation...
> > > > 
> > > > No, you're probably right. It's only a bit more bothersome if you
> > > > have multiple changes to submit from the same countdown.
> > > 
> > > The real problem starts when people don't manage to get their patch
> > > in because the pipeline is always busy.  But if we are there, the free
> > > CI plan will most certainly not do the trick anymore.
> > 
> > One thing is clear: we need to make sure we don't abuse James'
> > generosity, so I'm willing to try whatever system you think will be
> > the fairest all around, even if it might be a bit "bothersome" as an
> > individual submitter from time to time.
> 
> That's true.
> But I'd like to disencourage (can you say that?) using our small
> contribution frequency as an argument here. Making it easier to
> contribute and as a consequence have more contribution was a major
> motivation behind all this. So while we'll surely never get to a Linux
> kernel situation having a solution that scales to some activity
> substantially increased from what we have now should be a requirement.

Should this really become a problem and GitLab not offer a solution by
then, we can of course still build our own queuing solution: Invent
something like Patch::merge and let a cron job periodically check for
merge requests with this label and apply them. This should be doable
via the API (did I say I love documented API endpoints?).

Thanks for all the feedback so far, I'll then work to propose something
simple that can at least get us started. Afterwards we can work from
there.

Jonas

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