Re: [oi-dev] Time for Divorce from Oracle (was Re: pkg5 Linked Images)
On May 30, 2011, at 6:53 PM, Alasdair Lumsden wrote: >>> We need to overhaul the way things are structured into a single >>> unified build system that is natively IPS based. There has been >>> a lot of interest in using the "userland" consolidation to do this, >>> and collapsing the other consolidations into it. For example pkg5, >>> slim_source, g11n etc can just become components of user land. >>> It should be possible for people to check out the source, make >>> changes, and type "cd foo ; make publish ; pkg install foo". Then if >>> they want to build the ISO, do something like "make live-iso" or >>> "make text-iso". This build system should be contained in a single >>> mercurial repo and branched at each release, so security and bug >>> fixes can be kept easily in it. Bye bye mercurial patch queues. >> >> Absolutely. Although I'm not so sure IPS is necessarily the way to go. >> One advantage is that it is here now. But otoh, there are other mature >> systems out there that might be leverages, e.g. pkg_src from NetBSD >> or apt from Debian. The latter would be good from making things more >> familiar for Linux users "goal" that some advocate. > > Without starting a massive packaging debate, IPS is one of the main non- > negotiable points! It's exceptionally good and one of the foundations of > the OS. There's no way we could switch now. There's a lot of FUD out > there about IPS but I hope over time people will come to realise just how > good it is. I agree that we need to keep IPS. Packaging and their dependencies are a lot harder of a problem than many people realize. For instance take a look at this short article by Bart Smaalders: http://blogs.oracle.com/barts/entry/satisfaction I think that a lot of people who make very significant contributions to open source projects would just stare at you blankly at the mention of terms like "boolean satisfiability solvers" and "conjunctive normal form". Some really smart people at Sun, like Bart, took a good hard look at what it would take to solve this problem and came up with IPS. If Bart says that IPS is the way to go then that's good enough for me*. Phil * Disclaimer Bart was a colleague and acquaintance of mine when I worked at Sun. Along with just about everyone else in the OS/Net group he's one of the smartest people I've ever met. -- "What do you think of the Macintosh now?" It is the least unsatisfactory personal computer I know of, but that's an easy win, considering the competition. — Jay Freeman (Author of Wraith Scheme) ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Time for Divorce from Oracle (was Re: pkg5 Linked Images)
On Mon, 2011-05-30 at 23:53 +0100, Alasdair Lumsden wrote: > Hi Ken, > > On 30 May 2011, at 22:32, Ken Gunderson wrote: > > > Your MUA doesn't wrap lines at any reasonable length, which makes > > replying inline more challenging than it should be but a few thoughts: > > Sorry. I'm using Apple mail. I looked in the preferences but nothing jumped > out, if anyone knows how to adjust this let me know. I'm going to switch to > Thunderbird on my macbook when I can find the time, which should hopefully > knock the problem on the head. > > > >> Absolutely.. this is the conclusion that I think everyone has come to. > >> It's interesting you raised this now, I was planning on firing off an > >> email tonight on this very topic. > > > > I think more than a few saw this writing on the wall long, long ago but > > were shot down as Oracle bashers so left and went back to Linux. I'm > > probably one of few coming from non Solaris background still hanging > > around?? > > I'd try not to let any of the trolls on the mailing lists influence which OS > you use; the OI devs care about OI and if you like the product and where its > going then please do stick around! And of course if you don't like where > things are going, you can get involved or give feedback. Sorry, I wasn't referencing OI specifically, more OpenSolaris in general following the "merger", when many still pushing to maintain the status quo for drinking the corporate Kool-Aide. > >> Officially, we should fork. We should update the FAQ and any other docs to > >> reflect this, once we've fleshed out exactly what we mean. > > > > +1 > > > >> If we don't fork, we're following instead of leading, and this (as you > >> pointed out) means we're just a second class citizen in the Solaris > >> ecosphere. If we want to succeed, we have to innovate, and to innovate, we > >> have to attract top developers. The only way to do this is to lead, and > >> allow people to contribute without fear of being trampled on by upstream. > > > > Yes, OI doesn't have the $ and developer resources that Oracle has, but > > still in my mind has the much more potential than Solaris because in > > order to fuel those corporate resources Oracle only wants to sell to > > high end, top echelon big enterprises. This strategy may well make lots > > of money for Oracle but in so doing Solaris will still end up being > > somewhat of niche platform due to being priced out of reach of the > > typical budget conscious enterprise. Meanwhile, OI could well capture > > this "market". Attracting developers will be key. And... > > Absolutely. > > >> Forking will also help with the way things are organised. The way > >> OpenSolaris was developed within Sun, which consisted of different teams > >> around the globe working on different consolidations, with different build > >> systems (some of which are pretty horrid to work with), might work for a > >> large commercial company with paid developers, but it doesn't work for an > >> open source project like ours. It's needlessly complex, and means there's > >> a really high barrier of entry for new developers. People can't easily > >> download the source, get hacking, and install the changes they've made, > >> and get those changes easily integrated. > > > > As you rightly point out - pretty much a nightmare state of affairs, > > even for experienced developers, as some feedback I've gotten goes. > > Never mind someone who may be somewhat technical but not a coder, e.g. > > sysadmins coming from other platforms. > > Yup! > > >> We need to overhaul the way things are structured into a single unified > >> build system that is natively IPS based. There has been a lot of interest > >> in using the "userland" consolidation to do this, and collapsing the other > >> consolidations into it. For example pkg5, slim_source, g11n etc can just > >> become components of userland. It should be possible for people to check > >> out the source, make changes, and type "cd foo ; make publish ; pkg > >> install foo". Then if they want to build the ISO, do something like "make > >> live-iso" or "make text-iso". This build system should be contained in a > >> single mercurial repo and branched at each release, so security and bug > >> fixes can be kept easily in it. Bye bye mercurial patch queues. > > > > Absolutely. Although I'm not so sure IPS is necessarily the way to go. > > One advantage is that it is here now. But otoh, there are other mature > > systems out there that might be leverages, e.g. pkg_src from NetBSD or > > apt from Debian. The latter would be good from making things more > > familiar for Linux users "goal" that some advocate. > > Without starting a massive packaging debate, IPS is one of the main > non-negotiable points! It's exceptionally good and one of the foundations of > the OS. There's no way we could switch now. There's a lot of FUD out there > about IPS but I hope over time people will come to real
Re: [oi-dev] Time for Divorce from Oracle (was Re: pkg5 Linked Images)
IMHO: eternal and happy +1 Best regards, HeCSa. On 5/30/11, Alasdair Lumsden wrote: > Hi Ken, > > On 30 May 2011, at 22:32, Ken Gunderson wrote: > >> Your MUA doesn't wrap lines at any reasonable length, which makes >> replying inline more challenging than it should be but a few thoughts: > > Sorry. I'm using Apple mail. I looked in the preferences but nothing jumped > out, if anyone knows how to adjust this let me know. I'm going to switch to > Thunderbird on my macbook when I can find the time, which should hopefully > knock the problem on the head. > > >>> Absolutely.. this is the conclusion that I think everyone has come to. >>> It's interesting you raised this now, I was planning on firing off an >>> email tonight on this very topic. >> >> I think more than a few saw this writing on the wall long, long ago but >> were shot down as Oracle bashers so left and went back to Linux. I'm >> probably one of few coming from non Solaris background still hanging >> around?? > > I'd try not to let any of the trolls on the mailing lists influence which OS > you use; the OI devs care about OI and if you like the product and where its > going then please do stick around! And of course if you don't like where > things are going, you can get involved or give feedback. > >>> Officially, we should fork. We should update the FAQ and any other docs >>> to reflect this, once we've fleshed out exactly what we mean. >> >> +1 >> >>> If we don't fork, we're following instead of leading, and this (as you >>> pointed out) means we're just a second class citizen in the Solaris >>> ecosphere. If we want to succeed, we have to innovate, and to innovate, >>> we have to attract top developers. The only way to do this is to lead, >>> and allow people to contribute without fear of being trampled on by >>> upstream. >> >> Yes, OI doesn't have the $ and developer resources that Oracle has, but >> still in my mind has the much more potential than Solaris because in >> order to fuel those corporate resources Oracle only wants to sell to >> high end, top echelon big enterprises. This strategy may well make lots >> of money for Oracle but in so doing Solaris will still end up being >> somewhat of niche platform due to being priced out of reach of the >> typical budget conscious enterprise. Meanwhile, OI could well capture >> this "market". Attracting developers will be key. And... > > Absolutely. > >>> Forking will also help with the way things are organised. The way >>> OpenSolaris was developed within Sun, which consisted of different teams >>> around the globe working on different consolidations, with different >>> build systems (some of which are pretty horrid to work with), might work >>> for a large commercial company with paid developers, but it doesn't work >>> for an open source project like ours. It's needlessly complex, and means >>> there's a really high barrier of entry for new developers. People can't >>> easily download the source, get hacking, and install the changes they've >>> made, and get those changes easily integrated. >> >> As you rightly point out - pretty much a nightmare state of affairs, >> even for experienced developers, as some feedback I've gotten goes. >> Never mind someone who may be somewhat technical but not a coder, e.g. >> sysadmins coming from other platforms. > > Yup! > >>> We need to overhaul the way things are structured into a single unified >>> build system that is natively IPS based. There has been a lot of interest >>> in using the "userland" consolidation to do this, and collapsing the >>> other consolidations into it. For example pkg5, slim_source, g11n etc can >>> just become components of userland. It should be possible for people to >>> check out the source, make changes, and type "cd foo ; make publish ; pkg >>> install foo". Then if they want to build the ISO, do something like "make >>> live-iso" or "make text-iso". This build system should be contained in a >>> single mercurial repo and branched at each release, so security and bug >>> fixes can be kept easily in it. Bye bye mercurial patch queues. >> >> Absolutely. Although I'm not so sure IPS is necessarily the way to go. >> One advantage is that it is here now. But otoh, there are other mature >> systems out there that might be leverages, e.g. pkg_src from NetBSD or >> apt from Debian. The latter would be good from making things more >> familiar for Linux users "goal" that some advocate. > > Without starting a massive packaging debate, IPS is one of the main > non-negotiable points! It's exceptionally good and one of the foundations of > the OS. There's no way we could switch now. There's a lot of FUD out there > about IPS but I hope over time people will come to realise just how good it > is. > >>> This wouldn't just help new developers, it would help *everyone*, >>> especially the existing core devs. It would massively speed up >>> development of the OS, and the release engineering process. It would also >>> make ke
Re: [oi-dev] Time for Divorce from Oracle (was Re: pkg5 Linked Images)
Hi Ken, On 30 May 2011, at 22:32, Ken Gunderson wrote: > Your MUA doesn't wrap lines at any reasonable length, which makes > replying inline more challenging than it should be but a few thoughts: Sorry. I'm using Apple mail. I looked in the preferences but nothing jumped out, if anyone knows how to adjust this let me know. I'm going to switch to Thunderbird on my macbook when I can find the time, which should hopefully knock the problem on the head. >> Absolutely.. this is the conclusion that I think everyone has come to. It's >> interesting you raised this now, I was planning on firing off an email >> tonight on this very topic. > > I think more than a few saw this writing on the wall long, long ago but > were shot down as Oracle bashers so left and went back to Linux. I'm > probably one of few coming from non Solaris background still hanging > around?? I'd try not to let any of the trolls on the mailing lists influence which OS you use; the OI devs care about OI and if you like the product and where its going then please do stick around! And of course if you don't like where things are going, you can get involved or give feedback. >> Officially, we should fork. We should update the FAQ and any other docs to >> reflect this, once we've fleshed out exactly what we mean. > > +1 > >> If we don't fork, we're following instead of leading, and this (as you >> pointed out) means we're just a second class citizen in the Solaris >> ecosphere. If we want to succeed, we have to innovate, and to innovate, we >> have to attract top developers. The only way to do this is to lead, and >> allow people to contribute without fear of being trampled on by upstream. > > Yes, OI doesn't have the $ and developer resources that Oracle has, but > still in my mind has the much more potential than Solaris because in > order to fuel those corporate resources Oracle only wants to sell to > high end, top echelon big enterprises. This strategy may well make lots > of money for Oracle but in so doing Solaris will still end up being > somewhat of niche platform due to being priced out of reach of the > typical budget conscious enterprise. Meanwhile, OI could well capture > this "market". Attracting developers will be key. And... Absolutely. >> Forking will also help with the way things are organised. The way >> OpenSolaris was developed within Sun, which consisted of different teams >> around the globe working on different consolidations, with different build >> systems (some of which are pretty horrid to work with), might work for a >> large commercial company with paid developers, but it doesn't work for an >> open source project like ours. It's needlessly complex, and means there's a >> really high barrier of entry for new developers. People can't easily >> download the source, get hacking, and install the changes they've made, and >> get those changes easily integrated. > > As you rightly point out - pretty much a nightmare state of affairs, > even for experienced developers, as some feedback I've gotten goes. > Never mind someone who may be somewhat technical but not a coder, e.g. > sysadmins coming from other platforms. Yup! >> We need to overhaul the way things are structured into a single unified >> build system that is natively IPS based. There has been a lot of interest in >> using the "userland" consolidation to do this, and collapsing the other >> consolidations into it. For example pkg5, slim_source, g11n etc can just >> become components of userland. It should be possible for people to check out >> the source, make changes, and type "cd foo ; make publish ; pkg install >> foo". Then if they want to build the ISO, do something like "make live-iso" >> or "make text-iso". This build system should be contained in a single >> mercurial repo and branched at each release, so security and bug fixes can >> be kept easily in it. Bye bye mercurial patch queues. > > Absolutely. Although I'm not so sure IPS is necessarily the way to go. > One advantage is that it is here now. But otoh, there are other mature > systems out there that might be leverages, e.g. pkg_src from NetBSD or > apt from Debian. The latter would be good from making things more > familiar for Linux users "goal" that some advocate. Without starting a massive packaging debate, IPS is one of the main non-negotiable points! It's exceptionally good and one of the foundations of the OS. There's no way we could switch now. There's a lot of FUD out there about IPS but I hope over time people will come to realise just how good it is. >> This wouldn't just help new developers, it would help *everyone*, especially >> the existing core devs. It would massively speed up development of the OS, >> and the release engineering process. It would also make keeping the OS up to >> date with bug and security fixes for the stable branch, because that would >> be a branch we push updates to. > > Definitely in serious need of ov
Re: [oi-dev] IPS repo organisation and versioning
On Mon, 2011-05-30 at 23:25 +0100, Alasdair Lumsden wrote: > Hi All, > > After discussions online I wanted to flesh out proposals for the IPS repos > and version numbers moving for the stable build and future dev builds. > > Repo wise: > > /release - for the stable releases > /release-staging - a short-term staging area for us to test updates due to be > published to /release, so we don't screw up peoples machines en-masse with > untested updates > > /dev - for our public consumption development releases, because we all know > end users want bleeding edge desktop stuff. > /dev-staging - a short-term place where /dev releases get tested, so that, > again, we don't screw up peoples machines en-masse with untested stuff > > /experimental - primarily for oi devs, where we put in-progress and > known-broken updates for people collaborating on forthcoming > features/releases. This would help for longer-term collaborative development > of bigger changes. > > This is an increase on the number of repos we have now, and I appreciate > there's a maintenance cost, but when we launch stable we will definitely need > to stage the updates. /dev-staging is just /dev-il renamed. /experimental is > new and requested by a few people who want to work on things that will be > unstable for a good few /dev releases. > > Version wise: > > The Oracle build numbers no longer make sense (eg 0.151 aka [snv|oi]_151), so > with the forking we have an opportunity to switch to something saner. We've > been talking about doing this for ages, but haven't really come up with > something. I've had a proposal through from DeanoC which I've tweaked > slightly, which I think makes sense for us to do in time for the stable > release. I'd appreciate feedback. > > For the first stable release, we could bump the version up to 1.0.0. The next > stable release would be 2.0.0. Security and bug fixes would increment the > last digit, so 1.0.X, eg 1.0.4. > > /dev would increment the 1.X field, so you'd have eg 1.2, 1.3, etc. Respins > of /dev (which will hopefully be less common) will bump the minor version, eg > 1.3.1. When we are ready to release, this goes into /dev as 2.0.0, then > /release when we're happy with it. > > This lets people flip between /dev and /release on major versions, which I > think is important. It also lets people at any point upgrade from /release to > /dev without much hassle. It also means bug fixes and security updates into > /release won't hold back people upgrading to /dev. > > For the version numbers in /experimental, I'd suggest we use 1.X.X.X for this > branch, so that the OI devs can switch between /dev and /experimental easily > as the dev builds increase in number. I imagine /experimental at any one > point will be based off /dev with a bunch of extra stuff added. > > There is an alternative to the above, which is to ditch that component of the > IPS version numbers, which has been mentioned. But I'm not sure how well that > would work with flipping between repos and knowing what has been > bug/security-fixed and what hasn't. The advantage of the version numbers > above is that they're very clear. > > Let me know if there are any reasons not to go with the above or any better > alternatives. > > Cheers, > > Alasdair I would give your specifics more thought but in general have found that the *BSD models work well, i.e.: RELEASE - this is stable release and the only stuff that gets updated are security and other _critical_ patches, e.g. sanest thing to track for production development. STABLE - RELEASE plus MFC'd (merged from current) stuff that has been well tested and scratches and common itch that would be too inconvenient to wait for next RELEASE. At first blush, this might appear analogous to your /dev proposal, but not nearly so bleeding edge, i.e. could still run in production with adequate testing. CURRENT - the bleeding edge of development. Code tends to flow from current to stable to release. Other projects, e.g. Debian, add another level in there but I think 3 is enough. The more branches the more dev time needed to maintain, and while 4 might have some advantages I wonder if OI has the dev bandwidth to maintain 4 branches?? ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
On 30 May 2011, at 20:13, Alan Coopersmith wrote: > Yes - SolBook is still used as the source markup, from which the nroff output > is generated for man pages in the OS, and the html & pdf output for the site > formerly known as docs.sun.com. The DTD is in the ON gate/packages - see > /usr/share/lib/sgml/locale/C/dtds/solbookv2 from pkg:/text/doctools . > > For what it's worth, most of the html/pdf/txt docs on > http://www.x.org/releases/X11R7.6/doc/ > were generated from Docbook/XML on a Solaris 11 Express machine, though I did > have to install a couple extra open source packages that aren't currently > in any of the consolidations/package repos: > https://fedorahosted.org/xmlto/ > http://xmlgraphics.apache.org/fop/ > as well as updating to a slightly newer version of the Docbook style sheets > than the JDS consolidation currently packages. > > Personally, I just use emacs to edit docbook files, but I do the same for > html too, never having found (or looked that hard for) a more user-friendly > front end editor. Tales from the trenches are extremely helpful, thanks, Alan. I did a little searching around, trying to get a sense of how people who were maintaining documentation for large project, either as developers or as tech writers saw the state of the art. Here's a fairly random sample, which also provides some incidental name-dropping to give a sense of where different formats are being used: http://www.scons.org/wiki/DeveloperGuide/Documentation/Discussion http://freerangelibrarian.com/2009/06/07/docbook-xml-and-homebrew/ http://lethargy.org/~jesus/writes/xmlxslt-and-docbook-for-docs http://blog.raspberry.nl/2011/04/12/documentation/ http://ffeathers.wordpress.com/2009/05/18/scroll-converts-wiki-to-docbook-and-pdf/ https://docs.jboss.org/author/display/AUTHGUIDE/How+to+release+documentation http://www.dmncommunications.com/weblog/?p=199 http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-August/034044.html http://mark-story.com/posts/view/generating-documentation-with-sphinx If anyone else has some points of reference that speak to what's worked for whom where, please share. smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Time for Divorce from Oracle (was Re: pkg5 Linked Images)
On 30 May 2011, at 22:14, Deano wrote: > +INFINITY+1 > > Whilst we are being all revolutionary. Whats our actual name? > > Open Indiana, OpenIndiana, Openindiana, Project OpenIndiana, The OpenIndiana > Project, ... > > Think I've seen all a one point or another, personally I like OpenIndiana. > Bad English but I like. "OpenIndiana" :-) "Project" makes it sound like some kind of experiment! Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] IPS repo organisation and versioning
Hi All, After discussions online I wanted to flesh out proposals for the IPS repos and version numbers moving for the stable build and future dev builds. Repo wise: /release - for the stable releases /release-staging - a short-term staging area for us to test updates due to be published to /release, so we don't screw up peoples machines en-masse with untested updates /dev - for our public consumption development releases, because we all know end users want bleeding edge desktop stuff. /dev-staging - a short-term place where /dev releases get tested, so that, again, we don't screw up peoples machines en-masse with untested stuff /experimental - primarily for oi devs, where we put in-progress and known-broken updates for people collaborating on forthcoming features/releases. This would help for longer-term collaborative development of bigger changes. This is an increase on the number of repos we have now, and I appreciate there's a maintenance cost, but when we launch stable we will definitely need to stage the updates. /dev-staging is just /dev-il renamed. /experimental is new and requested by a few people who want to work on things that will be unstable for a good few /dev releases. Version wise: The Oracle build numbers no longer make sense (eg 0.151 aka [snv|oi]_151), so with the forking we have an opportunity to switch to something saner. We've been talking about doing this for ages, but haven't really come up with something. I've had a proposal through from DeanoC which I've tweaked slightly, which I think makes sense for us to do in time for the stable release. I'd appreciate feedback. For the first stable release, we could bump the version up to 1.0.0. The next stable release would be 2.0.0. Security and bug fixes would increment the last digit, so 1.0.X, eg 1.0.4. /dev would increment the 1.X field, so you'd have eg 1.2, 1.3, etc. Respins of /dev (which will hopefully be less common) will bump the minor version, eg 1.3.1. When we are ready to release, this goes into /dev as 2.0.0, then /release when we're happy with it. This lets people flip between /dev and /release on major versions, which I think is important. It also lets people at any point upgrade from /release to /dev without much hassle. It also means bug fixes and security updates into /release won't hold back people upgrading to /dev. For the version numbers in /experimental, I'd suggest we use 1.X.X.X for this branch, so that the OI devs can switch between /dev and /experimental easily as the dev builds increase in number. I imagine /experimental at any one point will be based off /dev with a bunch of extra stuff added. There is an alternative to the above, which is to ditch that component of the IPS version numbers, which has been mentioned. But I'm not sure how well that would work with flipping between repos and knowing what has been bug/security-fixed and what hasn't. The advantage of the version numbers above is that they're very clear. Let me know if there are any reasons not to go with the above or any better alternatives. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
On Mon, 2011-05-30 at 23:33 +0200, Damian Wojsław wrote: > W dniu 2011-05-30 23:09, Ken Gunderson pisze: > > On Mon, 2011-05-30 at 21:22 +0200, Damian Wojsław wrote: > >> My personal take is: write the goddamn thing and the choice of the > >> format goes to person that actaully does the thing. There sure is a way > >> to convert it later. > >> So, I'd like to write a part on resource management, but I guess > >> installation comes first. I can cover one method of installation, say > >> graphical install. > >> Any other takers? > > So you would have no problem with, for example, MS Word document? > > > > I thought so... > > You thought what? As long as anyone writes the doc, I can take .docx or > anything else. I'm sure that someone with too much free time on their > hands would convert it quite quickly. Given that OpenIndiana gains any > popularity. You're assuming a newer version of Word than I was implying. But I don't want to haggle, I was merely trying to make a point. Obviously we are of differing opinion on this so we can agree to disagree and leave it at that. More importantly to me, is that we have someone willing to step in and make some serious contributions as part of class project so we should at least be open to evaluating their proposed toolset. Especially since that toolset facilitates migration between various formats. And on that I think we do agree. -- Ken Gunderson ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
W dniu 2011-05-30 23:09, Ken Gunderson pisze: On Mon, 2011-05-30 at 21:22 +0200, Damian Wojsław wrote: My personal take is: write the goddamn thing and the choice of the format goes to person that actaully does the thing. There sure is a way to convert it later. So, I'd like to write a part on resource management, but I guess installation comes first. I can cover one method of installation, say graphical install. Any other takers? So you would have no problem with, for example, MS Word document? I thought so... You thought what? As long as anyone writes the doc, I can take .docx or anything else. I'm sure that someone with too much free time on their hands would convert it quite quickly. Given that OpenIndiana gains any popularity. So now you understand why this issue warrants discussion. :) ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Time for Divorce from Oracle (was Re: pkg5 Linked Images)
On Mon, 2011-05-30 at 21:55 +0100, Alasdair Lumsden wrote: > Hi Ken, > > On 30 May 2011, at 19:04, Ken Gunderson wrote: > > > Not having time to follow your links, but on the subject of Oracle I > > have been meaning to comment for sometime. I think it's long past due > > for IllumOS and OI to accept that we need a clean divorce from Oracle > > and that this masquerade of a trial separation is in reality fooling > > nobody but ourselves. Time to get over it and on with our lives. > > Depending on anything from Oracle leaves us not only vulnerable to the > > whims of the powers that be, but also relegates us to second class > > citizenry. > Greets Alasdair: Your MUA doesn't wrap lines at any reasonable length, which makes replying inline more challenging than it should be but a few thoughts: > Absolutely.. this is the conclusion that I think everyone has come to. It's > interesting you raised this now, I was planning on firing off an email > tonight on this very topic. I think more than a few saw this writing on the wall long, long ago but were shot down as Oracle bashers so left and went back to Linux. I'm probably one of few coming from non Solaris background still hanging around?? > Officially, we should fork. We should update the FAQ and any other docs to > reflect this, once we've fleshed out exactly what we mean. +1 > If we don't fork, we're following instead of leading, and this (as you > pointed out) means we're just a second class citizen in the Solaris > ecosphere. If we want to succeed, we have to innovate, and to innovate, we > have to attract top developers. The only way to do this is to lead, and allow > people to contribute without fear of being trampled on by upstream. Yes, OI doesn't have the $ and developer resources that Oracle has, but still in my mind has the much more potential than Solaris because in order to fuel those corporate resources Oracle only wants to sell to high end, top echelon big enterprises. This strategy may well make lots of money for Oracle but in so doing Solaris will still end up being somewhat of niche platform due to being priced out of reach of the typical budget conscious enterprise. Meanwhile, OI could well capture this "market". Attracting developers will be key. And... > Forking will also help with the way things are organised. The way OpenSolaris > was developed within Sun, which consisted of different teams around the globe > working on different consolidations, with different build systems (some of > which are pretty horrid to work with), might work for a large commercial > company with paid developers, but it doesn't work for an open source project > like ours. It's needlessly complex, and means there's a really high barrier > of entry for new developers. People can't easily download the source, get > hacking, and install the changes they've made, and get those changes easily > integrated. As you rightly point out - pretty much a nightmare state of affairs, even for experienced developers, as some feedback I've gotten goes. Never mind someone who may be somewhat technical but not a coder, e.g. sysadmins coming from other platforms. > We need to overhaul the way things are structured into a single unified build > system that is natively IPS based. There has been a lot of interest in using > the "userland" consolidation to do this, and collapsing the other > consolidations into it. For example pkg5, slim_source, g11n etc can just > become components of userland. It should be possible for people to check out > the source, make changes, and type "cd foo ; make publish ; pkg install foo". > Then if they want to build the ISO, do something like "make live-iso" or > "make text-iso". This build system should be contained in a single mercurial > repo and branched at each release, so security and bug fixes can be kept > easily in it. Bye bye mercurial patch queues. Absolutely. Although I'm not so sure IPS is necessarily the way to go. One advantage is that it is here now. But otoh, there are other mature systems out there that might be leverages, e.g. pkg_src from NetBSD or apt from Debian. The latter would be good from making things more familiar for Linux users "goal" that some advocate. > This wouldn't just help new developers, it would help *everyone*, especially > the existing core devs. It would massively speed up development of the OS, > and the release engineering process. It would also make keeping the OS up to > date with bug and security fixes for the stable branch, because that would be > a branch we push updates to. Definitely in serious need of overhaul. > We should still leverage the Oracle upstream to import changesets that are of > interest to us. But we shouldn't manage our contributions as a set of patches > on top. And herein lies the biggest key paradigm shift. > This is what we should be aiming at for the next build after oi_151. I'm due > to send out another email related to the p
Re: [oi-dev] Time for Divorce from Oracle (was Re: pkg5 Linked Images)
+INFINITY+1 Whilst we are being all revolutionary. Whats our actual name? Open Indiana, OpenIndiana, Openindiana, Project OpenIndiana, The OpenIndiana Project, ... Think I've seen all a one point or another, personally I like OpenIndiana. Bad English but I like. Deano -Original Message- From: Alasdair Lumsden [mailto:alasdai...@gmail.com] Sent: 30 May 2011 21:56 To: OpenIndiana Developer mailing list Subject: Re: [oi-dev] Time for Divorce from Oracle (was Re: pkg5 Linked Images) Hi Ken, On 30 May 2011, at 19:04, Ken Gunderson wrote: > Not having time to follow your links, but on the subject of Oracle I > have been meaning to comment for sometime. I think it's long past due > for IllumOS and OI to accept that we need a clean divorce from Oracle > and that this masquerade of a trial separation is in reality fooling > nobody but ourselves. Time to get over it and on with our lives. > Depending on anything from Oracle leaves us not only vulnerable to the > whims of the powers that be, but also relegates us to second class > citizenry. Absolutely.. this is the conclusion that I think everyone has come to. It's interesting you raised this now, I was planning on firing off an email tonight on this very topic. Officially, we should fork. We should update the FAQ and any other docs to reflect this, once we've fleshed out exactly what we mean. If we don't fork, we're following instead of leading, and this (as you pointed out) means we're just a second class citizen in the Solaris ecosphere. If we want to succeed, we have to innovate, and to innovate, we have to attract top developers. The only way to do this is to lead, and allow people to contribute without fear of being trampled on by upstream. Forking will also help with the way things are organised. The way OpenSolaris was developed within Sun, which consisted of different teams around the globe working on different consolidations, with different build systems (some of which are pretty horrid to work with), might work for a large commercial company with paid developers, but it doesn't work for an open source project like ours. It's needlessly complex, and means there's a really high barrier of entry for new developers. People can't easily download the source, get hacking, and install the changes they've made, and get those changes easily integrated. We need to overhaul the way things are structured into a single unified build system that is natively IPS based. There has been a lot of interest in using the "userland" consolidation to do this, and collapsing the other consolidations into it. For example pkg5, slim_source, g11n etc can just become components of userland. It should be possible for people to check out the source, make changes, and type "cd foo ; make publish ; pkg install foo". Then if they want to build the ISO, do something like "make live-iso" or "make text-iso". This build system should be contained in a single mercurial repo and branched at each release, so security and bug fixes can be kept easily in it. Bye bye mercurial patch queues. This wouldn't just help new developers, it would help *everyone*, especially the existing core devs. It would massively speed up development of the OS, and the release engineering process. It would also make keeping the OS up to date with bug and security fixes for the stable branch, because that would be a branch we push updates to. We should still leverage the Oracle upstream to import changesets that are of interest to us. But we shouldn't manage our contributions as a set of patches on top. This is what we should be aiming at for the next build after oi_151. I'm due to send out another email related to the public IPS repos and the version numbers used within. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
On Mon, 2011-05-30 at 13:53 -0700, Gary Driggs wrote: > FWIW, there are plenty of tools to convert to/from DocBook. Even the WYSIWYG > LaTeX editor, Lyx, can export to DB. > http://wiki.docbook.org/ConvertOtherFormatsToDocBook q.v. > http://johnmacfarlane.net/pandoc > Lyx is excellent tool for making Latex accessible. My kid has been using it since age 12 for writing. But on Solaris would need to have working QT, etc. -- Ken Gunderson ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
On Mon, 2011-05-30 at 21:22 +0200, Damian Wojsław wrote: > My personal take is: write the goddamn thing and the choice of the > format goes to person that actaully does the thing. There sure is a way > to convert it later. > So, I'd like to write a part on resource management, but I guess > installation comes first. I can cover one method of installation, say > graphical install. > Any other takers? So you would have no problem with, for example, MS Word document? I thought so... So now you understand why this issue warrants discussion. :) -- Ken Gunderson ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Time for Divorce from Oracle (was Re: pkg5 Linked Images)
Hi Ken, On 30 May 2011, at 19:04, Ken Gunderson wrote: > Not having time to follow your links, but on the subject of Oracle I > have been meaning to comment for sometime. I think it's long past due > for IllumOS and OI to accept that we need a clean divorce from Oracle > and that this masquerade of a trial separation is in reality fooling > nobody but ourselves. Time to get over it and on with our lives. > Depending on anything from Oracle leaves us not only vulnerable to the > whims of the powers that be, but also relegates us to second class > citizenry. Absolutely.. this is the conclusion that I think everyone has come to. It's interesting you raised this now, I was planning on firing off an email tonight on this very topic. Officially, we should fork. We should update the FAQ and any other docs to reflect this, once we've fleshed out exactly what we mean. If we don't fork, we're following instead of leading, and this (as you pointed out) means we're just a second class citizen in the Solaris ecosphere. If we want to succeed, we have to innovate, and to innovate, we have to attract top developers. The only way to do this is to lead, and allow people to contribute without fear of being trampled on by upstream. Forking will also help with the way things are organised. The way OpenSolaris was developed within Sun, which consisted of different teams around the globe working on different consolidations, with different build systems (some of which are pretty horrid to work with), might work for a large commercial company with paid developers, but it doesn't work for an open source project like ours. It's needlessly complex, and means there's a really high barrier of entry for new developers. People can't easily download the source, get hacking, and install the changes they've made, and get those changes easily integrated. We need to overhaul the way things are structured into a single unified build system that is natively IPS based. There has been a lot of interest in using the "userland" consolidation to do this, and collapsing the other consolidations into it. For example pkg5, slim_source, g11n etc can just become components of userland. It should be possible for people to check out the source, make changes, and type "cd foo ; make publish ; pkg install foo". Then if they want to build the ISO, do something like "make live-iso" or "make text-iso". This build system should be contained in a single mercurial repo and branched at each release, so security and bug fixes can be kept easily in it. Bye bye mercurial patch queues. This wouldn't just help new developers, it would help *everyone*, especially the existing core devs. It would massively speed up development of the OS, and the release engineering process. It would also make keeping the OS up to date with bug and security fixes for the stable branch, because that would be a branch we push updates to. We should still leverage the Oracle upstream to import changesets that are of interest to us. But we shouldn't manage our contributions as a set of patches on top. This is what we should be aiming at for the next build after oi_151. I'm due to send out another email related to the public IPS repos and the version numbers used within. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
FWIW, there are plenty of tools to convert to/from DocBook. Even the WYSIWYG LaTeX editor, Lyx, can export to DB. http://wiki.docbook.org/ConvertOtherFormatsToDocBook q.v. http://johnmacfarlane.net/pandoc -Gary ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
My personal take is: write the goddamn thing and the choice of the format goes to person that actaully does the thing. There sure is a way to convert it later. So, I'd like to write a part on resource management, but I guess installation comes first. I can cover one method of installation, say graphical install. Any other takers? Regards Damian ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
On 05/30/11 11:19 AM, Chris Ridd wrote: > Are the Solaris man pages still authored in some kind of customized Docbook? Yes - SolBook is still used as the source markup, from which the nroff output is generated for man pages in the OS, and the html & pdf output for the site formerly known as docs.sun.com. The DTD is in the ON gate/packages - see /usr/share/lib/sgml/locale/C/dtds/solbookv2 from pkg:/text/doctools . For what it's worth, most of the html/pdf/txt docs on http://www.x.org/releases/X11R7.6/doc/ were generated from Docbook/XML on a Solaris 11 Express machine, though I did have to install a couple extra open source packages that aren't currently in any of the consolidations/package repos: https://fedorahosted.org/xmlto/ http://xmlgraphics.apache.org/fop/ as well as updating to a slightly newer version of the Docbook style sheets than the JDS consolidation currently packages. Personally, I just use emacs to edit docbook files, but I do the same for html too, never having found (or looked that hard for) a more user-friendly front end editor. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
On Mon, 2011-05-30 at 20:49 +0200, Tobias Famulla wrote: > Hi all, > > I thought that Sphinx is better known in the Open-Source-Community, but > because it's not known by the most of you, it might be easier for you, > if I explain it shortly. > Sphinx [1] was original written to write the Python-documentation and it > is written in Python itself, so it runs on any platform on which python > 2.6 runs. Nowadays it is widely used, especially by python-projects > like Zope, Django, Bazaar and also by Blender for example and it is > actively developed. Familiar with all those projects but you're correct - not with Sphinx. Your post was actually first I'd hear of it. > The software itselfs uses reStructuredText which is very close to > metawiki-syntax or especially Markdown. It is build modular and > generates HTML, Gnome- and Windows-Help, man-pages, PDFs and Latex > automatically and is easy to expand. > It is also possible to add mathematically formulars, source-code and > complete API-descriptions. To get an impression of the syntax, you can > click on the "show source" link in the python or sphinx-docu. > As I read, there is also a converter from DocBook to reStructuredText > available, so a converter(or in Sphinx called Generator) to DocBook > might not be an unsolvable problem. > > In my opinion, I prefer reStructuredText over DocBook and Latex, because > it is very easy to write with standard-editors(like vim, emacs, ... in > some with syntax-highlighting, this is true for Latex either) but much > easier to learn. It is also easy to manage with Mercurial or Git and > build with hooks or simple Makefiles (of course automatically to all > formats). After quick review it looks worthy of further consideration. Low bar of entry but, like Python, it is very tab/indentation dependent? That sometimes can be problematic to maintain for people editing from different platforms using different editors, etc. > > If you prefer to use pure DocBook or Latex, it is of course ok for me. I > used Latex some times till now, mostly in university for math. > > Tobias Sphinx seems to meet requirements. I think at this point maybe time for Bayard's gf to take it for a test drive and give us her impressions?? ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
Hi all, I thought that Sphinx is better known in the Open-Source-Community, but because it's not known by the most of you, it might be easier for you, if I explain it shortly. Sphinx [1] was original written to write the Python-documentation and it is written in Python itself, so it runs on any platform on which python 2.6 runs. Nowadays it is widely used, especially by python-projects like Zope, Django, Bazaar and also by Blender for example and it is actively developed. The software itselfs uses reStructuredText which is very close to metawiki-syntax or especially Markdown. It is build modular and generates HTML, Gnome- and Windows-Help, man-pages, PDFs and Latex automatically and is easy to expand. It is also possible to add mathematically formulars, source-code and complete API-descriptions. To get an impression of the syntax, you can click on the "show source" link in the python or sphinx-docu. As I read, there is also a converter from DocBook to reStructuredText available, so a converter(or in Sphinx called Generator) to DocBook might not be an unsolvable problem. In my opinion, I prefer reStructuredText over DocBook and Latex, because it is very easy to write with standard-editors(like vim, emacs, ... in some with syntax-highlighting, this is true for Latex either) but much easier to learn. It is also easy to manage with Mercurial or Git and build with hooks or simple Makefiles (of course automatically to all formats). If you prefer to use pure DocBook or Latex, it is of course ok for me. I used Latex some times till now, mostly in university for math. Tobias [1] Sphinx-page: http://sphinx.pocoo.org/ Python-Documentation for example: http://docs.python.org/py3k/ Page for reading the documentations easily: http://readthedocs.org/ Am 30.05.2011 19:07, schrieb Ken Gunderson: > On Mon, 2011-05-30 at 11:23 -0500, TJ Yang wrote: >> On Mon, May 30, 2011 at 10:49 AM, Ken Gunderson >> wrote: >>> On Mon, 2011-05-30 at 08:24 +0400, Garrett D'Amore wrote: Switching to another less popular doc format doesn't seem like a great idea. I don't work with the documentation frequently, but I'd ask people that do. One thing is that some of these formats are like fads... they come and go. I remember not long ago when SGML was all the rage. :-) From my perspective it would be good to have a format that has good tools available (multiple implementations, at least some of which are portable to other platforms), displays nicely, and provides some basic structure capabitilities to assist in parsing for content or format conversion (e.g. to HTML). If you make me install a bunch of new tools, or learn a format that nobody else uses, I probably will be less inclined to write documentation. (That said, I've not written much except a few man pages, and the format of *those* is relatively constrained by the need to be able to display them with the man command. :-) -- Garrett D'Amore >>> I would think Docbook would be the way to go. Yeah, it's going to >>> require some specific libraries and tools but it's transformable to many >>> different formats. I haven't dealt with it for a while now but easily >>> to morph to man, text, html, and pdf, which I think pretty much covers >>> all reasonable bases. >>> >>> XML situps are a pain after the first few thousand. Last I looked most >>> good XML editors out there were proprietary. All fine and dandy if >>> you're a commercial corp with a documentation staff but such would seem >>> to raise the bar w/o much of any real gain for a small FOSS project. >>> >>> Else maybe the old standard Latex, wh/facilitates same, and although out >>> of vogue at present, I don't think it's not going to disappear anytime >>> soon. Advantage here might be that lots of science and math types will >>> already be somewhat familiar w/it from thesis writing and such, but I'd >>> also think this would not encompass a significant number of OS/IllumOS >>> contributors. >> Hi, All >> >> This is my personal experience on this matter. >> >> Having use both Docbook and LaTeX to on a few manuals before. >> I actually retracted back to use LaTeX from docbook as documentation >> tools to create Manual/Book. >> >> >>> I've never heard of Sphinx. >> Me either. >> >> So to me, Docbook is acceptable but LaTeX is the best tool, IMHO. >> >> tj > Interesting. Plus added advantage that's it's going to be easy access > via emacs, wh/is readily available for pretty much any platform. Yeah, > docbook is going to be too, but goes to show you that sometime old > school tools are old school because they're the best tools > > > ___ > oi-dev mailing list > oi-dev@openindiana.org > http://openindiana.org/mailman/listinfo/oi-dev > -- Jabber: b...@jabber.ccc.de ICQ:279837014 Handy: 0178-5545505 Skype: grund-rauschen <>_
Re: [oi-dev] Hack session in July in Berlin
On 30 May 2011, at 18:23, Alasdair Lumsden wrote: > Hi Damian, > > I'd love to attend this, and will do my best to make it. I've popped the date > in my calendar. > > I'll mail you personally as requested to confirm once I've booked tickets. Ditto. smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
On 30 May 2011, at 18:56, Ken Gunderson wrote: > Anywh... I've not checked those links yet but in general would avoid > wiki markup. Interesting exception here possibly being since we're > using Atlassian wiki already hmmm. This is trouble with the low > hanging fruit - it tends not to withstand the test of time. The advatage > of SGML and subset docbook is that they do - with cost of higher bar of > entry. Why can't we have out cake and eat it too?? > > Latex might be worth a closer look as I suspect there are lots of FOSS > gui'zed editors out there. Ease of use when needed for cranking out > text and also power for power user when needed? Hmmm. > > Else I do think Docbook would be best, even if initial bar is a bit > higher. It would not be unlike Solaris in that regard and most folks > hereabouts seem capable of dealing with it. I'm not sure you've understand my premise: I'm not suggesting that we reduce editing to using wikis, just that wikis can be a very usefully simplifying front-end for content that can be exported to DocBook and then republished into other formats we need. I'd bet that with a bit of nursing, we can get some of the macros we want for things like man pages working just fine in a wiki so that it's not even a question of leaning heavily on wiki markup per se. I don't mean to suggest that wiki authoring is a 100% solution, as I don't think there is a 100% solution for this in terms of editing tools. I do, however, think that we should be trying to maintain as much content as possible with a front end system that has the lowest barrier to entry in terms of toolset complexity and reserve more complex tools for content for which it is absolutely necessary. As per the cite already provided, DocBook is perfectly happy to see itself as an interchange format, so we can afford to use a range of tools, as long as that doesn't create confusion in its own right. Cheers, Bayard smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
On 30 May 2011, at 16:49, Ken Gunderson wrote: > On Mon, 2011-05-30 at 08:24 +0400, Garrett D'Amore wrote: >> Switching to another less popular doc format doesn't seem like a great idea. >> I don't work with the documentation frequently, but I'd ask people that do. >> >> One thing is that some of these formats are like fads... they come and go. >> I remember not long ago when SGML was all the rage. :-) From my perspective >> it would be good to have a format that has good tools available (multiple >> implementations, at least some of which are portable to other platforms), >> displays nicely, and provides some basic structure capabitilities to assist >> in parsing for content or format conversion (e.g. to HTML). >> >> If you make me install a bunch of new tools, or learn a format that nobody >> else uses, I probably will be less inclined to write documentation. (That >> said, I've not written much except a few man pages, and the format of >> *those* is relatively constrained by the need to be able to display them >> with the man command. :-) >> >> -- Garrett D'Amore > > I would think Docbook would be the way to go. Yeah, it's going to > require some specific libraries and tools but it's transformable to many > different formats. I haven't dealt with it for a while now but easily > to morph to man, text, html, and pdf, which I think pretty much covers > all reasonable bases. Yes, and epub. RTFM on your iPhone :-) > XML situps are a pain after the first few thousand. Last I looked most > good XML editors out there were proprietary. All fine and dandy if > you're a commercial corp with a documentation staff but such would seem > to raise the bar w/o much of any real gain for a small FOSS project. There are reasonable docbook-aware editors around which work on Solaris, and which are free for use by non-commercial outfits. Most are Java. XXE (www.xmlmind.com) is the one I use, based on our tech author's recommendation. The fact there *are* many ways to maintain Docbook content is a point in its favour. Are the Solaris man pages still authored in some kind of customized Docbook? Chris ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Time for Divorce from Oracle (was Re: pkg5 Linked Images)
On Mon, 2011-05-30 at 18:37 +0100, Alasdair Lumsden wrote: > Hi All, > > Now that 151 is almost out the door, we need to start looking beyond this to > the next release. I'd like to kick this off looking at pkg5, since Userland > would benefit from a newer pkg version. > > The pkg team integrated "Linked Images" in build 165: > > http://mail.opensolaris.org/pipermail/pkg-discuss/2011-May/026479.html > > I haven't yet had a chance to read the pkg5 linked images design document, > but from what I understand it's a larger change that may give us a headache > without access to the Oracle onnv-gate. > > Has anyone had a chance to read over the design doc? It's over at (this is > from 2010 so it might be out of date): > > http://mail.opensolaris.org/pipermail/pkg-discuss/2010-March/021573.html > > If anyone has read it, is this something that we should avoid for now, and go > with an earlier build, such as 164? Does anyone know of any commits to pkg5 > that might bite us between build 151 and 164? > > We can also look at getting pkg5 building within the Userland framework > itself, but I'll cover this off in a separate mail/thread to keep this one > specifically about linked images and the pkg5 version we pick for the next > dev build. > > Cheers, > > Alasdair Not having time to follow your links, but on the subject of Oracle I have been meaning to comment for sometime. I think it's long past due for IllumOS and OI to accept that we need a clean divorce from Oracle and that this masquerade of a trial separation is in reality fooling nobody but ourselves. Time to get over it and on with our lives. Depending on anything from Oracle leaves us not only vulnerable to the whims of the powers that be, but also relegates us to second class citizenry. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
On Mon, 2011-05-30 at 15:11 +0100, Bayard Bell wrote: > Tobias, > > I was just discussing this with Deano on IRC... > > My proposed litmus test is this: my girlfriend is willing to spend some time > this summer helping out the project as a tech writer (she's got a background > in speciality editing, although not as specialised as IT or *nix in > particular). I'm pretty much with Garrett: the problem isn't that we using > DocBook and should be using something else instead. If someone is interested > in writing documentation, the question seems to be is there a mature toolset > whose learning curve we can reduce to get someone willing able to be > productive quickly. The issue is mostly one of front-end tools, and the > question would thus be whether we can allow most editing to happen in a > really simple format that can be marked up to DocBook for interchange, as a > format that can be consumed by a PDF reader, a browser, or man. Alasdair's > offered similar feedback recently. The DocBook people recognise as much: > looking through some of the DocBook sites, I found the following remark: > > "DocBook has the vices that go with its virtues. Some people find it > unpleasantly heavyweight, and too verbose to be really comfortable as a > composition format. That's OK; as long as the markup tools they like (things > like asciidoc or Perl POD or GNU Texinfo) can generate DocBook out their back > ends, we can all still get what we want. It doesn't matter whether or not > everybody writes in DocBook — as long as it becomes the common document > interchange format that everyone uses, we'll still get unified searchable > documentation databases."[1] > > The premise should be what simple format we can use to generate DocBook for > what I'd take to be the very simple bulk of documentation tasks, preferably > using a wiki-like editor. Doing some very brief research, I came up with > Scroll Wiki Exporter, which would allow us to export documentation from the > Confluence wikis we're already using for OI and Illumos.[2] > > One way or another, the topic does seem ripe for discussion. If you're game > to work with us through the decision process into implementation, how about > we schedule you for a coming oi-meeting? > > Cheers, > Bayard > > [1] http://tldp.org/HOWTO/DocBook-Demystification-HOWTO/x57.html > [2] https://plugins.atlassian.com/plugin/details/7019 Aye carumba!! All you top posters sure mess up the logical flow ... Anywh... I've not checked those links yet but in general would avoid wiki markup. Interesting exception here possibly being since we're using Atlassian wiki already hmmm. This is trouble with the low hanging fruit - it tends not to withstand the test of time. The advatage of SGML and subset docbook is that they do - with cost of higher bar of entry. Why can't we have out cake and eat it too?? Latex might be worth a closer look as I suspect there are lots of FOSS gui'zed editors out there. Ease of use when needed for cranking out text and also power for power user when needed? Hmmm. Else I do think Docbook would be best, even if initial bar is a bit higher. It would not be unlike Solaris in that regard and most folks hereabouts seem capable of dealing with it. I write fairly well, as well, and have previously given consideration to helping out in this regard, but am not too familiar with Solaris and that high bar remains for me. My $0.02 ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] pkg5 Linked Images
Hi All, Now that 151 is almost out the door, we need to start looking beyond this to the next release. I'd like to kick this off looking at pkg5, since Userland would benefit from a newer pkg version. The pkg team integrated "Linked Images" in build 165: http://mail.opensolaris.org/pipermail/pkg-discuss/2011-May/026479.html I haven't yet had a chance to read the pkg5 linked images design document, but from what I understand it's a larger change that may give us a headache without access to the Oracle onnv-gate. Has anyone had a chance to read over the design doc? It's over at (this is from 2010 so it might be out of date): http://mail.opensolaris.org/pipermail/pkg-discuss/2010-March/021573.html If anyone has read it, is this something that we should avoid for now, and go with an earlier build, such as 164? Does anyone know of any commits to pkg5 that might bite us between build 151 and 164? We can also look at getting pkg5 building within the Userland framework itself, but I'll cover this off in a separate mail/thread to keep this one specifically about linked images and the pkg5 version we pick for the next dev build. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Hack session in July in Berlin
Hi Damian, I'd love to attend this, and will do my best to make it. I've popped the date in my calendar. I'll mail you personally as requested to confirm once I've booked tickets. Cheers, Alasdair On 30 May 2011, at 09:59, Damian Wojsław wrote: > Hi > > More information. > > Place: Berlin, at http://www.buero20.org/. > Time: 2/3rd of July. > Cost: 10 EUR for grill. Food and transport on your own. > Sleeping: either you book a hotel. We could try and arrange for place to > crash in sleeping bag. > > If you're interested and can commit, please mail me personally at > dam...@wojslaw.pl > > Regards > > Damian Wojsław > > > > This message was sent using IMP, the Internet Messaging Program. > > ___ > oi-dev mailing list > oi-dev@openindiana.org > http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
On Mon, 2011-05-30 at 11:23 -0500, TJ Yang wrote: > On Mon, May 30, 2011 at 10:49 AM, Ken Gunderson wrote: > > On Mon, 2011-05-30 at 08:24 +0400, Garrett D'Amore wrote: > >> Switching to another less popular doc format doesn't seem like a great > >> idea. I don't work with the documentation frequently, but I'd ask people > >> that do. > >> > >> One thing is that some of these formats are like fads... they come and go. > >> I remember not long ago when SGML was all the rage. :-) From my > >> perspective it would be good to have a format that has good tools > >> available (multiple implementations, at least some of which are portable > >> to other platforms), displays nicely, and provides some basic structure > >> capabitilities to assist in parsing for content or format conversion (e.g. > >> to HTML). > >> > >> If you make me install a bunch of new tools, or learn a format that nobody > >> else uses, I probably will be less inclined to write documentation. (That > >> said, I've not written much except a few man pages, and the format of > >> *those* is relatively constrained by the need to be able to display them > >> with the man command. :-) > >> > >> -- Garrett D'Amore > > > > I would think Docbook would be the way to go. Yeah, it's going to > > require some specific libraries and tools but it's transformable to many > > different formats. I haven't dealt with it for a while now but easily > > to morph to man, text, html, and pdf, which I think pretty much covers > > all reasonable bases. > > > > XML situps are a pain after the first few thousand. Last I looked most > > good XML editors out there were proprietary. All fine and dandy if > > you're a commercial corp with a documentation staff but such would seem > > to raise the bar w/o much of any real gain for a small FOSS project. > > > > Else maybe the old standard Latex, wh/facilitates same, and although out > > of vogue at present, I don't think it's not going to disappear anytime > > soon. Advantage here might be that lots of science and math types will > > already be somewhat familiar w/it from thesis writing and such, but I'd > > also think this would not encompass a significant number of OS/IllumOS > > contributors. > > Hi, All > > This is my personal experience on this matter. > > Having use both Docbook and LaTeX to on a few manuals before. > I actually retracted back to use LaTeX from docbook as documentation > tools to create Manual/Book. > > > > I've never heard of Sphinx. > > Me either. > > So to me, Docbook is acceptable but LaTeX is the best tool, IMHO. > > tj Interesting. Plus added advantage that's it's going to be easy access via emacs, wh/is readily available for pretty much any platform. Yeah, docbook is going to be too, but goes to show you that sometime old school tools are old school because they're the best tools ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
On Mon, May 30, 2011 at 10:49 AM, Ken Gunderson wrote: > On Mon, 2011-05-30 at 08:24 +0400, Garrett D'Amore wrote: >> Switching to another less popular doc format doesn't seem like a great idea. >> I don't work with the documentation frequently, but I'd ask people that do. >> >> One thing is that some of these formats are like fads... they come and go. >> I remember not long ago when SGML was all the rage. :-) From my perspective >> it would be good to have a format that has good tools available (multiple >> implementations, at least some of which are portable to other platforms), >> displays nicely, and provides some basic structure capabitilities to assist >> in parsing for content or format conversion (e.g. to HTML). >> >> If you make me install a bunch of new tools, or learn a format that nobody >> else uses, I probably will be less inclined to write documentation. (That >> said, I've not written much except a few man pages, and the format of >> *those* is relatively constrained by the need to be able to display them >> with the man command. :-) >> >> -- Garrett D'Amore > > I would think Docbook would be the way to go. Yeah, it's going to > require some specific libraries and tools but it's transformable to many > different formats. I haven't dealt with it for a while now but easily > to morph to man, text, html, and pdf, which I think pretty much covers > all reasonable bases. > > XML situps are a pain after the first few thousand. Last I looked most > good XML editors out there were proprietary. All fine and dandy if > you're a commercial corp with a documentation staff but such would seem > to raise the bar w/o much of any real gain for a small FOSS project. > > Else maybe the old standard Latex, wh/facilitates same, and although out > of vogue at present, I don't think it's not going to disappear anytime > soon. Advantage here might be that lots of science and math types will > already be somewhat familiar w/it from thesis writing and such, but I'd > also think this would not encompass a significant number of OS/IllumOS > contributors. Hi, All This is my personal experience on this matter. Having use both Docbook and LaTeX to on a few manuals before. I actually retracted back to use LaTeX from docbook as documentation tools to create Manual/Book. > I've never heard of Sphinx. Me either. So to me, Docbook is acceptable but LaTeX is the best tool, IMHO. tj > > > > My $0.02, fwiw. > > > > > ___ > oi-dev mailing list > oi-dev@openindiana.org > http://openindiana.org/mailman/listinfo/oi-dev > -- T.J. Yang ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
On Mon, 2011-05-30 at 08:24 +0400, Garrett D'Amore wrote: > Switching to another less popular doc format doesn't seem like a great idea. > I don't work with the documentation frequently, but I'd ask people that do. > > One thing is that some of these formats are like fads... they come and go. I > remember not long ago when SGML was all the rage. :-) From my perspective it > would be good to have a format that has good tools available (multiple > implementations, at least some of which are portable to other platforms), > displays nicely, and provides some basic structure capabitilities to assist > in parsing for content or format conversion (e.g. to HTML). > > If you make me install a bunch of new tools, or learn a format that nobody > else uses, I probably will be less inclined to write documentation. (That > said, I've not written much except a few man pages, and the format of *those* > is relatively constrained by the need to be able to display them with the man > command. :-) > > -- Garrett D'Amore I would think Docbook would be the way to go. Yeah, it's going to require some specific libraries and tools but it's transformable to many different formats. I haven't dealt with it for a while now but easily to morph to man, text, html, and pdf, which I think pretty much covers all reasonable bases. XML situps are a pain after the first few thousand. Last I looked most good XML editors out there were proprietary. All fine and dandy if you're a commercial corp with a documentation staff but such would seem to raise the bar w/o much of any real gain for a small FOSS project. Else maybe the old standard Latex, wh/facilitates same, and although out of vogue at present, I don't think it's not going to disappear anytime soon. Advantage here might be that lots of science and math types will already be somewhat familiar w/it from thesis writing and such, but I'd also think this would not encompass a significant number of OS/IllumOS contributors. I've never heard of Sphinx. My $0.02, fwiw. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
Tobias, I was just discussing this with Deano on IRC... My proposed litmus test is this: my girlfriend is willing to spend some time this summer helping out the project as a tech writer (she's got a background in speciality editing, although not as specialised as IT or *nix in particular). I'm pretty much with Garrett: the problem isn't that we using DocBook and should be using something else instead. If someone is interested in writing documentation, the question seems to be is there a mature toolset whose learning curve we can reduce to get someone willing able to be productive quickly. The issue is mostly one of front-end tools, and the question would thus be whether we can allow most editing to happen in a really simple format that can be marked up to DocBook for interchange, as a format that can be consumed by a PDF reader, a browser, or man. Alasdair's offered similar feedback recently. The DocBook people recognise as much: looking through some of the DocBook sites, I found the following remark: "DocBook has the vices that go with its virtues. Some people find it unpleasantly heavyweight, and too verbose to be really comfortable as a composition format. That's OK; as long as the markup tools they like (things like asciidoc or Perl POD or GNU Texinfo) can generate DocBook out their back ends, we can all still get what we want. It doesn't matter whether or not everybody writes in DocBook — as long as it becomes the common document interchange format that everyone uses, we'll still get unified searchable documentation databases."[1] The premise should be what simple format we can use to generate DocBook for what I'd take to be the very simple bulk of documentation tasks, preferably using a wiki-like editor. Doing some very brief research, I came up with Scroll Wiki Exporter, which would allow us to export documentation from the Confluence wikis we're already using for OI and Illumos.[2] One way or another, the topic does seem ripe for discussion. If you're game to work with us through the decision process into implementation, how about we schedule you for a coming oi-meeting? Cheers, Bayard [1] http://tldp.org/HOWTO/DocBook-Demystification-HOWTO/x57.html [2] https://plugins.atlassian.com/plugin/details/7019 On 30 May 2011, at 05:24, Garrett D'Amore wrote: > Switching to another less popular doc format doesn't seem like a great idea. > I don't work with the documentation frequently, but I'd ask people that do. > > One thing is that some of these formats are like fads... they come and go. I > remember not long ago when SGML was all the rage. :-) From my perspective it > would be good to have a format that has good tools available (multiple > implementations, at least some of which are portable to other platforms), > displays nicely, and provides some basic structure capabitilities to assist > in parsing for content or format conversion (e.g. to HTML). > > If you make me install a bunch of new tools, or learn a format that nobody > else uses, I probably will be less inclined to write documentation. (That > said, I've not written much except a few man pages, and the format of *those* > is relatively constrained by the need to be able to display them with the man > command. :-) > > -- Garrett D'Amore > > On May 30, 2011, at 2:22 AM, "Tobias Famulla" wrote: > >> Dear all Developers, >> >> As I mentioned on the Discussion-List(see below), I had the idea of >> transforming the OpenSolaris-documentation to another system and change some >> parts to the OpenIndiana specific behaviors. >> >> Deano wrote on the Discussion-list, that it might be more helpful, to >> discuss the pros and cons of different systems and especially asking for >> people who also write the discussion and maintain it afterwards. >> I think I am not able to maintain such documentation, because I am very new >> to the OpenIndiana and Solaris operating system and such developement >> process as a whole. >> >> Because of that, I would ask on this list, if anybody sees the importance of >> an documentation, sees advantages of a special documentation system and >> would be able to maintain it. The other question is of course, whether the >> below described idea is an good one, or work on another part would be more >> helpful. >> >> Sincerely, >> >> Tobias >> >> Original-Nachricht >> Betreff: [OpenIndiana-discuss] Documentation-Project >> Datum: Thu, 26 May 2011 15:54:36 +0200 >> Von: Tobias Famulla >> Antwort an: Discussion list for OpenIndiana >> >> An: Discussion list for OpenIndiana >> >> Hello OpenIndiana-Community, >> >> I am in an Open-Source-seminar at University, in which we have to hold a >> presentation about an Open-Source project and participate in the >> development-process of this project. >> >> I chose OpenIndiana for this Course, because I think it is an >> interesting young project and the developement of a free Solaris
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
Switching to another less popular doc format doesn't seem like a great idea. I don't work with the documentation frequently, but I'd ask people that do. One thing is that some of these formats are like fads... they come and go. I remember not long ago when SGML was all the rage. :-) From my perspective it would be good to have a format that has good tools available (multiple implementations, at least some of which are portable to other platforms), displays nicely, and provides some basic structure capabitilities to assist in parsing for content or format conversion (e.g. to HTML). If you make me install a bunch of new tools, or learn a format that nobody else uses, I probably will be less inclined to write documentation. (That said, I've not written much except a few man pages, and the format of *those* is relatively constrained by the need to be able to display them with the man command. :-) -- Garrett D'Amore On May 30, 2011, at 2:22 AM, "Tobias Famulla" wrote: > Dear all Developers, > > As I mentioned on the Discussion-List(see below), I had the idea of > transforming the OpenSolaris-documentation to another system and change some > parts to the OpenIndiana specific behaviors. > > Deano wrote on the Discussion-list, that it might be more helpful, to discuss > the pros and cons of different systems and especially asking for people who > also write the discussion and maintain it afterwards. > I think I am not able to maintain such documentation, because I am very new > to the OpenIndiana and Solaris operating system and such developement process > as a whole. > > Because of that, I would ask on this list, if anybody sees the importance of > an documentation, sees advantages of a special documentation system and would > be able to maintain it. The other question is of course, whether the below > described idea is an good one, or work on another part would be more helpful. > > Sincerely, > > Tobias > > Original-Nachricht > Betreff: [OpenIndiana-discuss] Documentation-Project > Datum:Thu, 26 May 2011 15:54:36 +0200 > Von: Tobias Famulla > Antwort an: Discussion list for OpenIndiana > > An: Discussion list for OpenIndiana > > Hello OpenIndiana-Community, > > I am in an Open-Source-seminar at University, in which we have to hold a > presentation about an Open-Source project and participate in the > development-process of this project. > > I chose OpenIndiana for this Course, because I think it is an > interesting young project and the developement of a free Solaris is > important for the open-source-community. > > Becaus it lacks in a good documentation of OpenIndiana yet, as far as i > read in the wiki, I had the idea of writing a script to transform the > latest OpenSolaris documentation from XML to a > Sphinx-documentation(restructuredText) and rewrite it in some parts. I > think Sphinx is a wonderful tool to write a good documentation and > export it to html and pdf. It might be easier to handle these documents > than the XML ones. > > If you like the idea of writing the OpenSolaris-documentation in Sphinx, > it might be helpful to integrate it in the revision control system to > have an easy way to manage the documentation. > > On another point, it would help me for the presentation, if someone > writes me, how decisions for the project are made and how the project is > managed(commitments to the sourcetree and something like that) > > Sincerely yours, > > Tobias Famulla > > ___ > OpenIndiana-discuss mailing list > openindiana-disc...@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss > > > ___ > oi-dev mailing list > oi-dev@openindiana.org > http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
Hello, * Tobias Famulla [2011-05-30 00:22]: > As I mentioned on the Discussion-List(see below), I had the idea of > transforming the OpenSolaris-documentation to another system and change > some parts to the OpenIndiana specific behaviors. I think something comparable to the OpenSolaris Getting Started Guide (see http://dlc.sun.com/osol/docs/content/2009.06/getstart/docinfo.html) and the numerous Administrator, End User and Developer Howtos in the Wiki (see http://wikis.sun.com/display/OpenSolarisInfo200906/User+Information, http://wikis.sun.com/display/OpenSolarisInfo200906/System+Administration+Information, and http://wikis.sun.com/display/OpenSolarisInfo200906/Developer+Information) is really missing and would be highly useful to the project. The problem is that the above documentation does not seem to be available under a license which allows modification and redistribution, so you would have to produce new and genuine documentation. There are is already a stub for a FreeBSD-like handbook in our wiki under http://wiki.openindiana.org/oi/OpenIndiana+Handbook with some documentation fragments. That effort has not gotten very far yet but it might be a starting point. So far we have had people contributing to the wiki but not really a coordinated team working on improving documentation in a systematic manner. It's just about manpower and someone picking it up, the project can provide infrastructure (e.g. a mailinglist for coordination) as needed, if you would like to contribute in this area I'm sure it will be highly appreciated. > Deano wrote on the Discussion-list, that it might be more helpful, to > discuss the pros and cons of different systems and especially asking for > people who also write the discussion and maintain it afterwards. > I think I am not able to maintain such documentation, because I am very > new to the OpenIndiana and Solaris operating system and such > developement process as a whole. Since I'm not familiar with the different documentation system I'll leave that for others to comment on. -- Guido Berhoerster ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Hack session in July in Berlin
Hi More information. Place: Berlin, at http://www.buero20.org/. Time: 2/3rd of July. Cost: 10 EUR for grill. Food and transport on your own. Sleeping: either you book a hotel. We could try and arrange for place to crash in sleeping bag. If you're interested and can commit, please mail me personally at dam...@wojslaw.pl Regards Damian Wojsław This message was sent using IMP, the Internet Messaging Program. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
