Han-Wen Nienhuys writes:
> On Sat, Sep 12, 2020 at 11:28 AM Jonas Hahnfeld wrote:
>>
>> > >> Similarly, if I change a documentation string in an SCM file like
>> > >> `define-markup-commands.scm`, the documentation doesn't get
>> > >> rebuilt, either.
>> > >
>> > > I can look at reintroducing
On Sep 13, 2020, at 12:57, Jonas Hahnfeld wrote:
> Am Sonntag, den 13.09.2020, 11:59 +0200 schrieb Han-Wen Nienhuys:
...
>> What annoys me is that the default build creates the info docs, which
>> aren't necessary for developing lilypond.
>
> I guess that has to stay because we want
Am Sonntag, den 13.09.2020, 11:59 +0200 schrieb Han-Wen Nienhuys:
> On Sat, Sep 12, 2020 at 11:28 AM Jonas Hahnfeld wrote:
> > > > > Similarly, if I change a documentation string in an SCM file like
> > > > > `define-markup-commands.scm`, the documentation doesn't get
> > > > > rebuilt, either.
>
On Sat, Sep 12, 2020 at 11:28 AM Jonas Hahnfeld wrote:
>
> > >> Similarly, if I change a documentation string in an SCM file like
> > >> `define-markup-commands.scm`, the documentation doesn't get
> > >> rebuilt, either.
> > >
> > > I can look at reintroducing the SCM -> texi dependencies.
> >
>
Am Freitag, den 11.09.2020, 19:10 +0200 schrieb Werner LEMBERG:
> >> This is not my proposal anymore to just branch, but Han-Wen's idea
> >> of having a freeze of 3-4 weeks before branching.
> >
> > For me, a freeze can only start if we agree that nothing fundamental
> > has to be changed or
Am Samstag, den 12.09.2020, 14:21 +0200 schrieb Werner LEMBERG:
> >> > make out=www out-www/en/notation.pdf
> >>
> >> Aah, I tried without `out=www`. This incantation is good enough for
> >> me, thanks. No further action needed.
> >
> > Actually that's the same as before, no?
>
> No.
>> > make out=www out-www/en/notation.pdf
>>
>> Aah, I tried without `out=www`. This incantation is good enough for
>> me, thanks. No further action needed.
>
> Actually that's the same as before, no?
No. Previously, `notation.pdf` was a first-class target: If you
deleted it, a call to
Am Samstag, den 12.09.2020, 06:42 +0200 schrieb Werner LEMBERG:
> >> [...] if I delete a PDF file, say, `notation.pdf`, right now it
> >> gets *not* rebuilt!
> >
> > The new documentation build has much more accurate dependency
> > tracking, so if you want to rebuild notation.pdf, you can just
>
> I can look at reintroducing the SCM -> texi dependencies.
Please do so. Due to the auto-generation process, it is far from
trivial to find out which command has to be called.
>> I consider this fundamental flaws.
>
> I disagree. These flaws might be a bother for developers, but
On Sep 11, 2020, at 15:19, James Lowe wrote:
>
> On 11/09/2020 20:13, Han-Wen Nienhuys wrote:
>>> I consider this fundamental flaws.
>> I disagree. These flaws might be a bother for developers, but
>> branching stable/2.22 is about not having user-visible regres
On 11/09/2020 20:13, Han-Wen Nienhuys wrote:
I consider this fundamental flaws.
I disagree. These flaws might be a bother for developers, but
branching stable/2.22 is about not having user-visible regressions of
lilypond itself, relative to 2.20, which has nothing to do with how
developers
d notation.pdf, you can just say so:
make out=www out-www/en/notation.pdf
> Similarly, if I change a documentation string in an SCM file
> like `define-markup-commands.scm`, the documentation doesn't get
> rebuilt, either.
I can look at reintroducing the SCM -> texi dependencies.
> I
>> This is not my proposal anymore to just branch, but Han-Wen's idea
>> of having a freeze of 3-4 weeks before branching.
>
> For me, a freeze can only start if we agree that nothing fundamental
> has to be changed or added. IMHO, we are far away from such a
> state.
What we can start,
>> > I don't see that in the current stage of upheaval of both
>> > internals and build system and infrastructure, there is a point
>> > in freezing off some half-baked intermediate state that hasn't
>> > seen significant exposure to extensive testing.
>>
>> +1 It's too early IMHO. Let's wait
Am Freitag, den 11.09.2020, 16:18 +0100 schrieb James Lowe:
> On 11/09/2020 15:22, David Kastrup wrote:
> > Jonas Hahnfeld writes:
> >
> > > Am Sonntag, den 06.09.2020, 13:40 +0200 schrieb Jonas Hahnfeld:
> > > > Am Sonntag, den 06.09.2020, 12:33 +0200 schrieb Han-Wen Nienhuys:
> > > > > Here is
Am Freitag, den 11.09.2020, 17:14 +0200 schrieb Werner LEMBERG:
> > I don't see that in the current stage of upheaval of both internals and
> > build system and infrastructure, there is a point in freezing off some
> > half-baked intermediate state that hasn't seen significant exposure to
> >
On 11/09/2020 15:22, David Kastrup wrote:
Jonas Hahnfeld writes:
Am Sonntag, den 06.09.2020, 13:40 +0200 schrieb Jonas Hahnfeld:
Am Sonntag, den 06.09.2020, 12:33 +0200 schrieb Han-Wen Nienhuys:
Here is my proposal for how to go ahead:
* we build a 2.21.6 from master, and announce it
> I don't see that in the current stage of upheaval of both internals and
> build system and infrastructure, there is a point in freezing off some
> half-baked intermediate state that hasn't seen significant exposure to
> extensive testing.
+1 It's too early IMHO. Let's wait at laest a month.
Jonas Hahnfeld writes:
> Am Sonntag, den 06.09.2020, 13:40 +0200 schrieb Jonas Hahnfeld:
>> Am Sonntag, den 06.09.2020, 12:33 +0200 schrieb Han-Wen Nienhuys:
>> > Here is my proposal for how to go ahead:
>> >
>> > * we build a 2.21.6 from master, and announce it widely as a 2.22
>> >
Am Sonntag, den 06.09.2020, 13:40 +0200 schrieb Jonas Hahnfeld:
> Am Sonntag, den 06.09.2020, 12:33 +0200 schrieb Han-Wen Nienhuys:
> > Here is my proposal for how to go ahead:
> >
> > * we build a 2.21.6 from master, and announce it widely as a 2.22
> > pre-release version.
>
> Adding Phil. I
On Sun, Sep 6, 2020 at 1:40 PM Jonas Hahnfeld wrote:
>
> Am Sonntag, den 06.09.2020, 12:33 +0200 schrieb Han-Wen Nienhuys:
> > On Sat, Sep 5, 2020 at 10:52 AM Jonas Hahnfeld wrote:
> > > > I think the real problem is that we don't know exactly how many
> > > > problems there are that would be
Am So., 6. Sept. 2020 um 12:33 Uhr schrieb Han-Wen Nienhuys :
> I am not aware of critical issues at the moment.
At least
https://gitlab.com/lilypond/lilypond/-/issues?scope=all=%E2%9C%93=opened_name[]=Critical
returns empty.
Some issues are labeled "crash" though:
Am Sonntag, den 06.09.2020, 12:33 +0200 schrieb Han-Wen Nienhuys:
> On Sat, Sep 5, 2020 at 10:52 AM Jonas Hahnfeld wrote:
> > > I think the real problem is that we don't know exactly how many
> > > problems there are that would be unacceptable in a stable release. So
> > > we need a way to coax
On Sat, Sep 5, 2020 at 10:52 AM Jonas Hahnfeld wrote:
> > I think the real problem is that we don't know exactly how many
> > problems there are that would be unacceptable in a stable release. So
> > we need a way to coax people normally on stable releases to try out
> > our current master, so we
Am Freitag, den 04.09.2020, 22:49 +0200 schrieb Han-Wen Nienhuys:
> On Thu, Sep 3, 2020 at 11:16 AM Jonas Hahnfeld wrote:
> > Am Mittwoch, den 26.08.2020, 00:05 +0200 schrieb Han-Wen Nienhuys:
> > > On Tue, Aug 25, 2020 at 11:17 PM Jonas Hahnfeld wrote:
> > > > > I think the stabilization effort
On Thu, Sep 3, 2020 at 11:16 AM Jonas Hahnfeld wrote:
>
> Am Mittwoch, den 26.08.2020, 00:05 +0200 schrieb Han-Wen Nienhuys:
> > On Tue, Aug 25, 2020 at 11:17 PM Jonas Hahnfeld wrote:
> > > > I think the stabilization effort could be a joint effort by the entire
> > > > dev team, by agreeing
Jonas Hahnfeld writes:
> Am Mittwoch, den 26.08.2020, 00:05 +0200 schrieb Han-Wen Nienhuys:
>> On Tue, Aug 25, 2020 at 11:17 PM Jonas Hahnfeld wrote:
>> > > I think the stabilization effort could be a joint effort by the entire
>> > > dev team, by agreeing with the team to hold off on new
Am Mittwoch, den 26.08.2020, 00:05 +0200 schrieb Han-Wen Nienhuys:
> On Tue, Aug 25, 2020 at 11:17 PM Jonas Hahnfeld wrote:
> > > I think the stabilization effort could be a joint effort by the entire
> > > dev team, by agreeing with the team to hold off on new features and
> > > invasive changes
Jonas Hahnfeld writes:
> Am Dienstag, den 25.08.2020, 07:51 -0600 schrieb Carl Sorensen:
>> On Tue, Aug 25, 2020 at 7:13 AM Jonas Hahnfeld wrote:
>> > I know I'll regret it because I still don't know what objective
>> > criteria others have, but as you really insist on a statement:
>> > in the
Am Dienstag, den 25.08.2020, 07:51 -0600 schrieb Carl Sorensen:
> On Tue, Aug 25, 2020 at 7:13 AM Jonas Hahnfeld wrote:
> > I know I'll regret it because I still don't know what objective
> > criteria others have, but as you really insist on a statement:
> > in the week of 14th of September (this
Am Dienstag, den 25.08.2020, 22:56 +0200 schrieb Han-Wen Nienhuys:
> On Tue, Aug 25, 2020 at 8:31 AM Jonas Hahnfeld wrote:
> > I don't understand why you would want to backport features? IMO that's
> > got nothing to do with how far the stable branch diverges.
> >
> > > Whatever the option, we
On Tue, Aug 25, 2020 at 8:31 AM Jonas Hahnfeld wrote:
> I don't understand why you would want to backport features? IMO that's
> got nothing to do with how far the stable branch diverges.
>
> > Whatever the option, we will need people to manage the release (yes, I
> > could possibly help next
> I concur with the idea that a properly functioning full conversion to
> Python 3 and workable (though not required) Guile 2 constitutes sufficient
> change for the next stable version. No other features are needed.
I agree with this.
Kevin
On Aug 25, 2020, at 09:51, Carl Sorensen wrote:
>
> Once we have an unstable release with the build system in good shape (all
> the auxiliary scripts work well, the website builds correctly, the MacOS
> build is functional at least on MacPorts), I'd be in favor of creating a
> pre-release
> Now go off tearing me apart.
That one was a blow in my stomach.(In fact, I was about to write something
similar in my last message.)
Taking stock on the thread, my reactions were not appropriate, especially the
fourth one which is rubbish. I should have anticipated that personal issues
On Tue, Aug 25, 2020 at 7:13 AM Jonas Hahnfeld wrote:
>
> I know I'll regret it because I still don't know what objective
> criteria others have, but as you really insist on a statement:
> in the week of 14th of September (this year, 2020, just to be clear)
> or put differently: right after
Am Dienstag, den 25.08.2020, 14:43 +0200 schrieb Jean Abou Samra:
> > Le 25 août 2020 à 12:29, Jonas Hahnfeld a écrit :
> >
> > Am Dienstag, den 25.08.2020, 12:06 +0200 schrieb Jean Abou Samra:
> > > > Le 25 août 2020 à 08:30, Jonas Hahnfeld a écrit :
> > > > For me, creating the branch is
Forgot the list, sorry.
Début du message transféré :
> Expéditeur: Jean Abou Samra
> Date: 25 août 2020 14:43:21 UTC+2
> Destinataire: Jonas Hahnfeld
> Objet: Rép : branching stable/2.22?
>
>
>> Le 25 août 2020 à 12:29, Jonas Hahnfeld a écrit :
>>
>>
the 2.22
> > > > > > > release for May 2021, for example?
> > > > > >
> > > > > > Do you mean branching stable/2.22 or releasing 2.22.0 in May 2021?
> > > > > > In
> > > > > > my understanding, the past
> Le 25 août 2020 à 08:30, Jonas Hahnfeld a écrit :
>
> Am Montag, den 24.08.2020, 22:10 +0200 schrieb Jean Abou Samra:
>>>>>> As sort of a shot in the dark, how about planning the 2.22 release for
>>>>>> May 2021, for example?
>>>&g
Am Montag, den 24.08.2020, 22:10 +0200 schrieb Jean Abou Samra:
> > > > > As sort of a shot in the dark, how about planning the 2.22 release
> > > > > for May 2021, for example?
> > > >
> > > > Do you mean branching stable/2.22 or rel
hout some effort.
>>>>
>>>> What about scheduling the release?
>>>>
>>>> While I do know that "Grass doesn't grow faster when you pull on it.", I
>>>> would definitely like having a defined point in time where the stable
>&g
Jonas Hahnfeld writes:
> Am Montag, den 24.08.2020, 12:56 +0200 schrieb Jean Abou Samra:
>>
>> Right, I was oblique: the scripts are fragile at present, so
>> branching release/2.22 now is no good in my opinion, but hopefully
>> we can stabilize them faster than we stabilize LilyPond as a
ed state: you'd have
> > > > to cherry-pick loads of stuff from the unstable branch as it comes in.
> > >
> > > [Jonas] I fully agree
> > >
> > > ... and so do I (for what my opinion's worth, really) ...
> > >
> > > [Jonas] and I shoul
k. The point was to find out what it would take
>> because just waiting for some unspoken condition to become true is not
>> exactly going to happen without some effort.
>>
>> What about scheduling the release?
>>
>> While I do know that "Grass doesn't grow faste
te (even if
> not more precise than a month), but to me, having this talk now is preferable
> so as to give LilyPond development a tempo. To say it with other words, we've
> got a score to play; arguing about the tempo is better than starting the
> piece with different tempi.
>
&
On Aug 23, 2020, at 17:44, Jean Abou Samra wrote:
>
> At least four areas are currently under flux: Python scripts, the build
> system, Guile 2 support, and fonts (Owen's project), and I don't see that
> master is coming any close to stability. I think we are better with focusing
> on these
Hi,
(Sorry about the strange reply style.)
On Sun, Aug 23, 2020 at 1:58 PM Jonas Hahnfeld wrote:
> I'd like to ask what it would take in principle to branch stable/2.22
> and what others think about this.
>
> Personally I'm convinced that creating the branch and only picking bug
> fixes from
On Sun, Aug 23, 2020 at 1:58 PM Jonas Hahnfeld wrote:
> I'd like to ask what it would take in principle to branch stable/2.22
> and what others think about this.
>
> Personally I'm convinced that creating the branch and only picking bug
> fixes from master is the only guaranteed way to stabilize.
Am Sonntag, den 23.08.2020, 14:59 +0200 schrieb David Kastrup:
> Jonas Hahnfeld writes:
> > Hi all,
> >
> > I'd like to ask what it would take in principle to branch stable/2.22
> > and what others think about this.
>
> I don't see that this is a good point of time.
>
> There has been an
Jonas Hahnfeld writes:
> Hi all,
>
> I'd like to ask what it would take in principle to branch stable/2.22
> and what others think about this.
I don't see that this is a good point of time.
There has been an influx of badly tested changes to the build system and
directory setup and the web
Hi all,
I'd like to ask what it would take in principle to branch stable/2.22
and what others think about this.
Personally I'm convinced that creating the branch and only picking bug
fixes from master is the only guaranteed way to stabilize. Now you
might say that there were only few unstable
52 matches
Mail list logo
