-
> Phil Holmes
>
>
> - Original Message -
> From: "Jonas Hahnfeld" <
> hah...@hahnjo.de
> >
> To: "Han-Wen Nienhuys" <
> hanw...@gmail.com
> >
> Cc: "David Kastrup" <
> d...@gnu.org
> >; "lilypond-devel&q
avid Kastrup" ; "lilypond-devel"
Sent: Thursday, March 05, 2020 6:54 PM
Subject: Re: 2.21.0 release plans and considerations
Am Donnerstag, den 05.03.2020, 19:50 +0100 schrieb Han-Wen Nienhuys:
>
>
> On Thu, Mar 5, 2020 at 2:16 PM Jonas Hahnfeld wrote:
> > > * I'd base it off Git commits rather than tarballs. The tarballs are
> > > anachronistic, and with git commits, it will be easier to build binaries
> > > for
On Thu, Mar 5, 2020 at 2:16 PM Jonas Hahnfeld wrote:
> > * I'd base it off Git commits rather than tarballs. The tarballs are
> anachronistic, and with git commits, it will be easier to build binaries
> for pending changes (to make sure they don't break the process).
>
> Nope, I'm not a huge fan
Am Donnerstag, den 05.03.2020, 11:45 +0100 schrieb Han-Wen Nienhuys:
> On Wed, Mar 4, 2020 at 9:46 AM Jonas Hahnfeld wrote:
> > The basic idea is to produce native binaries with all dependencies
> > compiled as static libraries, with dependencies only on the most basic
>
> I applaud that, but I
On Wed, Mar 4, 2020 at 9:46 AM Jonas Hahnfeld wrote:
> Am Mittwoch, den 04.03.2020, 09:34 +0100 schrieb Han-Wen Nienhuys:
> > On Sun, Mar 1, 2020 at 3:12 PM Jonas Hahnfeld <
> > hah...@hahnjo.de
> > > wrote:
> > > For example, I'd very much like #5799 to be part of 2.21.0 to be able
> > > to
Am Mittwoch, den 04.03.2020, 09:34 +0100 schrieb Han-Wen Nienhuys:
> On Sun, Mar 1, 2020 at 3:12 PM Jonas Hahnfeld <
> hah...@hahnjo.de
> > wrote:
> > For example, I'd very much like #5799 to be part of 2.21.0 to be able
> > to cross-compile to x86_64-w64-mingw32 and show-case a replacement for
>
On Sun, Mar 1, 2020 at 3:12 PM Jonas Hahnfeld wrote:
> For example, I'd very much like #5799 to be part of 2.21.0 to be able
> to cross-compile to x86_64-w64-mingw32 and show-case a replacement for
> GUB. However I acknowledge that the changes have at least the potential
> to break the current
Jonas Hahnfeld writes:
> Sure, the solution is to apply #5799. Turns out the solution is not
> only for x86_64-w64-mingw32 but also for 32 bit mingw that GUB
> uses. So I'm arguing that it should go in before 2.21.0 is cut.
Well, the rationale for being conservative with new patches is so that
Am Montag, den 02.03.2020, 19:38 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> hah...@hahnjo.de
> > writes:
>
> > Am Montag, den 02.03.2020, 10:48 +0100 schrieb Jonas Hahnfeld:
> > > Am Sonntag, den 01.03.2020, 15:39 +0100 schrieb David Kastrup:
> > > > But fortunately, we are now at the
Jonas Hahnfeld writes:
> Am Montag, den 02.03.2020, 10:48 +0100 schrieb Jonas Hahnfeld:
>> Am Sonntag, den 01.03.2020, 15:39 +0100 schrieb David Kastrup:
>> >
>> > But fortunately, we are now at the point where 2.20 _and_ 2.21 are going
>> > to be a thing rather soon. Assuming that things like
Am Montag, den 02.03.2020, 10:48 +0100 schrieb Jonas Hahnfeld:
> Am Sonntag, den 01.03.2020, 15:39 +0100 schrieb David Kastrup:
> >
> > But fortunately, we are now at the point where 2.20 _and_ 2.21 are going
> > to be a thing rather soon. Assuming that things like the Python3
> > migration
Am Sonntag, den 01.03.2020, 15:39 +0100 schrieb David Kastrup:
>
> But fortunately, we are now at the point where 2.20 _and_ 2.21 are going
> to be a thing rather soon. Assuming that things like the Python3
> migration don't cause more of a standstill for 2.21.0 than we imagine,
> but then one
Jonas Hahnfeld writes:
> could you maybe flag those patches under review that you think should
> not go in? I guess everybody considers the own changes to be
> "important", so I'm not 100% sure which patches fall under that
> category.
"Important" is absolutely no criterion. It has been easy
14 matches
Mail list logo
