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 _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
