Re: [nex-xsl] What to do?
On 7/4/07, M.Canales.es [EMAIL PROTECTED] wrote: El Miércoles, 4 de Julio de 2007 22:59, Bruce Dubbs escribió: Manuel, I know that you have been working hard on the updates, but options 2 and 3 seem to be even more work. On top of that, I suspect we will want to go to the next stable release when it is available, so a lot of the work done for options 2 and 3 would only be useful for a few months. With option 3 we could forgot about depending on upstream releases, if wanted, before migrating in a not-so-long future to DocBook-XML-5.0, that will be a more big work than the current one in both, the book sources and the stylesheets code. I think this would be the best. It gives maximum flexibility if the stylesheets we use are local to our repos. This also solves the issue of people having different versions of the stylesheets installed. So long as someone (Manuel) tracks upstream to fold any updates into our local copies, then this seems like the best solution, IMO. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [nex-xsl] What to do?
El Jueves, 5 de Julio de 2007 15:40, Dan Nicholson escribió: I think this would be the best. It gives maximum flexibility if the stylesheets we use are local to our repos. This also solves the issue of people having different versions of the stylesheets installed. So long as someone (Manuel) tracks upstream to fold any updates into our local copies, then this seems like the best solution, IMO. Looks like there is some type of consensus. I will start working on the migration today. Many thaks for the replies and comments. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [nex-xsl] What to do?
El Miércoles, 4 de Julio de 2007 22:59, Bruce Dubbs escribió: Do you have any insight into why there will be no 1.72.1 release? Apart the comments in the commits and some developer's post in docbook-apps saying that 1.73.0 will be released soon. I think that the main reason that they have to not do yet a *.1 release is that the nest stable version is supossed to support natively DocBook-XML-5.0. Thus, how can a XSL release be called stable if there is no stable DocBook-XML-5.0 yet? -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[nex-xsl] What to do?
Hi,
As you know, the new XSL stylesheets are ready for production time waiting the
release of stable DocBook-XSL-1.72.1.
The bad news it that there will be no DocBook-XSL-1.72.1 release, but a new
beta DocBook-XSL-1.73.0 that may contains several bugs due very intrusive
changes on how the package is generated from source code, changes on how
processing instructions are handled, and maybe other changes they are
planning before release.
That lead us to the next choices:
1. - Wait up to the next *.1 release to start using the new code. That could
meant to wait at least other 3-4 months :-/
2.- To create our own LFS-XSL-1.0 package based on current new-xsl branch
code and use it as a temporally solution. That implies to add a installation
page for such package in BLFS and to install it on the servers and editor's
machines.
3.- To clean-up the docbook-xsl-snapshoot branch subdirectory to keep only
that files actualy required to build the books. Then merge the code to the
{,B,C,H}LFS SVN trees. That will made the book's sources full auto-contained.
This will increase maintenance work to keep it sinchronized with upstream
code, but IMHO is the more simple solution and my prefered way.
Options 2 and 3 implies also that the DocBook-XSL page in BLFS could be
updated at least up to 1.71.1
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info
TLDP-ES: http://es.tldp.org
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [nex-xsl] What to do?
M.Canales.es wrote:
Hi,
As you know, the new XSL stylesheets are ready for production time waiting
the
release of stable DocBook-XSL-1.72.1.
The bad news it that there will be no DocBook-XSL-1.72.1 release, but a new
beta DocBook-XSL-1.73.0 that may contains several bugs due very intrusive
changes on how the package is generated from source code, changes on how
processing instructions are handled, and maybe other changes they are
planning before release.
That lead us to the next choices:
1. - Wait up to the next *.1 release to start using the new code. That could
meant to wait at least other 3-4 months :-/
2.- To create our own LFS-XSL-1.0 package based on current new-xsl branch
code and use it as a temporally solution. That implies to add a installation
page for such package in BLFS and to install it on the servers and editor's
machines.
3.- To clean-up the docbook-xsl-snapshoot branch subdirectory to keep only
that files actualy required to build the books. Then merge the code to the
{,B,C,H}LFS SVN trees. That will made the book's sources full auto-contained.
This will increase maintenance work to keep it sinchronized with upstream
code, but IMHO is the more simple solution and my prefered way.
Options 2 and 3 implies also that the DocBook-XSL page in BLFS could be
updated at least up to 1.71.1
Manuel,
I know that you have been working hard on the updates, but options 2
and 3 seem to be even more work. On top of that, I suspect we will want
to go to the next stable release when it is available, so a lot of the
work done for options 2 and 3 would only be useful for a few months.
Do you have any insight into why there will be no 1.72.1 release?
My initial reaction is that option 1 is best for the overall project.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [nex-xsl] What to do?
M.Canales.es wrote these words on 07/04/07 15:34 CST:
1. - Wait up to the next *.1 release to start using the new code. That could
meant to wait at least other 3-4 months :-/
2.- To create our own LFS-XSL-1.0 package based on current new-xsl branch
code and use it as a temporally solution. That implies to add a installation
page for such package in BLFS and to install it on the servers and editor's
machines.
3.- To clean-up the docbook-xsl-snapshoot branch subdirectory to keep only
that files actualy required to build the books. Then merge the code to the
{,B,C,H}LFS SVN trees. That will made the book's sources full auto-contained.
This will increase maintenance work to keep it sinchronized with upstream
code, but IMHO is the more simple solution and my prefered way.
Since Manuel is the one doing all the work, I defer my vote to
whichever option he wants (#3). This way we can keep the new version
of FOP in the book, or at least not have to put the previous version
in as well.
--
Randy
rmlscsi: [bogomips 1003.28] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3]
[GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686]
16:04:00 up 6 days, 13:55, 1 user, load average: 0.10, 0.14, 0.09
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [nex-xsl] What to do?
Bruce Dubbs wrote these words on 07/04/07 15:59 CST: My initial reaction is that option 1 is best for the overall project. I typed a long essay in reply to Manuel's question agreeing with Bruce. However, just as I was finishing it, I thought well, since Manuel is the one doing all the work, whatever he thinks is fine with me and deleted my post before sending. I'm sitting on the fence. As I said, I initially thought option 1 was best, but now ... -- Randy rmlscsi: [bogomips 1003.28] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 16:14:00 up 6 days, 14:05, 1 user, load average: 0.18, 0.22, 0.16 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [nex-xsl] What to do?
On Wednesday 04 July 2007 21:34:05 M.Canales.es wrote:
Hi,
As you know, the new XSL stylesheets are ready for production time waiting
the release of stable DocBook-XSL-1.72.1.
The bad news it that there will be no DocBook-XSL-1.72.1 release
That's obviously not the news any of us were hoping for!
That lead us to the next choices:
1. - Wait up to the next *.1 release to start using the new code. That
could meant to wait at least other 3-4 months :-/
While this is probably the easiest option to go for (all projects simply stick
with the current docbook toolchain), it would be a shame to see all of your
hard work on the new-xsl branch not made use of.
2.- To create our own LFS-XSL-1.0 package based on current new-xsl branch
code and use it as a temporally solution. That implies to add a
installation page for such package in BLFS and to install it on the servers
and editor's machines.
This, I fear, would look as if we've created a fork of the upstream project.
While there are some good reasons for creating a fork (lack of maintenance,
undesirable license changes, etc.), the lack of a stable release when we
want/need one by is not one of them, in my opinion.
3.- To clean-up the docbook-xsl-snapshoot branch subdirectory to keep only
that files actualy required to build the books. Then merge the code to the
{,B,C,H}LFS SVN trees. That will made the book's sources full
auto-contained. This will increase maintenance work to keep it sinchronized
with upstream code, but IMHO is the more simple solution and my prefered
way.
I also think this is the way we should proceed. I'm not sure that we
necessarily need to remove files that we don't require for a build of any of
our books - in fact, keeping them around would probably make diffs between
upstream and our downstream copy easier to understand.
Related to this issue is the fact that I'm painfully aware that the 6.3
release has been a long-time coming. Manuel, as you said, the current
snapshot in the new-xsl branch are production ready, so I'd be happy for
these to be merged, if this is the route that is decided upon.
Regards,
Matt.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [nex-xsl] What to do?
El Miércoles, 4 de Julio de 2007 23:29, Matthew Burgess escribió: I also think this is the way we should proceed. I'm not sure that we necessarily need to remove files that we don't require for a build of any of our books - in fact, keeping them around would probably make diffs between upstream and our downstream copy easier to understand. The files to be removed are almost all internationalization support files (keeping only the few ones used for current translators) and the highlighting/ files (used only by Saxon6). Thats around 5M of text files. What I'm afraid is that if the stable DocBook-XSL release take another 5-6 months we could start working on the Relax-NG migration before using the nex-xsl code :-/ -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [nex-xsl] What to do?
On Wednesday 04 July 2007 22:37:01 M.Canales.es wrote: El Miércoles, 4 de Julio de 2007 23:29, Matthew Burgess escribió: I also think this is the way we should proceed. I'm not sure that we necessarily need to remove files that we don't require for a build of any of our books - in fact, keeping them around would probably make diffs between upstream and our downstream copy easier to understand. The files to be removed are almost all internationalization support files (keeping only the few ones used for current translators) and the highlighting/ files (used only by Saxon6). Thats around 5M of text files. Oh, OK. That's pretty limited in scope then - seems to make sense to omit them from our repositories. What I'm afraid is that if the stable DocBook-XSL release take another 5-6 months we could start working on the Relax-NG migration before using the nex-xsl code :-/ Well, I took a look at the Relax-NG stuff a while back and hit a bug in libxml2 (http://bugzilla.gnome.org/show_bug.cgi?id=413248). That pretty much stops any work on migrating the stylesheets to be Relax-NG friendly. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [nex-xsl] What to do?
El Miércoles, 4 de Julio de 2007 23:49, Matthew Burgess escribió: Well, I took a look at the Relax-NG stuff a while back and hit a bug in libxml2 (http://bugzilla.gnome.org/show_bug.cgi?id=413248). That pretty much stops any work on migrating the stylesheets to be Relax-NG friendly. Actualy for DocBook-XML-5.0 libxslt2 is not useful as a validator tool due that it can't do RelaxNG+Schematron validations, at least for now. Plus, Bob Stayton said some days ago in the docbook-apps list that the libxslt maintainer confirms that libxslt will never support XSLT-2.0 -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
