[Scons-dev] Documentation in EPUB-Format?
Hi devs, since we're now using DocBook as source format for all our documentation, it would technically be relatively easy to publish things like the MAN page or the UserGuide in EPUB format as well. The latest versions of pandoc ( 1.12.x) offer a DocBook reader and do a, more or less, good job in rendering the single markups. Find a shortened version of the UserGuide attached, as a first example... The question now is: Should we go this route? Then I'd try to integrate an ebook target into the build and bootstrapping process, such that EPUBs get created automatically if pandoc can be found on the current system. Note, how this would add a dependency to pandoc for all the ReleaseManagers...and this currently means installing the full Haskell platform package with approx 400MB. ;) Your comments? Best regards, Dirk scons.epub Description: application/epub ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
[Scons-dev] Working branches
Now we have default and python3-port as working branches, we need a workflow that ensures they are kept in sync. If python3-port is left behind, then all the work to date will have been for nought. I also need advice on how to handle feature clones: I have the SCons_D_Tooling clone and have no idea how to manage it now with the two working branches. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Working branches
Hi Russel, On 04.10.2013 19:23, Russel Winder wrote: Now we have default and python3-port as working branches, we need a workflow that ensures they are kept in sync. If python3-port is left behind, then all the work to date will have been for nought. hmmm, we probably should discuss (and then decide) how we want development to look like, once we have a working python3 branch. Will we continue to support both major versions 2.x and 3.x? If yes, in which direction (2-3 or 3-2) do we merge preferably, meaning: where do we do most of our development? Or does the 2.x stuff get abandoned and we care about Python 3.x only? I also need advice on how to handle feature clones: I have the SCons_D_Tooling clone and have no idea how to manage it now with the two working branches. I have my own repository scons_experimental for things like this. I pull from the SCons main repo whenever I feel the need to update, but never push back. So, I can merge freely and can also use named branches as much as I like...one for every feature, basically. For features to be published, I create a patch and apply it to my clone of the main repo...then issue a pull request from there. Best regards, Dirk ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Working branches
On Fri, Oct 4, 2013 at 2:10 PM, Dirk Bächle tshor...@gmx.de wrote: Hi Russel, On 04.10.2013 19:23, Russel Winder wrote: Now we have default and python3-port as working branches, we need a workflow that ensures they are kept in sync. If python3-port is left behind, then all the work to date will have been for nought. hmmm, we probably should discuss (and then decide) how we want development to look like, once we have a working python3 branch. Will we continue to support both major versions 2.x and 3.x? If yes, in which direction (2-3 or 3-2) do we merge preferably, meaning: where do we do most of our development? Or does the 2.x stuff get abandoned and we care about Python 3.x only? What I've been thinking is this: * for now, we continue working on the python3-port branch until it works. * until python3-port works, regular changes go on default as usual. * merge from default into python3-port as needed, to keep it current. * as soon as it's working (which means on both python2 and python3 all tests pass, and a few people say it works in their environments), we merge it to default and close that branch. * From then on, all new changes go on default, and must support our list of supported pythons (2.7.2 or greater, and 3.3 or greater, right?) I also need advice on how to handle feature clones: I have the SCons_D_Tooling clone and have no idea how to manage it now with the two working branches. I have my own repository scons_experimental for things like this. I pull from the SCons main repo whenever I feel the need to update, but never push back. So, I can merge freely and can also use named branches as much as I like...one for every feature, basically. For features to be published, I create a patch and apply it to my clone of the main repo...then issue a pull request from there. Feature branches seem to be the worst part of hg IMHO. Dirk, your workflow seems OK, although a bit indirect; you could run into problems once your changes are accepted, pulling back in. Russel, would Dirk's setup work for you? Alternatively if we used a separate repo for python3 work would that be better? (Seems weird to me, even though it seems to be common practice in mercurial). -- Gary ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Working branches
On Fri, 2013-10-04 at 20:10 +0200, Dirk Bächle wrote: […] hmmm, we probably should discuss (and then decide) how we want development to look like, once we have a working python3 branch. Will we continue to support both major versions 2.x and 3.x? If yes, in which direction (2-3 or 3-2) do we merge preferably, meaning: where do we do most of our development? Or does the 2.x stuff get abandoned and we care about Python 3.x only? My preference is to have a single default branch that compiles under Python 2.7 and Python 3.3 (and soon Python 3.4). […] I have my own repository scons_experimental for things like this. I pull from the SCons main repo whenever I feel the need to update, but never push back. So, I can merge freely and can also use named branches as much as I like...one for every feature, basically. For features to be published, I create a patch and apply it to my clone of the main repo...then issue a pull request from there. I have never got into MQ which may solve the problem. But using Ockham's Razor, I'd prefer to have a single development branch in the mainline, then I can use the same workflow that is already in place. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Documentation in EPUB-Format?
I like the idea since I like ebooks. However, I will be honest and say that for code development I would not be too likely to use it since on my desktop machines I don't have a great epub viewers. So I guess I would say that if there was no extra effort or file space required go ahead and add it but if the extra effort is noticeable don't bother. Just my 2 cents worth. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 On 10/4/13 5:56 AM, Dirk Bächle tshor...@gmx.de wrote: Hi devs, since we're now using DocBook as source format for all our documentation, it would technically be relatively easy to publish things like the MAN page or the UserGuide in EPUB format as well. The latest versions of pandoc ( 1.12.x) offer a DocBook reader and do a, more or less, good job in rendering the single markups. Find a shortened version of the UserGuide attached, as a first example... The question now is: Should we go this route? Then I'd try to integrate an ebook target into the build and bootstrapping process, such that EPUBs get created automatically if pandoc can be found on the current system. Note, how this would add a dependency to pandoc for all the ReleaseManagers...and this currently means installing the full Haskell platform package with approx 400MB. ;) Your comments? Best regards, Dirk ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
