> On 5/14/20, 8:04 AM, "David Kastrup" wrote:
>
> Carl Sorensen writes:
>
> > On 5/14/20, 2:31 AM, "lilypond-devel on behalf of Jonas Hahnfeld"
> > > hah...@hahnjo.de> wrote:
> >
> > Am Donnerstag, den 14.05.2020, 08:09 +0100 schrieb James:
> >> On a more general question, and not really
Am Donnerstag, den 14.05.2020, 13:04 + schrieb Carl Sorensen:
>
> On 5/14/20, 2:31 AM, "lilypond-devel on behalf of Jonas Hahnfeld" <
> lilypond-devel-bounces+c_sorensen=byu@gnu.org
> on behalf of
> hah...@hahnjo.de
> > wrote:
>
> Am Donnerstag, den 14.05.2020, 08:09 +0100 schrieb
Carl Sorensen writes:
>> On 5/14/20, 8:04 AM, "David Kastrup" wrote:
>>
>> Patchy, however, is set up in a manner where it picks up work not when
>> staging is ahead of master, but rather when staging is ahead of its last
>> tested version.
>>
>> That means that even if the migration to master
Carl Sorensen writes:
> On 5/14/20, 2:31 AM, "lilypond-devel on behalf of Jonas Hahnfeld"
> hah...@hahnjo.de> wrote:
>
> Am Donnerstag, den 14.05.2020, 08:09 +0100 schrieb James:
>> On a more general question, and not really understanding how this CI
>> workflow will change 'contexturally'
On 5/14/20, 2:31 AM, "lilypond-devel on behalf of Jonas Hahnfeld"
wrote:
Am Donnerstag, den 14.05.2020, 08:09 +0100 schrieb James:
> On a more general question, and not really understanding how this CI
> workflow will change 'contexturally' what we do, so apologies for if
> what I am about
Am Donnerstag, den 14.05.2020, 08:09 +0100 schrieb James:
> On a more general question, and not really understanding how this CI
> workflow will change 'contexturally' what we do, so apologies for if
> what I am about to say is ignorant, but are we still taking the
>
Am Donnerstag, den 14.05.2020, 08:05 +0100 schrieb James:
> On 14/05/2020 07:58, Jonas Hahnfeld wrote:
> > 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.
>
> So for now I can just manually
On a more general question, and not really understanding how this CI
workflow will change 'contexturally' what we do, so apologies for if
what I am about to say is ignorant, but are we still taking the
'master-must-always-be-good' /
On 14/05/2020 07:58, Jonas Hahnfeld wrote:
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.
So for now I can just manually carry on running patchy-merge on staging
as needed?
James
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 wrote:
> > > > > At the current point of time, our pipeline does not tend to be
> > > > > all that full I think. We are not at
Am Mittwoch, den 13.05.2020, 22:33 -0400 schrieb Dan Eble:
> On May 13, 2020, at 17:13, David Kastrup 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...
> > >
> > >
On May 13, 2020, at 17:13, David Kastrup 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
Jonas Hahnfeld writes:
> Am Mittwoch, den 13.05.2020, 21:54 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>> > Hi all,
>> >
>> > as discussed before the migration, we might want to look into using a
>> > CI system. Foremost this would help James who is currently still
>> > testing
Am Mittwoch, den 13.05.2020, 21:54 +0200 schrieb David Kastrup:
> Jonas Hahnfeld writes:
> > Hi all,
> >
> > as discussed before the migration, we might want to look into using a
> > CI system. Foremost this would help James who is currently still
> > testing patches manually. At least the doc
Jonas Hahnfeld writes:
> Hi all,
>
> as discussed before the migration, we might want to look into using a
> CI system. Foremost this would help James who is currently still
> testing patches manually. At least the doc build can and should be
> completely automatic.
> Additionally GitLab has a
Hi all,
as discussed before the migration, we might want to look into using a
CI system. Foremost this would help James who is currently still
testing patches manually. At least the doc build can and should be
completely automatic.
Additionally GitLab has a feature called "Merge Trains", see [1]
16 matches
Mail list logo
