Am Donnerstag, den 21.05.2020, 13:02 +0200 schrieb Han-Wen Nienhuys:
> On Thu, May 21, 2020 at 12:34 PM Jonas Hahnfeld wrote:
> > Am Dienstag, den 19.05.2020, 08:08 -0400 schrieb Dan Eble:
> > > On May 17, 2020, at 15:27, Jonas Hahnfeld wrote:
> > > > before merging. As we only allow
Am Donnerstag, den 21.05.2020, 18:25 +0200 schrieb David Kastrup:
> > If we think contention will be a problem, we cannot do the proposal.
> > There's no sane "mixed bag": As outlined initially, we would 1)
> > require CI for merge requests, and 2) disable direct pushes to
> > master. This
Jonas Hahnfeld writes:
> Am Donnerstag, den 21.05.2020, 17:21 +0200 schrieb Han-Wen Nienhuys:
>> On Thu, May 21, 2020 at 1:17 PM James wrote:
>> > On 21/05/2020 12:02, Han-Wen Nienhuys wrote:
>> > > so a next step might be making the countdown process more
>> > > continuous.
>> >
>> > What
Jonas Hahnfeld writes:
> Am Donnerstag, den 21.05.2020, 17:10 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>> > Am Donnerstag, den 21.05.2020, 15:19 +0200 schrieb David Kastrup:
>> > > Jonas Hahnfeld writes:
>> > > > Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup:
Am Donnerstag, den 21.05.2020, 17:10 +0200 schrieb David Kastrup:
> Jonas Hahnfeld writes:
> > Am Donnerstag, den 21.05.2020, 15:19 +0200 schrieb David Kastrup:
> > > Jonas Hahnfeld writes:
> > > > Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup:
> > > > > The "traffic jam"
Am Donnerstag, den 21.05.2020, 17:21 +0200 schrieb Han-Wen Nienhuys:
> On Thu, May 21, 2020 at 1:17 PM James wrote:
> > On 21/05/2020 12:02, Han-Wen Nienhuys wrote:
> > > so a next step might be making the countdown process more
> > > continuous.
> >
> > What does that mean - even conceptually?
On Thu, May 21, 2020 at 1:17 PM James wrote:
>
>
> On 21/05/2020 12:02, Han-Wen Nienhuys wrote:
> > so a next step might be making the countdown process more
> > continuous.
>
> What does that mean - even conceptually?
My idea is that patches could enter 'countdown' stage throughout the
day, and
Jonas Hahnfeld writes:
> Am Donnerstag, den 21.05.2020, 15:19 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>> > Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup:
>> > > The "traffic jam" problem could be avoided by retaining the option of
>> > > pushing to staging.
Am Donnerstag, den 21.05.2020, 15:19 +0200 schrieb David Kastrup:
> Jonas Hahnfeld writes:
> > Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup:
> > > The "traffic jam" problem could be avoided by retaining the option of
> > > pushing to staging. That would occur without CI, but
Jonas Hahnfeld writes:
> Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>> > Am Dienstag, den 19.05.2020, 08:08 -0400 schrieb Dan Eble:
>> > > On May 17, 2020, at 15:27, Jonas Hahnfeld wrote:
>> > > > before merging. As we only allow fast-forward
Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup:
> Jonas Hahnfeld writes:
> > Am Dienstag, den 19.05.2020, 08:08 -0400 schrieb Dan Eble:
> > > On May 17, 2020, at 15:27, Jonas Hahnfeld wrote:
> > > > before merging. As we only allow fast-forward merges, this means each
> > > >
Jonas Hahnfeld writes:
> Am Dienstag, den 19.05.2020, 08:08 -0400 schrieb Dan Eble:
>> On May 17, 2020, at 15:27, Jonas Hahnfeld wrote:
>> > before merging. As we only allow fast-forward merges, this means each
>> > MR has received testing in the form it hits master. This would
>> > effectively
On 21/05/2020 12:02, Han-Wen Nienhuys wrote:
so a next step might be making the countdown process more
continuous.
What does that mean - even conceptually?
The countdown is specifically to allow everyone some time to breathe and
digest patches submitted without the fear of having to be
On Thu, May 21, 2020 at 12:34 PM Jonas Hahnfeld wrote:
>
> Am Dienstag, den 19.05.2020, 08:08 -0400 schrieb Dan Eble:
> > On May 17, 2020, at 15:27, Jonas Hahnfeld wrote:
> > > before merging. As we only allow fast-forward merges, this means each
> > > MR has received testing in the form it hits
Am Dienstag, den 19.05.2020, 08:08 -0400 schrieb Dan Eble:
> On May 17, 2020, at 15:27, Jonas Hahnfeld wrote:
> > before merging. As we only allow fast-forward merges, this means each
> > MR has received testing in the form it hits master. This would
> > effectively replace the current setup of
On May 17, 2020, at 15:27, Jonas Hahnfeld wrote:
>
> before merging. As we only allow fast-forward merges, this means each
> MR has received testing in the form it hits master. This would
> effectively replace the current setup of pushing to staging.
I'm for this.
—
Dan
Am Montag, den 18.05.2020, 17:50 +0200 schrieb Jonas Hahnfeld:
> Am Montag, den 18.05.2020, 12:59 +0200 schrieb Jonas Hahnfeld:
> > Am Montag, den 18.05.2020, 11:53 +0100 schrieb Kevin Barry:
> > > On Mon, May 18, 2020 at 11:29:35AM +0100, James Lowe wrote:
> > > > Countdown.py (which is Jonas'
Am Montag, den 18.05.2020, 12:59 +0200 schrieb Jonas Hahnfeld:
> Am Montag, den 18.05.2020, 11:53 +0100 schrieb Kevin Barry:
> > On Mon, May 18, 2020 at 11:29:35AM +0100, James Lowe wrote:
> > > Countdown.py (which is Jonas' great cli tool) it's what you see when I do
> > > the countdown (that's
Am Montag, den 18.05.2020, 11:53 +0100 schrieb Kevin Barry:
> On Mon, May 18, 2020 at 11:29:35AM +0100, James Lowe wrote:
> > Countdown.py (which is Jonas' great cli tool) it's what you see when I do
> > the countdown (that's literally cut/paste).
>
> I haven't seen that script, but the gitlab
On Mon, May 18, 2020 at 11:29:35AM +0100, James Lowe wrote:
> Countdown.py (which is Jonas' great cli tool) it's what you see when I do
> the countdown (that's literally cut/paste).
I haven't seen that script, but the gitlab API exposes pipeline
information. It should be enough to correlate a
On 18/05/2020 11:21, Kevin Barry wrote:
On Mon, May 18, 2020 at 12:17:53PM +0200, Urs Liska wrote:
No, at least not at the time I looked.
What James needs is additionally an icon that states that MR is
*currently* being tested.
There is an icon for that (it's blue and looks like a half-filled
On Mon, May 18, 2020 at 12:17:53PM +0200, Urs Liska wrote:
> No, at least not at the time I looked.
> What James needs is additionally an icon that states that MR is
> *currently* being tested.
There is an icon for that (it's blue and looks like a half-filled pie
chart) - I just couldn't find a
Am Montag, den 18.05.2020, 11:15 +0100 schrieb Kevin Barry:
> On Mon, May 18, 2020 at 10:48:55AM +0100, James Lowe wrote:
> > but how do I know? That is the nub of what I am asking. If a patch
> > is 'new'
> > how do I know that an automated make doc is 'in progress, has
> > completed with
> >
On Mon, May 18, 2020 at 10:48:55AM +0100, James Lowe wrote:
> but how do I know? That is the nub of what I am asking. If a patch is 'new'
> how do I know that an automated make doc is 'in progress, has completed with
> errors, has completed without errors' as I am not going to bother to do any
>
On 18/05/2020 10:29, Jonas Hahnfeld wrote:
Am Sonntag, den 17.05.2020, 21:14 +0100 schrieb James Lowe:
On 17/05/2020 20:27, Jonas Hahnfeld wrote:
- Comparison of regression tests is not yet integrated, the main
problem being the need for a baseline. I already have an idea or two
how this
Am Sonntag, den 17.05.2020, 21:14 +0100 schrieb James Lowe:
> On 17/05/2020 20:27, Jonas Hahnfeld wrote:
> > - Comparison of regression tests is not yet integrated, the main
> > problem being the need for a baseline. I already have an idea or two
> > how this could work, but for now I'm focusing
On Sun, May 17, 2020, 3:11 PM Dan Eble wrote:
> I might be willing to plug in a cheap, headless computer to crank through
> patches night and day, but probably not if it will upload GBs of results.
>
I can also offer this, from a computer shop with lots of spare hardware and
an unmetered 30
Am Sonntag, den 17.05.2020, 16:10 -0400 schrieb Dan Eble:
> On May 17, 2020, at 15:27, Jonas Hahnfeld wrote:
> > if we want to get faster builds, we can always add our own machines.
> > That is a matter of installing Docker and the runner (packages provided
> > by GitLab). Configuration is as
On 17/05/2020 20:27, Jonas Hahnfeld wrote:
- Comparison of regression tests is not yet integrated, the main
problem being the need for a baseline. I already have an idea or two
how this could work, but for now I'm focusing on the initial setup.
This means James still needs to download the
On May 17, 2020, at 15:27, Jonas Hahnfeld wrote:
> if we want to get faster builds, we can always add our own machines.
> That is a matter of installing Docker and the runner (packages provided
> by GitLab). Configuration is as simple as running one command and
> pasting the URL as well as a
I'd like to propose that we enable GitLab CI and use it for
automatically testing our merge requests. It would run 'make', 'make
test', and 'make doc' like the current manual testing process. Once we
have that, GitLab can be configured to enforce a successful pipeline
before merging. As we only
31 matches
Mail list logo
