lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GOP-PROP 12: keep master in ready-to-release state (probable decisio


From: David Kastrup
Subject: Re: GOP-PROP 12: keep master in ready-to-release state (probable decision)
Date: Fri, 23 Sep 2011 15:03:46 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

David Kastrup <address@hidden> writes:

> Reinhold Kainhofer <address@hidden> writes:
>
>> Am Friday, 23. September 2011, 11:17:32 schrieb David Kastrup:
>>
>>> It is a compromise between the damage and the good developers manage
>>> to do.  The higher the number of developers, the more important it
>>> becomes to avoid damage, since damage blocks everybody, and good
>>> initially helps only a single application.
>>
>> Well, in this case, it's really not David's fault.
>
> It sure is.  State before the commit: documentation compiles.  State
> afterwards: it doesn't.  It is not my _bug_, but certainly my fault.

But we still need to find a solution where I have a chance of getting
work done.  I got a Pentium M at 1700MHz single core, 1GB of RAM.
That's not too shabby.  But "make doc" quite literally takes hours.  I
can't do that for every change.  I am currently doing the "make doc" for
the music function branch.  In order to be able to keep working, I did a
git clone on my work directory and continued work on the documentation.
I am currently doing a "make all info" in there, in parallel with the
"make doc" in the main work directory that has been running since
noonish.  That's just not something that is going to work for every
contribution.  If that is going to be a requirement, I might as well
stop fixing any problems except my own, and possibly not even them.  I
just don't have the resources.

Can we compromise on "make info" instead?  That still goes through all
the TeXinfo sources, but it does not take the same staggeringly awful
amount of time as "make doc" does.  Still a lot, but less.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]