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

[John Mandereau]

Hi guys,
I forgot to reply to -devel too, so I include at least all of Graham's
reply.

Le mardi 03 novembre 2009 à 19:21 +0000, Graham Percival a écrit :
> On Fri, Oct 30, 2009 at 07:18:50PM +0100, John Mandereau wrote: 
> > The problem is, we might end up creating many issues for trivial
> > building problems, which would surely clutter issues with LilyPond
> > programs, and in our current situation for a build system that may die
> > soon.
> 
> I still don't see the problem.  Searching for Type-Defect or
> Type-Enhancement (or just "label:not-maintainability") is easy
> enough.  I agree that we don't want many issues for trivial
> building problems, but I think we can rely on developers to use
> their own judgement as to what's trivial or not.
> 
> 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?  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.


> Why not?  I mean, they're called "issues" and not "bugs".  We even
> have labels for Type-Other and maintainability.

You're right.


> 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.



> > Speaking of, doesn't ROADMAP already say this?
> 
> Oops.  I never look at that file.  I guess I should include it in
> the CG.

Agreed.



> 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?


>   If it adds less than 10 minutes to the total
> processing time, I'd say go for it.

It mostly depends on the speed of your hard disk and the amount of
output HTML files that are still in the cache in RAM.


> 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

web/
doc/vx.y

or

/ (website)
/doc/vx.y

I don't suggest putting both the website and docs in the same directory,
as this would break a few more links (this is easily fixed
with .htaccess-like stuff, as you pointed out below), and more
importantly this would add a discrepancy between URLs of the last stable
docs -- e.g. /(web/)notation/ -- and URLs of doc for other branches --
e.g. /doc/vx.y/notation.


> > I guess there will be no particular difficulty doing
> > so, but this might break more old pages URLs than putting the new
> > website in web/. 
> 
> We have url forwarding (or whatever the technical name is) in
> .htaccess, so this shouldn't be a problem.

Sure, agreed.


> > I've done few math work and much bureaucratic work, but this should
> > change in November.  A waf-based build system could be developed much
> > quicker (more than twice faster) with two people on it; we'd have been
> > two on switching to SCons if I accepted to switch to this build system,
> > but because of its slowness I don't want to go for it. As I'm alone to
> > work on it, my motivation for this is down too easily to enable me
> > giving any timeframe.
> 
> 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 :-(


> I mean, we could try asking for volunteers
> to help you, but this stuff is probably sufficiently technical
> that any random volunteers from -user would slow you down rather
> than help.

Exactly.

Best,
John

signature.asc
Description: Ceci est une partie de message numériquement signée