lilypond-devel
[Top][All Lists]
Advanced

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

Re: Issue 872 in lilypond: Changes split-page has broken images


From: Graham Percival
Subject: Re: Issue 872 in lilypond: Changes split-page has broken images
Date: Wed, 4 Nov 2009 00:11:46 +0000
User-agent: Mutt/1.5.18 (2008-05-17)

On Tue, Nov 03, 2009 at 08:52:30PM +0100, John Mandereau wrote:
> Le mardi 03 novembre 2009 à 19:21 +0000, Graham Percival a écrit :
> > Evidently this issue was "too trivial", so I'll bear that in mind
> > when considering future additions.
> 
> Ah, thanks :-)  Before raising such an issue in the future, may I
> suggest you bug me with CC to -devel?

Sure!  At the time, I thought you were completely engrossed in
sorting out your move, and I didn't want to bother you.

> I mean, I'm not expecting you to
> master all of postprocess_html.py and other stuff like this, you have
> much more important things to do.

Yes and no.  My stated aim is that my job is to let everybody else
do their jobs.  If the doc people (kind-of not counting myself)
want new manuals, I'll do that.  If the font people want updated
packages in GUB, I'll do that.  For that matter, if anybody wants
releases, I'll do that.

If somebody else is willing to poke around in postprocess_html.py,
I will gladly not attempt to learn what's happening... but if
nobody else is doing it, I'll buckle down and figure it out.

> > If there's a strong argument against using the Issue tracker for
> > all sorts of development issues, I don't mind reserving it for
> > purely bugs... but then how should we keep track of problems in
> > GUB, the build system, translation infrastructure, etc?
> 
> On the wiki ;-)  I have no special strong argument, the little argument
> I have is that comments on Google Code issues are turned into emails
> with horrible indentation.

Why don't we just agree that any substantial discussion (more than
2 or 3 sentences) should be on the mailist?  Once the discussion
has ended, we can add a link to the archives on the tracker so it
doesn't get lost.

> > It explains that there's "special processing, so it can be used on
> > a website with content negotiation for automatic language
> > selection", but it's not clear to me why we don't make *all* the
> > HTML docs "online".
> 
> Why do you mean by "making *all* the HTML docs online"?
> Are you aware that we do need an offline and a online target as long as
> the website uses the automatic language selection we currently have and
> we want to distribute a docball?  Or do you mean we should always build
> both offline and online targets?

I'm not aware that we need an offline target.  If that's used for
the docball, why not build that from the online target?

This isn't rhetoric; I really honestly do not know what the point
is for having an "offline" doc target.  What do we lose if we only
have the "online" doc target?

> > But if the lilypond docs place bugs.html under general/bugs.html,
> > then we need to do extra work to strip that out.
> 
> We'll need such extra work anyway for the online target () if we keep a
> directory scheme like

I'm not convinced about this, but let's discuss it again in a few
weeks when it becomes relevant.


> > In that case, I think I'll keep on muddling with the old build
> > system when necessary.
> 
> I frankly don't recommend you to spend time on it, OTOH I concede that
> it's sometimes necessary :-(

Well, off the top of my head, the only thing that's left before
declaring the build system side of the new website "finished" is
fixing the image links in changes.tely.  So... 15 minutes (?) of
work for you to modify postprocess_html.py, 60 minutes (?) for me
to understand and then modify postprocess_html.py... or 5-10 weeks
to get the new doc build system ready?

At this stage, I really want to be finishing projects and getting
2.14 ready, so I think it makes sense to work on the old build
system.
(I consider postprocess.py part of the build system)

Cheers,
- Graham




reply via email to

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