On Jun 6, 2020, at 16:03, Jonas Hahnfeld wrote:
> Am Samstag, den 06.06.2020, 15:47 -0400 schrieb Dan Eble:
>> On Jun 6, 2020, at 15:26, Dan Eble wrote:
>>> split the doc stage of the build into multiple stages that can be run in
>>> parallel on different runners
>>
>> For example, assigning
Am Samstag, den 06.06.2020, 08:57 +0100 schrieb Kevin Barry:
> The fast-forward rebase has two advantages that I can think of:
> - the git history is cleaner/easier to parse
> - it prevents the situation that sometimes arises where a couple of
> patches - that pass testing independently, but
Dan Eble writes:
> Would we still be validating LilyPond properly if we split the doc
> stage of the build into multiple stages that can be run in parallel on
> different runners, or is it fundamentally important that we test "make
> doc"?
Well, given the current frequency of build system
Am Samstag, den 06.06.2020, 15:47 -0400 schrieb Dan Eble:
> On Jun 6, 2020, at 15:26, Dan Eble wrote:
> > split the doc stage of the build into multiple stages that can be run in
> > parallel on different runners
>
> For example, assigning each runner one or more languages to build.
In my
On Jun 6, 2020, at 15:26, Dan Eble wrote:
>
> split the doc stage of the build into multiple stages that can be run in
> parallel on different runners
For example, assigning each runner one or more languages to build.
—
Dan
Hi all,
while fixing some broken URLs in the documentation, I noticed that
some URLs do have possible line breaking points manually specified like
@uref{http://@/www@/.schemers@/.org}
Others are just plain URLs like
@uref{http://www.schemers.org/Documents/Standards/R5RS/}
Is there a reason
Would we still be validating LilyPond properly if we split the doc stage of the
build into multiple stages that can be run in parallel on different runners, or
is it fundamentally important that we test "make doc"?
—
Dan
Hello,
Here is the current patch countdown list. The next countdown will be on
June 8th.
A list of all merge requests can be found here:
https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority
Push:
!80 Resolve "fingeringOrientations don't deal properly with omitted
Han-Wen Nienhuys writes:
> On Fri, May 29, 2020 at 7:22 PM Han-Wen Nienhuys wrote:
>> > On 5/27/20, Jonas Hahnfeld wrote:
>> > > No, "rebase" is currently manual (with "merge when pipeline succeeds"
>> > > being automatic). This has been clearly communicated, sorry if you
>> > > missed that.
On Fri, May 29, 2020 at 7:22 PM Han-Wen Nienhuys wrote:
> > On 5/27/20, Jonas Hahnfeld wrote:
> > > No, "rebase" is currently manual (with "merge when pipeline succeeds"
> > > being automatic). This has been clearly communicated, sorry if you
> > > missed that.
> >
> > Hey Jonas, hey everybody;
The fast-forward rebase has two advantages that I can think of:
- the git history is cleaner/easier to parse
- it prevents the situation that sometimes arises where a couple of
patches - that pass testing independently, but will break when
combined - from making it into master (and breaking
11 matches
Mail list logo
