> make a build
>
> --
> Phil Holmes
>
>
> - Original Message -
> From: "Jonas Hahnfeld" <
> hah...@hahnjo.de
> >
> To: "Han-Wen Nienhuys" <
> hanw...@gmail.com
> >
> Cc: "David Kastrup" <
> d...@gnu.org
> &g
t;
Cc: "David 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 pe
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 r
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 cros
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 pro
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
w
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 point
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 don't
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 ca
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 to
Hi David,
Am Sonntag, den 01.03.2020, 14:28 +0100 schrieb David Kastrup:
> Recently I asked the list to consider not putting any changes in master
> right now where we'd like to be able to figure out whether they are
> "introduced after 2.21.0" or not. At least with regard to build system
> chang
Recently I asked the list to consider not putting any changes in master
right now where we'd like to be able to figure out whether they are
"introduced after 2.21.0" or not. At least with regard to build system
changes but likely also some other ones, it's probably safe to say that
this ship has
Il giorno gio 20 feb 2020 alle 14:06, David Kastrup ha
scritto:
In unrelated news, I tried my hand at translating at least the Changes
file into German and am about 50% done. Anybody want to work from the
bottom so that we should coordinate in order to avoid duplicate
effort?
I got kind of a h
Federico Bruni writes:
> Il giorno lun 17 feb 2020 alle 22:49, Federico Bruni
> ha scritto:
>> I'm working on the italian update and I hope to be ready before
>> Thursday night.
>>
>
> Can we have one day delay? So deadline to push to translation branch
> by Friday night?
> I guess I won't ha
Il giorno lun 17 feb 2020 alle 22:49, Federico Bruni
ha scritto:
Il giorno lun 17 feb 2020 alle 22:35, David Kastrup ha
scritto:
Jean-Charles Malahieude writes:
Le 17/02/2020 à 13:25, David Kastrup a écrit :
Ok, I think 2.20 is basically done and we should push it out by
the
end
Urs Liska writes:
> Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup:
>> Ok, I think 2.20 is basically done and we should push it out by the
>> end
>> of this week.
>
> This is really great news!
> I'm somewhat undecided whether it is a cause for celebration or not to
> finally rele
Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup:
> Ok, I think 2.20 is basically done and we should push it out by the
> end
> of this week.
This is really great news!
I'm somewhat undecided whether it is a cause for celebration or not to
finally release a "stable" version after six
Il giorno lun 17 feb 2020 alle 22:35, David Kastrup ha
scritto:
Jean-Charles Malahieude writes:
Le 17/02/2020 à 13:25, David Kastrup a écrit :
Ok, I think 2.20 is basically done and we should push it out by the
end
of this week. This leaves a few days for the translation team to
ca
Jean-Charles Malahieude writes:
> Le 17/02/2020 à 13:25, David Kastrup a écrit :
>> Ok, I think 2.20 is basically done and we should push it out by the
>> end
>> of this week. This leaves a few days for the translation team to catch
>> up with the current state.
>> In particular HINT HINT HINT i
Le 17/02/2020 à 13:25, David Kastrup a écrit :
Ok, I think 2.20 is basically done and we should push it out by the end
of this week. This leaves a few days for the translation team to catch
up with the current state.
In particular HINT HINT HINT it gives the opportunity to native speakers
of l
Jonas Hahnfeld writes:
> Am Montag, den 17.02.2020, 14:59 +0100 schrieb David Kastrup:
>
>> Yes, GUB for 2.21.0. We don't want to have another indeterminate
>> backlog on unstable releases. That means that GUB needs to get switched
>> over to Python 3.
>
> For those following along: It's not th
Am Montag, den 17.02.2020, 14:59 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> hah...@hahnjo.de
> > writes:
>
> > Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup:
> > > Ok, I think 2.20 is basically done and we should push it out by the end
> > > of this week. This leaves a few d
Jonas Hahnfeld writes:
> Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup:
>> Ok, I think 2.20 is basically done and we should push it out by the end
>> of this week. This leaves a few days for the translation team to catch
>> up with the current state.
>
> Wohoo!
>
>> [...]
>>
>> W
Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup:
> Ok, I think 2.20 is basically done and we should push it out by the end
> of this week. This leaves a few days for the translation team to catch
> up with the current state.
Wohoo!
> [...]
>
> What does this mean for 2.21.0? I thi
Ok, I think 2.20 is basically done and we should push it out by the end
of this week. This leaves a few days for the translation team to catch
up with the current state.
In particular HINT HINT HINT it gives the opportunity to native speakers
of languages not as meticulously maintained as the c
James writes:
> In the CG we have nothing for patch-waiting, but just the others,
> which leads me on to:
>
> "Patch-abandoned: the author has not responded to review comments for
> a few months."
>
> Assuming that no one changes a patch-waiting for X weeks, how many
> would it take - just throwi
On 29/10/13 14:14, James wrote:
On 29/10/13 09:19, Julien Rioux wrote:
On 29/10/2013 4:43 AM, David Kastrup wrote:
Julien Rioux writes:
On 27/10/2013 2:09 PM, Janek Warchoł wrote:
That's good, but the most irritating thing about this patch is not
that i have to solve merge conflicts. I'm m
On 29/10/13 09:19, Julien Rioux wrote:
On 29/10/2013 4:43 AM, David Kastrup wrote:
Julien Rioux writes:
On 27/10/2013 2:09 PM, Janek Warchoł wrote:
That's good, but the most irritating thing about this patch is not
that i have to solve merge conflicts. I'm mainly irritated because a
piece o
Ok, i said that i closed this topic, but a question was asked so just
a short answer:
2013/10/29 Julien Rioux :
> On 29/10/2013 4:43 AM, David Kastrup wrote:
>>
>> Julien Rioux writes:
>>
>>> On 27/10/2013 2:09 PM, Janek Warchoł wrote:
That's good, but the most irritating thing about th
On 29/10/2013 4:43 AM, David Kastrup wrote:
Julien Rioux writes:
On 27/10/2013 2:09 PM, Janek Warchoł wrote:
That's good, but the most irritating thing about this patch is not
that i have to solve merge conflicts. I'm mainly irritated because a
piece of solid code (maybe it's not as solid as
Julien Rioux writes:
> On 27/10/2013 2:09 PM, Janek Warchoł wrote:
>> That's good, but the most irritating thing about this patch is not
>> that i have to solve merge conflicts. I'm mainly irritated because a
>> piece of solid code (maybe it's not as solid as i think, but to know
>> that i need
On 27/10/2013 2:09 PM, Janek Warchoł wrote:
That's good, but the most irritating thing about this patch is not
that i have to solve merge conflicts. I'm mainly irritated because a
piece of solid code (maybe it's not as solid as i think, but to know
that i need _reviews_) is laying dormant for *h
gt; solid code is laying dormant for half a year. I am irritated because so
> few people can be bothered with getting release-critical stuff under
> control that the stable release of LilyPond 2.18 has been dragging on
> for half a year. This thread is titled "2.18 release plans"
table release of LilyPond 2.18 has been dragging on
for half a year. This thread is titled "2.18 release plans" and you use
it for trying to divert resources to your own priorities and complaining
when people don't respond in a timely or favorable manner.
For you it might feel like
2013/10/27 Janek Warchoł :
> That's good, but the most irritating thing about this patch is not
> that i have to solve merge conflicts. I'm mainly irritated because a
> piece of solid code (maybe it's not as solid as i think, but to know
> that i need _reviews_) is laying dormant for *half a year*
2013/10/27 David Kastrup :
> Janek Warchoł writes:
>> So, would it be possible to get issue 3239 reviewed? It's waiting for
>> half a year, and solving merge conflicts when i rebase it gets
>> irritating.
>
> I don't tell people what they are supposed to review.
Oh, really? ;-P
You can tell whet
Janek Warchoł writes:
> 2013/10/27 David Kastrup :
>> Janek Warchoł writes:
>>
>>> 2013/10/26 David Kastrup :
I've now pushed stable/2.18 and synchronized translations to it.
I hereby declare the stable/2.18 branch my sole property, to be ruled
over dictatorially. As long as nobo
2013/10/27 David Kastrup :
> Janek Warchoł writes:
>
>> 2013/10/26 David Kastrup :
>>> I've now pushed stable/2.18 and synchronized translations to it.
>>> I hereby declare the stable/2.18 branch my sole property, to be ruled
>>> over dictatorially. As long as nobody else pushes to it without my
Janek Warchoł writes:
> 2013/10/26 David Kastrup :
>> I've now pushed stable/2.18 and synchronized translations to it.
>> I hereby declare the stable/2.18 branch my sole property, to be ruled
>> over dictatorially. As long as nobody else pushes to it without my
>> permission, I pledge to keep an
2013/10/26 David Kastrup :
> I've now pushed stable/2.18 and synchronized translations to it.
> I hereby declare the stable/2.18 branch my sole property, to be ruled
> over dictatorially. As long as nobody else pushes to it without my
> permission, I pledge to keep and lead it to releasable state
On 13-10-26 01:51 PM, Thomas Morley wrote:
2013/10/26 Trevor Daniels :
Werner LEMBERG wrote Saturday, October 26, 2013 8:07 PM
I've now pushed stable/2.18 and synchronized translations to it.
Thanks for your hard work!
Indeed! Much appreciated, David!
Trevor
Thanks a lot!!!
Harm
AO
2013/10/26 Trevor Daniels :
>
> Werner LEMBERG wrote Saturday, October 26, 2013 8:07 PM
>>
>>> I've now pushed stable/2.18 and synchronized translations to it.
>>
>> Thanks for your hard work!
>
> Indeed! Much appreciated, David!
>
> Trevor
Thanks a lot!!!
Harm
___
Werner LEMBERG wrote Saturday, October 26, 2013 8:07 PM
>
>> I've now pushed stable/2.18 and synchronized translations to it.
>
> Thanks for your hard work!
Indeed! Much appreciated, David!
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.o
> I've now pushed stable/2.18 and synchronized translations to it.
Thanks for your hard work!
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Francisco Vila writes:
> 2013/10/26 David Kastrup :
>> David Kastrup writes:
> b) translation branch
>
> The translation branch will stop getting merged with master. Some
> documentation changes from master might get cherry-picked into
> translation (I will do that myself),
2013/10/26 David Kastrup :
> David Kastrup writes:
b) translation branch
The translation branch will stop getting merged with master. Some
documentation changes from master might get cherry-picked into
translation (I will do that myself), and translation will get merged
>
David Kastrup writes:
> Jean-Charles Malahieude writes:
>
>> Le 22/10/2013 20:06, David Kastrup disait :
>>
>>> b) translation branch
>>>
>>> The translation branch will stop getting merged with master. Some
>>> documentation changes from master might get cherry-picked into
>>> translation (I w
Le 26/10/2013 19:17, David Kastrup disait :
Jean-Charles Malahieude writes:
Since nothing has changed on "translation" since Monday (too many
other things to deal with), I just merged _locally_ "master" into
it. Would you mind me pushing this before setting the freeze?
Yes, that's fine. It
Jean-Charles Malahieude writes:
> Le 22/10/2013 20:06, David Kastrup disait :
>
>> b) translation branch
>>
>> The translation branch will stop getting merged with master. Some
>> documentation changes from master might get cherry-picked into
>> translation (I will do that myself), and translati
Le 22/10/2013 20:06, David Kastrup disait :
Ok, after looking at the current situation and the current patches in
review/countdown, I've decided that I'll fork off the stable release
branch 2.18 after the current batch in countdown is in master. After
that point of time, I'll only cherry-pick p
Ok, after looking at the current situation and the current patches in
review/countdown, I've decided that I'll fork off the stable release
branch 2.18 after the current batch in countdown is in master. After
that point of time, I'll only cherry-pick patches into the stable branch
after having con
On Sun, Sep 26, 2010 at 11:42:55AM +0200, Marc Hohl wrote:
> I opened both files in an editor and compared. In the english
> source, I found two consecutive
> @divEnd-entries at line 141 and 143. If this is intended, the
> following patch does the same
> for the german translation.
Each @divClass{
Graham Percival schrieb:
On Fri, Sep 24, 2010 at 10:59:18AM +0200, Marc Hohl wrote:
Graham Percival schrieb:
2) website has been switched over. At first glance, I think I can
close issue 1244 now, but I want to double-check and wait for
feedback.
The menu bar is misplaced here,
On Thu, Sep 23, 2010 at 6:57 AM, Marc Hohl wrote:
>
> Since tablature support has changed, I think this should be
> reported, too.
Thanks, pushed.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/lis
On Fri, Sep 24, 2010 at 10:59:18AM +0200, Marc Hohl wrote:
> Graham Percival schrieb:
> >2) website has been switched over. At first glance, I think I can
> >close issue 1244 now, but I want to double-check and wait for
> >feedback.
> The menu bar is misplaced here, I don't know why - see the atta
Graham Percival schrieb:
Here's an update on the release plans. These are not cast in
stone; if you have a thoughtful objection or suggestion, I'm
willing to change things.
1) 2.13.34, "alpha test" has been released.
2) website has been switched over. At first glance,
"Graham Percival" wrote in message
news:20100922161121.gc14...@futoi...
Here's an update on the release plans. These are not cast in
stone; if you have a thoughtful objection or suggestion, I'm
willing to change things.
1) 2.13.34, "alpha test" has been released
Graham Percival schrieb:
Here's an update on the release plans. These are not cast in
stone; if you have a thoughtful objection or suggestion, I'm
willing to change things.
Since tablature support has changed, I think this should be
reported, too.
Ma
wrote:
> Here's an update on the release plans. These are not cast in
> stone; if you have a thoughtful objection or suggestion, I'm
> willing to change things.
>
> 1) 2.13.34, "alpha test" has been released.
> 2) website has been switched over. At first glance,
On Wed, Sep 22, 2010 at 6:11 PM, Graham Percival
wrote:
> 2) website has been switched over. At first glance, I think I can
> close issue 1244 now, but I want to double-check and wait for
> feedback.
I think we should make at least the following URLs point to the
equivalent new pages:
http://lil
On Wed, Sep 22, 2010 at 5:43 PM, Phil Holmes wrote:
>
> Just read the "2.13 diffs from 2.12" doc and there's no mention of page
> spacing changes. I think this is quite a major change and needs adding to
> that doc?
Thanks, I added an entry about this:
+...@item
+The vertical spacing engine has
"Graham Percival" wrote in message
news:20100922161121.gc14...@futoi...
Here's an update on the release plans. These are not cast in
stone; if you have a thoughtful objection or suggestion, I'm
willing to change things.
Just read the "2.13 diffs from 2.12" doc
"Graham Percival" wrote in message
news:20100922163820.ga14...@futoi...
On Wed, Sep 22, 2010 at 05:29:42PM +0100, Phil Holmes wrote:
"Graham Percival" wrote in message
news:20100922161121.gc14...@futoi...
>NB: I expect approximately 5 more regressions to be reported in
>the next week. Some of
On Wed, Sep 22, 2010 at 05:29:42PM +0100, Phil Holmes wrote:
> "Graham Percival" wrote in message
> news:20100922161121.gc14...@futoi...
> >NB: I expect approximately 5 more regressions to be reported in
> >the next week. Some of them might not be regressions in code that
> >worked deliberately.
"Graham Percival" wrote in message
news:20100922161121.gc14...@futoi...
Here's an update on the release plans. These are not cast in
stone; if you have a thoughtful objection or suggestion, I'm
willing to change things.
1) 2.13.34, "alpha test" has been released
Here's an update on the release plans. These are not cast in
stone; if you have a thoughtful objection or suggestion, I'm
willing to change things.
1) 2.13.34, "alpha test" has been released.
2) website has been switched over. At first glance, I think I can
close issue 124
Le mercredi 23 septembre 2009 à 21:02 +0100, Neil Puttock a écrit :
> It looks like there's no forced regeneration of the musicxml snippets:
> on my system, unless I do `make test-clean' first, they all have the
> wrong \version (i.e., 2.13.4), which causes `make test-baseline' to
> fail on the fi
2009/9/22 John Mandereau :
> I had a failure of test-baseline; I did
>
> git checkout stable/2.12
> ./autogen.sh
> make clean
> make -j3 &>make.log
> make test-baseline
>
> I couldn't investigate it, because test-baseline isn't built with
> --verbose. I'm building 2.12 docs, if the failure is rep
Le samedi 19 septembre 2009 à 22:26 +0100, Neil Puttock a écrit :
> I don't know whether it's significant, but I've found it's easy to
> tell when the testing's gone wrong, since the job forking message has
> too few jobs (on a good day, it usually averages around 20,000 per job
> for -j3 on my sy
2009/9/19 John Mandereau :
> Ugh, this is weird. I'll try comparing 2.12 and master, and 2.13.3 and
> master.
Cheers.
I don't know whether it's significant, but I've found it's easy to
tell when the testing's gone wrong, since the job forking message has
too few jobs (on a good day, it usually
Le samedi 19 septembre 2009 à 21:50 +0100, Neil Puttock a écrit :
> If it's not too much trouble for you to do this, John, I'd be
> interested to know whether you can get it too work; I've been trying
> without success over the last few weeks to do comparisons between
> various 2.12 & 2.13 release
2009/9/19 John Mandereau :
> Is it worth I generate a regtest comparison manually (without gub, doing
> git checkout release/2.12.3-0;make test-baseline;
> git checkout release/2.12.4-1;make check) and upload it somewhere.
If it's not too much trouble for you to do this, John, I'd be
interested t
I'll volunteer for helping regtest.
You just look at two output images and compare them, right? Any
difference, the test fails?
-Travis
On Sat, Sep 19, 2009 at 1:44 PM, Graham Percival
wrote:
> On Sat, Sep 19, 2009 at 06:34:41PM +0200, John Mandereau wrote:
>> Le vendredi 18 septembre 2009 à 06
On Sat, Sep 19, 2009 at 06:34:41PM +0200, John Mandereau wrote:
> Le vendredi 18 septembre 2009 à 06:56 +0100, Graham Percival a écrit :
> > Some time later today (knock on wood) I'll make the official
> > 2.13.4 release. This will happen whenever I manage to solve or
> > bludgeon all the issues
Le vendredi 18 septembre 2009 à 06:56 +0100, Graham Percival a écrit :
> Some time later today (knock on wood) I'll make the official
> 2.13.4 release. This will happen whenever I manage to solve or
> bludgeon all the issues involved in building GUB on my university
> machine. As such,
> - I'm n
On Fri, Sep 18, 2009 at 7:56 AM, Graham Percival
wrote:
> - I'm not going to check the regtests
> - I'm not going to announce it on info-lilypond or the website.
> - I'm not going to care about things like test output that's twice
> the size that it should be, or that I need to do
> rm -rf tar
Graham Percival wrote:
Some time later today (knock on wood) I'll make the official
2.13.4 release.
Great!
...
Some time next week (knock on wood again), I'll make a 2.13.5
release. The major new thing there will be creating the regtest
comparison between .4 and .5, and this time I *will*
Some time later today (knock on wood) I'll make the official
2.13.4 release. This will happen whenever I manage to solve or
bludgeon all the issues involved in building GUB on my university
machine. As such,
- I'm not going to check the regtests
- I'm not going to announce it on info-lilypond or
On Wed, Jun 24, 2009 at 12:02:12AM +0200, Reinhold Kainhofer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am Dienstag, 23. Juni 2009 06:25:20 schrieb Graham Percival:
> > Progress has been slow for the past month. I'd like to be able to
> > claim that I'll be getting more done in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Dienstag, 23. Juni 2009 06:25:20 schrieb Graham Percival:
> Progress has been slow for the past month. I'd like to be able to
> claim that I'll be getting more done in the next few weeks, but in
> all honesty I doubt it. If anything, I'll be engag
On Tue, Jun 23, 2009 at 06:04:54PM +0300, Joe Neeman wrote:
> On Mon, 2009-06-22 at 21:25 -0700, Graham Percival wrote:
> > With that in mind, I think we're looking at 2.14 being at the end
> > of July at the earliest. Therefore, I'd like to invite Joe to
> > merge the new vertical spacing code in
Graham Percival percival-music.ca> writes:
>
> Progress has been slow for the past month. I'd like to be able to
> claim that I'll be getting more done in the next few weeks, but in
> all honesty I doubt it. If anything, I'll be engaged in *more*
> household projects, not less.
>
> With that
On Mon, 2009-06-22 at 21:25 -0700, Graham Percival wrote:
> Progress has been slow for the past month. I'd like to be able to
> claim that I'll be getting more done in the next few weeks, but in
> all honesty I doubt it. If anything, I'll be engaged in *more*
> household projects, not less.
>
>
Progress has been slow for the past month. I'd like to be able to
claim that I'll be getting more done in the next few weeks, but in
all honesty I doubt it. If anything, I'll be engaged in *more*
household projects, not less.
With that in mind, I think we're looking at 2.14 being at the end
of J
Le lundi 22 décembre 2008 à 11:23 -0800, Graham Percival a écrit :
> This is totally a meritocracy question. Non-developers want the
> sun and moon, right now, for the price of a download.
So, let's ask for a fee for each download -<:o)
> In the past we've tried to do the backporting idea. It'
On Mon, Dec 22, 2008 at 06:54:43PM -, Trevor Daniels wrote:
>
> Han-Wen Nienhuys wrote Monday, December 22, 2008 6:22 PM
>
>> It would be really nice if we could invert the rhythms of
>> stable/devel: have a long stable cycle with many releases (like 2.11
>> had), and thenhave a flurry of 2
Han-Wen Nienhuys wrote Monday, December 22, 2008 6:22 PM
On Mon, Dec 22, 2008 at 10:58 AM, Graham Percival
wrote:
Does this mean you do not want to make any difference between odd and
even versions?
No. .13 would be the "devel" version, where syntax changes are
introduced, and any major
On Mon, Dec 22, 2008 at 10:58 AM, Graham Percival
wrote:
>> Does this mean you do not want to make any difference between odd and
>> even versions?
>
> No. .13 would be the "devel" version, where syntax changes are
> introduced, and any major breakage occurs. It would last as long
> as necessar
Graham Percival wrote Monday, December 22, 2008 5:40 AM
Once 2.12 is out and we've succeeded in setting up GUB3 on
kainhofer, I'll become the Release Manager. I have two ideas on
how to change things:
1) Move to a linux kernel type of releases: instead of having
separate devel and stable br
On Mon, Dec 22, 2008 at 12:56:35PM +0100, Valentin Villenave wrote:
> 2008/12/22 Graham Percival :
> > Once 2.12 is out and we've succeeded in setting up GUB3 on
> > kainhofer, I'll become the Release Manager. I have two ideas on
> > how to change things:
>
> Good to see you're still involved, Mr
2008/12/22 Graham Percival :
> Once 2.12 is out and we've succeeded in setting up GUB3 on
> kainhofer, I'll become the Release Manager. I have two ideas on
> how to change things:
Good to see you're still involved, Mr
"I'm-leavin'-soon-anyway-so-just-pretend-I'm-not-here" :-)
> 2) Keep the dist
On Mon, Dec 22, 2008 at 3:40 AM, Graham Percival
wrote:
> Once 2.12 is out and we've succeeded in setting up GUB3 on
> kainhofer, I'll become the Release Manager. I have two ideas on
> how to change things:
>
> 1) Move to a linux kernel type of releases: instead of having
> separate devel and st
Once 2.12 is out and we've succeeded in setting up GUB3 on
kainhofer, I'll become the Release Manager. I have two ideas on
how to change things:
1) Move to a linux kernel type of releases: instead of having
separate devel and stable branches, we just do everything in 2.12.
In some ways, we've be
97 matches
Mail list logo
