Michelle Olson wrote: > Thanks for dreaming, this is the kind of discussion we need to have!
Well, it's dreaming... ... but the reality looks like that it would need money to convince CiTec to contribute their stuff to Mozilla.org's Seamonkey, one or two full-time engineers to do the work (approximately 2-3 manyears are needed to get this pushed through mozilla.org code review) and someone at Sun with enougth "power" to get Seamonkey shipped again with Solaris (together with FireFox+Thunderbird to give customers a choice) ... > You wrote: > > Uhm... what about shipping the current SolBook/SGML > > DTD and make all > > _new_ manual pages use DocBook/XML and pull-over the > > old (SolBook/SGML) > > ones incrementally when larger edits are needed ? > > This is a good idea. Incremental changes to the structured markup > of individual files for a source base as large as the SunOS man > pages creates a lot of conditions for mistakes and breakage with > packaging and publishing, so we need to consider that. > There exist multiple SunOS man page gates containing thousands > of files that are all active supporting Solaris base and update > releases with bi-weekly builds, so I'm grappling with the volume > and need help to figure out how to make forward progress without > impact to our traditional responsibilities. Ok... what about a first step and get rid of the nroff "intermediate" step (e.g SolBook ---> nroff ---> plain text (in /usr/bin/man)), start shipping the SolBook/SGML files directly (yes, I know - it will cause some overhead since you have to ship and maintain multiple SolBook/SGML DTDs but you reduce the number of nroff files dramatically...) and then establish the infratructure to handle DocBook/SGML documents (including manual pages), then for DocBook/XML files and finally start the incremental work to convert the SolBook/SGML manual pages to DocBook/XML... > I think that the greater goals of 'use free tools, editable by > vi or emacs, with standard templates' can be achieved with the man > pages, but we have to develop a solution that really scales and > leaves no room for errors when managing the man page gate, > packages, HTML, and PDF delivery that Solaris users have come to > expect. What about limiting the delivery to SolBook- (and later DocBook-)only and let any viewer (e.g. /usr/bin/man or the webserver at docs.sun.com) do the conversion do "on the fly" (this would avoid the nroff, HTML, PDF, PostScript etc. "intermediate" steps) ? [snip] > > Well, it's better than trying to convince each > > OpenSource project on > > this planet to adopt SolBook/SGML... :-) > > Right, I have not signed up for that! :) But, I've certainly had > many conversations with community members who want the SolBook DTD > and SolBook files to work on, rather than DocBook files generated > from SolBook. I think, because it creates the path beyond the > sponsorship model that requires a Sun person to integrate changes. > The cost is learning curve, but if you know DocBook, you effectively > know SolBook. Yes, but you always have the problem to do the conversion from DocBook to SolBook - which needs time (which is a rare resource for small projects). Most OpenSource projects are now willing to write their manual pages in DocBook/XML because anyone (e.g. Linux) can use it - but SolBook is (AFAIK) Solaris-specific and there are not enougth people to maintain the SolBook pages. It's like fighting a windmill. And it's even an uphill battle if you have many many small projects, all with their own manual pages which would require to update the SolBook version of the DocBook master maintained by the upstream project. [snip] > > I just filed the matching RFE at > > http://bugs.opensolaris.org/ ... > > sponsor request follows once I get the email from > > Linda Bernal that the > > bug has been filed. Note that this requires an ARC > > fasttrack case > > (CC:'ing Don Cragun <don.cragun at sun.com> (and hoping > > he'll volunteer to > > do the ARC fasttrack stuff (Don: See > > http://mail.opensolaris.org/pipermail/docs-discuss/200 > > 7-January/000687.html > > , anything below the "Finally:"-line... would you be > > intrested to > > sponsor such a fasttrack ?))). > > Yes, I saw this from Linda yesterday, very cool!! Thanks so > much for helping out and sharing your expertise and time on > the documentation and strategy. It is so important and the > man PATH problem has been a real thorn for us, so I can't > emphasize enough how much your help to get a fix is appreciated, I've send a sponsor request to request-sponsor at opensolaris.org Note that this will require an ARC fasttrack (similar to http://opensolaris.org/os/community/arc/caselog/2006/587/ (that case was about "/etc/ksh.kshrc" which the ksh93-integration project uses to set a default editor mode for ksh93; in our case we'd like to add a default value for ${MANPATH} depending on ${PATH} (e.g. I expect similar pro/contra questions/argumentation during the ARC case... ;-/ ))). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
