lilypond-devel
[Top][All Lists]
Advanced

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

Re: stop breaking the docs


From: Graham Percival
Subject: Re: stop breaking the docs
Date: Tue, 26 Feb 2008 11:42:35 -0800

On Tue, 26 Feb 2008 15:54:08 +0100
John Mandereau <address@hidden> wrote:

> Le mardi 26 f__vrier 2008 __ 10:08 -0300, Han-Wen Nienhuys a __crit :
> > 
> > Well, yes - but living on the main branch also implies that you will
> > have to deal with breakage more often, simply because things change
> > more often.

I don't care about occasional breakage in input/regression/ ; I just
care about breakage in the whole make system.

> Graham, I agree with Han-Wen; lilypond/translation branch was created
> to avoid dealing with compilation failures not caused by translated
> docs. A dedicated branch would be the best option for GDP, with
> regular merging from and into master; it's not harder than using
> push, pull, checkout and merge Git commands.

That's not what we thought a few months ago:
http://lists.gnu.org/archive/html/lilypond-devel/2007-10/msg00001.html
http://lists.gnu.org/archive/html/lilypond-devel/2007-11/msg00149.html


Here's my opinion: I am not playing with switching between branches,
and the GDP helpers who use git are certainly not doing this either.  If
you want lilypond/gdp on a separate branch, then
1)  give me new commands to put under DOWNLOADING here:
http://web.uvic.ca/~gperciva/advanced-tech.txt
2)  somebody needs to pull GDP changes into main before each release.
3)  somebody needs to pull main changes into GDP after each release.
4)  I will only touch input/lsr/, input/new/, and Documentation/user/,
so if we need to make changes anywhere else I'll just send a patch
to -devel.
5)  People like Mats will need to switch between branches if they
want to fix a small thing in the docs.


I think this causes unnecessary overhead; that's why we stopped using
this method last Nov.  But it's up to you two.

> If you'd like to know a precise plan for docs and makefiles hacking,
> I'd like to
> - improve the silly @lsr and @lsrdir macros with duplicate arguments I
> proposed a while ago (see new thread on -devel)

Err... displaying the name, you mean?  I already did that.  Also, you
might want to wait until we know if we're keeping @lsr at all.  I'm
90% certain that we're junking that macro.

Cheers,
- Graham




reply via email to

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