Re: plan for branching

Am Freitag, den 16.10.2020, 08:17 +0200 schrieb Michael Käppler: > Am 16.10.2020 um 01:41 schrieb Dan Eble: > > On Oct 15, 2020, at 09:26, Jonas Hahnfeld wrote: > > > Am Dienstag, den 13.10.2020, 15:11 +0200 schrieb Jonas Hahnfeld: > > > > After creating the branch, I will (unless somebody

Re: plan for branching

Am 16.10.2020 um 01:41 schrieb Dan Eble: On Oct 15, 2020, at 09:26, Jonas Hahnfeld wrote: Am Dienstag, den 13.10.2020, 15:11 +0200 schrieb Jonas Hahnfeld: After creating the branch, I will (unless somebody doesn't want me to do this and volunteers to do the work; see also below): - bump

Re: plan for branching

On Oct 15, 2020, at 09:26, Jonas Hahnfeld wrote: > > Am Dienstag, den 13.10.2020, 15:11 +0200 schrieb Jonas Hahnfeld: >> After creating the branch, I will (unless somebody doesn't want me to >> do this and volunteers to do the work; see also below): >> - bump master to 2.23.0, in preparation

Re: plan for branching

Am 15.10.2020 um 15:26 schrieb Jonas Hahnfeld: Am Dienstag, den 13.10.2020, 15:11 +0200 schrieb Jonas Hahnfeld: After creating the branch, I will (unless somebody doesn't want me to do this and volunteers to do the work; see also below):  - bump master to 2.23.0, in preparation for the next

Re: plan for branching

Am Dienstag, den 13.10.2020, 15:11 +0200 schrieb Jonas Hahnfeld: > After creating the branch, I will (unless somebody doesn't want me to > do this and volunteers to do the work; see also below): >  - bump master to 2.23.0, in preparation for the next cycle; >  - bump stable/2.22 to 2.21.80, in

Re: plan for branching

Am Dienstag, den 13.10.2020, 15:11 +0200 schrieb Jonas Hahnfeld: > Thoughts? Something I forgot? I just removed translation-staging, which was equal to stable/2.20 signature.asc Description: This is a digitally signed message part

Re: plan for branching

On Tue, Oct 13, 2020 at 3:11 PM Jonas Hahnfeld wrote: > With the localization issues hopefully resolved and no objecting > comments to the last thread, I think we should go ahead and create > stable/2.22, with release candidates (2.21.8x) on the road to 2.22.0. > > After creating the branch, I

Re: plan for branching

Am Dienstag, den 13.10.2020, 15:38 +0200 schrieb Michael Käppler: > Am 13.10.2020 um 15:11 schrieb Jonas Hahnfeld: > > With the localization issues hopefully resolved and no objecting > > comments to the last thread, I think we should go ahead and create > > stable/2.22, with release candidates

Re: plan for branching

Am 13.10.2020 um 15:11 schrieb Jonas Hahnfeld: With the localization issues hopefully resolved and no objecting comments to the last thread, I think we should go ahead and create stable/2.22, with release candidates (2.21.8x) on the road to 2.22.0. After creating the branch, I will (unless

plan for branching

With the localization issues hopefully resolved and no objecting comments to the last thread, I think we should go ahead and create stable/2.22, with release candidates (2.21.8x) on the road to 2.22.0. After creating the branch, I will (unless somebody doesn't want me to do this and volunteers to

Re: on branching...

On Oct 5, 2020, at 07:49, Jonas Hahnfeld wrote: > > That said, I believe it would be reasonable to create a stable branch > and start picking fixes into that as needed. Before diving into the > details, I'd first like to know if there's still disagreement on this > starting point? If so, I'd

Re: on branching...

>> [...], I believe it would be reasonable to create a stable branch >> and start picking fixes into that as needed. Before diving into the >> details, I'd first like to know if there's still disagreement on >> this starting point? If so, I'd love to hear how to move forward > > I'm fine with

Re: on branching...

On 10/5/2020 7:33 AM, Michael Käppler wrote: Sure, it may be that there are still lots of problems there, waiting to be uncovered. But debating whether we need more testing at first does not help, when we do not have enough people to do it. What would a reasonably-adequate testing effort look

Re: on branching...

Am 05.10.2020 um 13:49 schrieb Jonas Hahnfeld: Hi all, Hi Jonas, tomorrow marks exactly one month since Han-Wen's proposal to have a freeze of 3 or 4 weeks for stabilizing [1]. While not everybody agreed with that plan, I think it has worked pretty well in practice and there has been no big

on branching...

Hi all, tomorrow marks exactly one month since Han-Wen's proposal to have a freeze of 3 or 4 weeks for stabilizing [1]. While not everybody agreed with that plan, I think it has worked pretty well in practice and there has been no big disturbance AFAICT. Instead many fixes landed, but in my

Re: branching stable/2.22?

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

Re: branching stable/2.22?

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

Re: branching stable/2.22?

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. >

Re: branching stable/2.22?

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. > > >

Re: branching stable/2.22?

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 fun

Re: branching stable/2.22?

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.

Re: branching stable/2.22?

>> > 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

Re: branching stable/2.22?

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

Re: branching stable/2.22?

> > 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

Re: branching stable/2.22?

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

Re: branching stable/2.22?

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

Re: branching stable/2.22?

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

Re: branching stable/2.22?

>> 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 > s

Re: branching stable/2.22?

ilarly, if I change a documentation string in an SCM file like `define-markup-commands.scm`, the documentation doesn't get rebuilt, either. I consider this fundamental flaws. > This is not my proposal anymore to just branch, but Han-Wen's idea of > having a freeze of 3-4 weeks before branc

Re: branching stable/2.22?

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

Re: branching stable/2.22?

gnificant exposure to > > extensive testing. > > +1 It's too early IMHO. Let's wait at laest a month. To be clear here: You mean at least one month before starting a freeze? This is not my proposal anymore to just branch, but Han-Wen's idea of having a freeze of 3-4 weeks before branchin

Re: branching stable/2.22?

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

Re: branching stable/2.22?

> 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.

Re: branching stable/2.22?

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 >> >

Re: branching stable/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

Re: branching stable/2.22?

and hopefully get some feedback? > > > > > > Well yes, that's the point of the whole thread, but I don't think we'll > > > get much feedback when continuing to break core functionality by usual > > > development. IMHO the bump to 2.21.90 (or some other high value)

Re: branching stable/2.22?

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:

Re: branching stable/2.22?

e thread, but I don't think we'll > > get much feedback when continuing to break core functionality by usual > > development. IMHO the bump to 2.21.90 (or some other high value) should > > happen after branching, ie when it's really a release candidate. > > We could of course h

Re: branching stable/2.22?

y by usual > development. IMHO the bump to 2.21.90 (or some other high value) should > happen after branching, ie when it's really a release candidate. > We could of course have some smaller bump to advertise as alpha while > still working on master, but I doubt that would help much without so

Re: branching stable/2.22?

feedback? Well yes, that's the point of the whole thread, but I don't think we'll get much feedback when continuing to break core functionality by usual development. IMHO the bump to 2.21.90 (or some other high value) should happen after branching, ie when it's really a release candidate. We c

Re: branching stable/2.22?

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

Re: branching stable/2.22?

sort of freeze > 3) Branch off stable/2.22 and cherry-pick only fixes I think that "some sort of freeze" makes sense only in light of defining goals to achieve for the next stable release. As long as those goals still necessitate disruptive/extensive changes, there is not much of a point in branching. -- David Kastrup

Re: branching stable/2.22?

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

Re: branching stable/2.22?

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

Re: branching stable/2.22?

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

Re: branching stable/2.22?

rom master as needed. > > I am happy to help with fixing bugs for the stable release. > > > From my experience in the LLVM project, there is no such thing as > > "naturally stabilizing code". Either you create a branch and pick fixes > > or you have a strict pol

Re: branching stable/2.22?

my experience in the LLVM project, there is no such thing as > "naturally stabilizing code". Either you create a branch and pick fixes > or you have a strict policy that allows only fixes to master before > branching. > That's basically the model GCC is using, and I don't think > it fits th

Re: branching stable/2.22?

> 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

Re: branching stable/2.22?

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

Re: branching stable/2.22?

> 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

Re: branching stable/2.22?

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

Re: branching stable/2.22?

> > > For me, creating the branch is nothing more than saying "feature > > > > development is over and the current set is worth making stable". Which > > > > I'm arguing is already there with Python 3 and the possibility to use > > > > Guile 2.

Fwd: branching stable/2.22?

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 : >> >>

Re: branching stable/2.22?

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

Re: branching stable/2.22?

> 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

Re: branching stable/2.22?

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

Re: branching stable/2.22?

ade in master will result in merge conflicts. >>> Plus I don't understand the proposal if you're at the same time saying >>> that the scripts are fragile. By that logic, why would we backport such >>> extensive changes and claim they're stable? >> >> Rig

Re: branching stable/2.22?

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 st

Re: branching stable/2.22?

sonally 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 releases (AFAICT there was > > > > 2.19.65 before branching stable/2.20)

Re: branching stable/2.22?

>>> might say that there were only few unstable releases (AFAICT there was >>> 2.19.65 before branching stable/2.20). However, I think there are >>> already quite some user-facing changes and also the switch to Python 3. >>> With Python 2.x being EOL since Ja

Re: branching 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 releases (AFAICT there was > > 2.19.65 before branc

Re: branching stable/2.22?

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

Re: branching stable/2.22?

> fixes from master is the only guaranteed way to stabilize. Now you > might say that there were only few unstable releases (AFAICT there was > 2.19.65 before branching stable/2.20). However, I think there are > already quite some user-facing changes and also the switch to Python 3. >

Re: branching stable/2.22?

ay to stabilize. Now you > might say that there were only few unstable releases (AFAICT there was > 2.19.65 before branching stable/2.20). However, I think there are > already quite some user-facing changes and also the switch to Python 3. > With Python 2.x being EOL since January,

Re: branching stable/2.22?

oint of time. > > There has been an influx of badly tested changes to the build system and > directory setup and the web pages that has to stabilise and result in a > workable version of LilyPond. I don't see the point in branching a > "stable" branch if there is so much in a dest

Re: branching stable/2.22?

and the web pages that has to stabilise and result in a workable version of LilyPond. I don't see the point in branching a "stable" branch if there is so much in a destabilised state: you'd have to cherry-pick loads of stuff from the unstable branch as it comes in. > Personally I'

branching stable/2.22?

releases (AFAICT there was 2.19.65 before branching stable/2.20). However, I think there are already quite some user-facing changes and also the switch to Python 3. With Python 2.x being EOL since January, it's only a matter of time until Linux distributions and BSDs want to drop that, and it would

Re: Any objections to branching off a stable branch for 2.20?

Le 19/07/2017 à 14:48, David Kastrup a écrit : Federico Bruni writes: Il giorno lun 17 lug 2017 alle 19:14, David Kastrup ha scritto: Other things up for cherry-picking are documentation changes and their translations. Since translations usually are done in "bulk", it would make sense to

Re: Any objections to branching off a stable branch for 2.20?

Dan Eble writes: >> On Jul 19, 2017, at 15:19, David Kastrup wrote: >> >> Paul > writes: >> >>> It's usually `a = b` or `\a b` but not `\a = b` or `\a b = c`. >> >> You can only use markup functions when

Re: Any objections to branching off a stable branch for 2.20?

On 20.07.2017 00:45, Dan Eble wrote: On Jul 19, 2017, at 15:19, David Kastrup wrote: Paul > writes: It's usually `a = b` or `\a b` but not `\a = b` or `\a b = c`. You can only use markup functions when refered to in markup

Re: Any objections to branching off a stable branch for 2.20?

> On Jul 19, 2017, at 15:19, David Kastrup wrote: > > Paul > writes: > >> It's usually `a = b` or `\a b` but not `\a = b` or `\a b = c`. > > You can only use markup functions when refered to in markup mode, so it > makes sense

Re: Any objections to branching off a stable branch for 2.20?

Paul writes: > On 07/17/2017 02:14 PM, David Kastrup wrote: > >> Currently there is a bit of a lull (not entirely graceful due to me not >> keeping up with things all the best), so the time seems convenient. > > No objections here. What's the latest thinking/status for

Re: Any objections to branching off a stable branch for 2.20?

On 07/17/2017 02:14 PM, David Kastrup wrote: Currently there is a bit of a lull (not entirely graceful due to me not keeping up with things all the best), so the time seems convenient. No objections here. What's the latest thinking/status for issue 3884? Anything I can / should do?

Re: Any objections to branching off a stable branch for 2.20?

Federico Bruni writes: > Il giorno lun 17 lug 2017 alle 19:14, David Kastrup ha > scritto: >> Other things up for cherry-picking are documentation changes and >> their translations. Since translations usually are done in "bulk", >> it would make sense to only

Re: Any objections to branching off a stable branch for 2.20?

Il giorno lun 17 lug 2017 alle 19:14, David Kastrup ha scritto: Other things up for cherry-picking are documentation changes and their translations. Since translations usually are done in "bulk", it would make sense to only translate stuff in the stable 2.20 branch in the

Re: Any objections to branching off a stable branch for 2.20?

Phil Holmes wrote Tuesday, July 18, 2017 11:07 AM > Subject: Any objections to branching off a stable branch for 2.20? > No objections from me towards aiming for a 2.20 stable release. None from me either. Trevor --- This email has been checked for viruses by AVG. http://www.a

Re: Any objections to branching off a stable branch for 2.20?

- Original Message - From: "David Kastrup" <d...@gnu.org> To: <lilypond-devel@gnu.org> Sent: Monday, July 17, 2017 7:14 PM Subject: Any objections to branching off a stable branch for 2.20? Currently there is a bit of a lull (not entirely graceful due to me not

Any objections to branching off a stable branch for 2.20?

Currently there is a bit of a lull (not entirely graceful due to me not keeping up with things all the best), so the time seems convenient. There are a few "critical" bugs outstanding, the "Changes" document should be reordered to be systematic rather than in reverse time order, and I'd want to

Re: Gitflow branching model

, 27 kwietnia 2015 Carl Sorensen c_soren...@byu.edu napisał(a): In another project that I am working on they use the gitflow branching model. It seems to be quite robust in terms of a: Freezing features for release while at the same time providing a means of working on new features. b

Gitflow branching model

In another project that I am working on they use the gitflow branching model. It seems to be quite robust in terms of a: Freezing features for release while at the same time providing a means of working on new features. b: Providing formal methods for getting critical bug fixes into both

Re: branching

beyond the individual. List-etiquette policies, branching policies - I’m open to trying anything. [...] What I’d like to see is a situation where David can blow off steam however he needs to, he doesn’t feel like people are ignoring him, You are aware that the above are mutually exclusive

Re: branching

the “many level and I think we need to find a solution that goes beyond the individual. List-etiquette policies, branching policies - I’m open to trying anything. [...] What I’d like to see is a situation where David can blow off steam however he needs to, he doesn’t feel like people

Re: branching

On Dec 11, 2013, at 11:36 AM, David Kastrup d...@gnu.org wrote: Mike Solomon m...@mikesolomon.org writes: We are currently taking a look at how to create regions of LilyPond that can be worked on independently and without affecting the overall quality of LilyPond. If we manage to do this

Re: branching

Mike Solomon wrote Wednesday, December 11, 2013 10:22 AM On Dec 11, 2013, at 11:36 AM, David Kastrup d...@gnu.org wrote: As opposed to me, Graham excelled at organizing and maintaining community efforts like this which makes his leaving an even larger loss. His leaving is a huge loss, and

Re: branching

On Dec 11, 2013, at 2:18 PM, Trevor Daniels t.dani...@treda.co.uk wrote: Mike Solomon wrote Wednesday, December 11, 2013 10:22 AM On Dec 11, 2013, at 11:36 AM, David Kastrup d...@gnu.org wrote: As opposed to me, Graham excelled at organizing and maintaining community efforts like this

Re: branching

Mike Solomon m...@mikesolomon.org writes: On Dec 11, 2013, at 11:36 AM, David Kastrup d...@gnu.org wrote: [...] But that’s no good - we have to find a solution. Modularity, while perhaps a good long term solution, is a long ways away. How are we going to deal with this in 2014? By making

Re: branching

On Dec 11, 2013, at 3:56 PM, David Kastrup d...@gnu.org wrote: Mike Solomon m...@mikesolomon.org writes: On Dec 11, 2013, at 11:36 AM, David Kastrup d...@gnu.org wrote: [...] But that’s no good - we have to find a solution. Modularity, while perhaps a good long term solution, is a

branching

Hey all, As 2.18 draws near, I’d like to work with everyone to establish a system of branching for LilyPond development. After several rounds of discussing things with David K, this emerged as the best way to avoid arguments about integrating work into the development branch that have led

Re: branching

On Tue, Dec 10, 2013 at 02:42:45PM +0200, Mike Solomon wrote: On the website, we would offer _all_ of these development branches, including the one built off of staging, as GUB builds. A few years ago, we were asked to cut our downloads down to 5 GB. I deleted a bunch of devel stuff and got it

Re: branching

On Dec 10, 2013, at 2:58 PM, Graham Percival gra...@percival-music.ca wrote: On Tue, Dec 10, 2013 at 02:42:45PM +0200, Mike Solomon wrote: On the website, we would offer _all_ of these development branches, including the one built off of staging, as GUB builds. A few years ago, we were

Re: branching

Mike Solomon m...@mikesolomon.org writes: Hey all, As 2.18 draws near, I’d like to work with everyone to establish a system of branching for LilyPond development. After several rounds of discussing things with David K, this emerged as the best way to avoid arguments about integrating work

Re: branching

On Dec 10, 2013, at 4:23 PM, David Kastrup d...@gnu.org wrote: Mike Solomon m...@mikesolomon.org writes: Hey all, As 2.18 draws near, I’d like to work with everyone to establish a system of branching for LilyPond development. After several rounds of discussing things with David K

Re: branching

On Tue, Dec 10, 2013 at 04:30:32PM +0200, Mike Solomon wrote: (quotes from David) The basic idea behind that is not to make confrontations nicer but reduce the necessity for them by establishing playing fields with different authorities. So that people can get work done without

Re: branching

Graham Percival gra...@percival-music.ca writes: On Tue, Dec 10, 2013 at 04:30:32PM +0200, Mike Solomon wrote: (quotes from David) The basic idea behind that is not to make confrontations nicer but reduce the necessity for them by establishing playing fields with different authorities.

Re: branching

On 12/10/13 5:42 AM, Mike Solomon m...@mikesolomon.org wrote: Hey all, As 2.18 draws near, I¹d like to work with everyone to establish a system of branching for LilyPond development. After several rounds of discussing things with David K, this emerged as the best way to avoid arguments about

Re: branching

On Dec 10, 2013, at 9:32 PM, Carl Sorensen c_soren...@byu.edu wrote: On 12/10/13 5:42 AM, Mike Solomon m...@mikesolomon.org wrote: Hey all, As 2.18 draws near, I¹d like to work with everyone to establish a system of branching for LilyPond development. After several rounds

Re: branching

On Tue, Dec 10, 2013 at 3:21 PM, Mike Solomon m...@mikesolomon.org wrote: The only hassle for me, which I did not run up against when I started with the project, is David’s way of communicating. I’m not claiming this is all on him, but I’m also pretty sure that I’m not the only one who has

Re: branching

Hi, On Tue, Dec 10, 2013 at 2:46 PM, Carl Peterson carlopeter...@gmail.comwrote: On Tue, Dec 10, 2013 at 3:21 PM, Mike Solomon m...@mikesolomon.orgwrote: The only hassle for me, which I did not run up against when I started with the project, is David’s way of communicating. I’m not

Re: branching

. The problem here has reached the “many level and I think we need to find a solution that goes beyond the individual. List-etiquette policies, branching policies - I’m open to trying anything. One thing that is important to restate is that I realize that, unlike my bad-but-getting-better

centralization of lilypond development and forking (was: branching)

On Wed, Dec 11, 2013 at 08:39:58AM +0200, Mike Solomon wrote: See: http://lilypond.1069038.n5.nabble.com/Allows-minimum-length-to-work-for-end-of-line-spanners-issue-7453046-td141952.html#a142870 as one of several examples. There is truth in anything David says, meaning that I

  1   2   >