David Kastrup wrote Thursday, November 03, 2011 9:01 AM
Graham Percival writes:
and there's no point having everbody work on dev/staging instead
of
master; we'll still get random breakage and so we'll be no better
off
than having everybody working on master.
Huh? The point is that not
Graham Percival writes:
> On Wed, Nov 02, 2011 at 09:13:02PM +0100, David Kastrup wrote:
>> Graham Percival writes:
>>
>> > At this very moment,
>> > - we cannot build releases
>>
>> Well, they _are_ development releases anyway. While my computing
>> facilities are quite limited (single Penti
Graham Percival writes:
> On Thu, Nov 03, 2011 at 08:40:46AM +0100, David Kastrup wrote:
>> And as long as nobody commits directly to master, dev/staging does not
> ~
>
> what if Han-Wen or John pops in to make a quick bugfix (say, to
> the transla
On Wed, Nov 02, 2011 at 09:13:02PM +0100, David Kastrup wrote:
> Graham Percival writes:
>
> > At this very moment,
> > - we cannot build releases
>
> Well, they _are_ development releases anyway. While my computing
> facilities are quite limited (single Pentium M of moderate speed), and
> my t
On Thu, Nov 03, 2011 at 08:40:46AM +0100, David Kastrup wrote:
> And as long as nobody commits directly to master, dev/staging does not
~
what if Han-Wen or John pops in to make a quick bugfix (say, to
the translation handling stuff), hasn't spent 1
Graham Percival writes:
> On Wed, Nov 02, 2011 at 09:13:02PM +0100, David Kastrup wrote:
>> Graham Percival writes:
>>
>> > At this very moment,
>> > - we cannot build releases
>>
>> Well, they _are_ development releases anyway. While my computing
>> facilities are quite limited (single Penti
On Wed, Nov 02, 2011 at 09:13:02PM +0100, David Kastrup wrote:
> Graham Percival writes:
>
> > At this very moment,
> > - we cannot build releases
>
> Well, they _are_ development releases anyway. While my computing
> facilities are quite limited (single Pentium M of moderate speed), and
> my t
On 11/2/11 10:20 AM, "Adam Spiers" wrote:
>
>>>
>>> >When building in a build/ subdirectory as recommended by the Guide,
>>> >this path is wrong; it should be:
>>> >
>>> >cp $LILYPOND/build/Documentation/out/version.itexi
>>> >$HOME/lilypond/tempdocs
>>>
>>> Actually, the script should be c
Graham Percival writes:
> At this very moment,
> - we cannot build releases
Well, they _are_ development releases anyway. While my computing
facilities are quite limited (single Pentium M of moderate speed), and
my testing probably not up to scratch, I'd be willing to churn out
minimal release
On Wed, Nov 02, 2011 at 04:20:02PM +, Adam Spiers wrote:
> On Wed, Nov 2, 2011 at 5:25 AM, Graham Percival
> wrote:
> > I'm not certain about the
> > big-page, but
> > make out=www out-www/notation/index.html
> > should be no problem.
>
> IIRC I tried that, and it seemed to behave as a NOOP
On Wed, Nov 2, 2011 at 5:25 AM, Graham Percival
wrote:
> On Wed, Nov 02, 2011 at 02:14:13AM +, Carl Sorensen wrote:
>> On 11/1/11 5:44 PM, "Adam Spiers" wrote:
>> >`make doc' works, but takes too long to be of practical use except as
>> >a final sanity check before submitting a patch upstream
On Wed, Nov 02, 2011 at 02:14:13AM +, Carl Sorensen wrote:
>
> On 11/1/11 5:44 PM, "Adam Spiers" wrote:
>
> >`make doc' works, but takes too long to be of practical use except as
> >a final sanity check before submitting a patch upstream.
You can use multiple threads.
> >http://lilypond.or
On 11/1/11 5:44 PM, "Adam Spiers" wrote:
>I'm trying to make sure my patches include the right tweaks to the
>documentation, but as a newbie to lilypond development (but with a lot
>of development experience elsewhere), I'm sorry to say I'm really
>struggling :-(
>
>`make doc' works, but takes
I'm trying to make sure my patches include the right tweaks to the
documentation, but as a newbie to lilypond development (but with a lot
of development experience elsewhere), I'm sorry to say I'm really
struggling :-(
`make doc' works, but takes too long to be of practical use except as
a final s
14 matches
Mail list logo
