From stickster at gmail.com Wed Jun 1 14:31:25 2005 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 01 Jun 2005 10:31:25 -0400 Subject: Install Guide HTML In-Reply-To: References: <1117571799.5172.4.camel@localhost.localdomain> Message-ID: <1117636285.6217.6.camel@localhost.localdomain> After sending this to Elliot and cc'ing Karsten and Stuart, I realized the FDSCo list was a better destination. Read on... On Tue, 2005-05-31 at 18:00 -0400, Elliot Lee wrote: > On Tue, 31 May 2005, Paul W. Frields wrote: > > > We have the Install Guide pretty much "camera ready," per the FDSCo > > meeting today. Karsten wants to give it a quick cover2cover read before > > we let it go, but we are wondering if we will be able to include a > > nochunk HTML version on the ISO images. Are we too late for the final > > spin? This would be *super* helpful to have on the disc if possible. > > Besides putting the docs in an RPM package that goes onto the installed > system, we don't really have a good way to include additional docs on the > CDs, and it will take a bit of work to retrofit the releng tools. Given > the other stuff that needs attention, it's just too late. > > Please make sure it gets on the plate early on in the FC5 devel cycle > though - there's nothing inherently unreasonable about the request... OK, I understand. Originally we just wanted a single .html file in the root of disc1, but I realized after I sent the email that whatever we wanted to include, it should probably be done as part of the automated {re,}spin, which means some work to integrate. We will revisit this issue for FC4 and simply make sure the release notes point to the f.r.c web site for the installation guide. I'm cc'ing Karsten to make sure that the release notes point prominently at the f.r.c copy of the installation guide, which should exist by the time the ISO's are out. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tfox at redhat.com Wed Jun 1 14:44:22 2005 From: tfox at redhat.com (Tammy Fox) Date: Wed, 01 Jun 2005 10:44:22 -0400 Subject: Before shipping the IG... In-Reply-To: <1117579475.29735.95.camel@erato.phig.org> References: <1117575069.13285.5.camel@humboldt.eln.lan> <1117579475.29735.95.camel@erato.phig.org> Message-ID: <1117637062.6340.6.camel@localhost.localdomain> On Tue, 2005-05-31 at 15:44 -0700, Karsten Wade wrote: > On Tue, 2005-05-31 at 22:31 +0100, Stuart Ellis wrote: > > Just in case... > > > > For safety, the &DRAFTNOTICE; is still at the top of fedora-install- > > guide-intro-en.xml. If somebody commits it to the Website or adds it to > > the ISO please remove the entity (since it will officially be The Real > > Thing at that point). > > Good reminder, thanks. We need to make that part of the release > checklist. :) > > I note that the schedule is for 6 June to ship FC4. Therefore, that is > our target for having it go live at a specific URL. > > For the added value, I'll talk with whomever is doing the announcement > to put in a plug for the IG right at the top. ;) > Can you also send the blurb to gdk so he can include it in the Fedora status report for June? Thanks, Tammy > The weeks following the release may present a few bugs to us for the IG. > Expect the unexpected. > > - Karsten > Know the unknowable > -- > fedora-dsco-list mailing list > fedora-dsco-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-dsco-list From ghenry at suretecsystems.com Wed Jun 1 19:41:56 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Wed, 1 Jun 2005 20:41:56 +0100 Subject: Directory server docs Message-ID: <200506012041.56826.ghenry@suretecsystems.com> Seen: http://directory.fedora.redhat.com/wiki/Main_Page -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From stuart at elsn.org Wed Jun 1 20:22:49 2005 From: stuart at elsn.org (Stuart Ellis) Date: Wed, 01 Jun 2005 21:22:49 +0100 Subject: Directory server docs In-Reply-To: <200506012041.56826.ghenry@suretecsystems.com> References: <200506012041.56826.ghenry@suretecsystems.com> Message-ID: <1117657369.4296.5.camel@humboldt.eln.lan> On Wed, 2005-06-01 at 20:41 +0100, Gavin Henry wrote: > Seen: > > http://directory.fedora.redhat.com/wiki/Main_Page I'm downloading this now... There's a stack of OPL documentation here: http://www.redhat.com/docs/manuals/dir-server/ I don't envy the people having to maintain it all ;) -- Stuart Ellis stuart at elsn.org Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ GPG key ID: 7098ABEA GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Thu Jun 2 13:08:07 2005 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 02 Jun 2005 09:08:07 -0400 Subject: Fedora-docs-commits Digest, Vol 2, Issue 46 In-Reply-To: <20050530205250.20DEB72ED2@hormel.redhat.com> References: <20050530205250.20DEB72ED2@hormel.redhat.com> Message-ID: <1117717687.6929.40.camel@localhost.localdomain> On Mon, 2005-05-30 at 16:52 -0400, fedora-docs-commits- request at redhat.com wrote: > ------------------------------ > > Message: 8 > Date: Mon, 30 May 2005 16:01:13 -0400 > From: "Elliot Lee" (sopwith) > Subject: xsl html-common.xsl,1.6,1.7 > To: fedora-docs-commits at redhat.com > Message-ID: <200505302001.j4UK1DkI029288 at cvs-int.fedora.redhat.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Author: sopwith > > Update of /cvs/docs/xsl > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv29280 > > Modified Files: > html-common.xsl > Log Message: > no separate legalnotice for now > > > Index: html-common.xsl > =================================================================== > RCS file: /cvs/docs/xsl/html-common.xsl,v > retrieving revision 1.6 > retrieving revision 1.7 > diff -u -r1.6 -r1.7 > --- html-common.xsl 17 May 2005 15:51:17 -0000 1.6 > +++ html-common.xsl 30 May 2005 20:01:11 -0000 1.7 > @@ -25,7 +25,10 @@ > > > > + > > > text/css > > > > ------------------------------ Is there a reason this changed in the common area and not as some sort of xsl override for the release notes? Sure uglies up the Install Guide.... -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Fri Jun 3 04:36:37 2005 From: kwade at redhat.com (Karsten Wade) Date: Thu, 02 Jun 2005 21:36:37 -0700 Subject: FedoraBounties Message-ID: <1117773397.12368.86.camel@erato.phig.org> I'm considering adding a documentation bounty to the FedoraBounties page [1]. Here are a few ideas: * Something with stylesheets. Problem fixing, new area tackled, making things more usable * Writing a specific document that would be useful to the community * Updating the Developer Guide * Solving some other esoteric, content management problem Technical people as well as tech writers need to know how to write. We can offer a little of both, at all levels. Writers can be beginners and very experienced. What would you like to see? Can we decide upon one that we are willing to write up a spec for and sponser throughout the process? FWIW, I'm working on the PDF toolchain problem. I'll know within a few weeks if I need any programming expertise to complete that project. [1] http://fedoraproject.org/wiki/FedoraBounties - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ghenry at suretecsystems.com Fri Jun 3 10:02:32 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Fri, 3 Jun 2005 11:02:32 +0100 (BST) Subject: FedoraBounties In-Reply-To: <1117773397.12368.86.camel@erato.phig.org> References: <1117773397.12368.86.camel@erato.phig.org> Message-ID: <51850.193.195.148.66.1117792952.squirrel@webmail.suretecsystems.com> > [1] http://fedoraproject.org/wiki/FedoraBounties There's some cool stuff on there. Are they just for the Google stuff or things that need doing in general? > > - Karsten > -- > Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ > gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 > Red Hat SELinux Guide > http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ > -- > fedora-dsco-list mailing list > fedora-dsco-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-dsco-list > From kwade at redhat.com Fri Jun 3 19:34:26 2005 From: kwade at redhat.com (Karsten Wade) Date: Fri, 03 Jun 2005 12:34:26 -0700 Subject: FedoraBounties In-Reply-To: <51850.193.195.148.66.1117792952.squirrel@webmail.suretecsystems.com> References: <1117773397.12368.86.camel@erato.phig.org> <51850.193.195.148.66.1117792952.squirrel@webmail.suretecsystems.com> Message-ID: <1117827266.12368.132.camel@erato.phig.org> On Fri, 2005-06-03 at 11:02 +0100, Gavin Henry wrote: > > [1] http://fedoraproject.org/wiki/FedoraBounties > > There's some cool stuff on there. > > Are they just for the Google stuff or things that need doing in general? AIUI, these predated the Google challenge and is being highlighted by that event. I could be incorrect. If we have good ideas, we can add multiple bounties, if we wish, hoping that one will get picked up. - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Fri Jun 3 22:17:14 2005 From: kwade at redhat.com (Karsten Wade) Date: Fri, 03 Jun 2005 15:17:14 -0700 Subject: minutes/log 31-May-2005 meeting Message-ID: <1117837034.12368.151.camel@erato.phig.org> sorry about the lack of agenda, I'm like a headless chicken <_stickster_> Good with mushrooms and wild rice? exactly yum! --> mariusm (~mariusm at littledude.inetfast.com) has joined #fedora-docs I actually don't want to introduce anything new today because a) we have lots going on already, b) we are really busy with what we have, and c) we're doing such a kick-ass job that I don't want to ruin our record :) <_stickster_> Yeah, especially C ok, so maybe we should start with relnotes status yeah, those things ok, here's a quick agenda then: * relnotes status * install guide status * doc guide thoughts (time coming soon) * tools status AOB Annals of Botany <_stickster_> sounds good to me ? <_stickster_> All Other Business? ah <_stickster_> Aggravating Opal Bunnies? yeah, dict failed me on that one I asked twaugh about printing for the relnotes, and he said there is nothing significant to mention just feeding ben be with you all in a minute no worries ok, relnotes officially went to bed yesterday and that was immediately followed by a bunch of bug reports from notting, warren, et al I will work on those today because they address ugliness I don't want to see published, but I'm being very unpicky about the state of the relnotes. all in all, I'd say the new process worked out great. cool, just wanted to let you know so you knew why I didn't commit anything about printing those who had time to contribute stuff in had an impact and helped make the whole thing much smoother. tcf: cool I plan on doing a fedora-announce about the relnotes in the next few days, highlighting the process and how successful the group effort was, partially to help recruit others. great, CVS access couldn't have come at a better time the best thing about it is that we have everything in nice XML, broken up to be useful for multiple writers, we have a well oiled makefile and the like, and for FC5test1 I expect this to be _much_ easier. <_stickster_> tcf: No kidding in a few weeks I'll bring up the idea of having separate relnotes by arch ... this time we lumped it all together, and I'm curious if that is better or what. seems like it might be easier to read for the end user hi all Hi. yeah, one data point we'll want is how the PPC users found it this time with the PPC stuff inline G2: hello! I personally don't like buying a camera and having to remember my model # while I read the manual (but in this case, hopefully you can remember what arch you are on) Sorry I haven't been much help with the realnotes G2: hi! quaid knows why <_stickster_> I think someone threw in the idea of conditional building to allow separate builds of the HTML/txt _stickster_: yes, we've done it in the past, so I think it is just a matter of should we and we have to switch to profiling from conditionals, aiui ok, we'll table the discussion on the future of the relnotes for a few weks. <_stickster_> k elliss: RHEL4 quaid: OK Better than Debian (I'll stop):) elliss: OT ha <_stickster_> So to sum up, quaid mustered the forces of good and kicked ass on relnotes, right? <-- stickster has quit (Read error: 113 (No route to host)) yes, and if there is anything more I should sneak in, now is the time. on to the IG ... Are they up on the wiki? moving along... no, relnotes not on the wiki yet <_stickster_> Stuart, I yield <_stickster_> Sock it to em big guy! good point though, we can do that for release --- _stickster_ is now known as stickster elliss: how are you feeling about the IG? elliss: did you do all the IG? All the screenshots are in. G2: Most of original draft. Stickster added lots of editing magic quaid taught me everything I know only via osmosis I've said that I won't declare it complete, but it looks shippable cool That's a good summation I think I plan on doing a cover2cover read this week, anyone else might want to as well. I'll take a look tomorrow. Is it a cvs co ? file bugs against the master tracker for the doc, and it's up to elliss and stickster to decide if they need inclusion at this point. G2: yup install-guide module ok. Is it feasible to talk about adding it to the ISOs ? stickster, elliss: unless you *want* us committing changes directly to CVS :D quaid: ACK 8-O Has there been anymore discussion on a fedora-doc.rpm ? elliss: we don't have a documentation RPM of our own, unfortunately. not really elliss: Sopwith said this *would* be possible elliss: Sorry, that was in particular about putting it on the ISO Or was it Jeremy? Someone told me... I think it was Elliot Well, if the files sit next to the README they would be in a good spot. might be better to have a separate RPM per manual elliss: exactly even though we don't have any docs right now, might as well think big ;-) tcf: Right, but source RPM could come right out of the CVS... then build fedora-doc-install-guide, fedora-doc-documentation- guide, etc tcf: Or is that stupid? I'm going to have come in and go out etc., Ben won't settle. G2: no worries G2: lots of parents here, you're in the clear buddy What does RH do for rpms? stickster: Sounds like one SRPM would be OK. If I think of any cons, I'll let you know. elliss: the funny thing being, of course, that once you have the system installed to get to the RPM of the IG ... well, it won't be as useful then, right? I remember stealign tammy's one form RH9 to do one for my company quaid: You're a faster typer quaid: right... it's the other guides that would be more helpful we do separate RPM s per guide and separate SRPMs as well right what would their dependancies be? Firefox? No dependencies, really I made htmlview a dep when I was building them some kind of viewer Build should include .txt it might depend ... we could look at docs to see if they need packaging together (all security, all package m anagement, etc.) yeah. what about a man page format? b/c htmlview just points to whatever the default browser is (just a little script) for the console? or just use lynx etc? This is kind of longer-term - generate an OMF file to add direct into Yelp. That's what links is for :-) or rather, maybe I called htmlview...yeah, sorry it has been a while ;-) elliss: There you go, one-stop shopping I made the menuitem call htmlview so it would use the default browser cool tcf: Right, I remember using that many times... :-) All this and more can be accomplished in the fullness of time... or for FC5, whichever comes first stickster: yes, there is always a chance you don't have htmlview installed, but making it a dep seems wrong elliss: yes, adding to yelp would be nice elliss: Yelp will read XML, aiui quaid: yes, it will quaid: but it was slow at first ah anything more you gents need for the Installation Guide? To go full circle * quaid smiles :) A big fat corporate sponsorship With free booze and broads working on it broadswords? * stickster apologizes to any offended by the term "broads" I was. Can we add alongside README for this release, without considering the RPM (slow typer) hmm Since desktop integration doesn't matter here so much elliss: Let's send an email to whoever spins the ISOs, to ask for the inclusion of a single no-chunk HTML version have to ask Sopwith It insures that users get it you see. quaid: I think Sopwith told me he could make this happen if we had it done by this week Should I confirm with him? yes k also https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156151 that has a Makefile that supports no chunks the XSL is already checked in, but I haven't patched any of the Makefiles yet jlaska had already patched the XSL to do this so you can modify the IG Makefile to use that one, if you wish, and we can then work on it to be more-perfect and distribute the new makefile. tcf: that's the one quaid: cool! quaid: he was hoping his patches would get applied er... "no chunks" ? his patches were nicely waiting for me when I needed them yesterday, OSS at it's finest elliss: one html file instead of multiple html files Aah quaid: yes ;-) multiple files == chunking ok, so stickster will check with sopwith about including a no chunks HTML with the README, that's cool anyone with time to read it this week and offer edits, great and I'll get it ready for f.r.c/docs in time for the release. Let's try and have any changes in by Thursday so I can give Elliot the staight scoop on when we can turn it over ok (I'm writing the "confirm?" email right now) :-) yeah, be prepared for him to say no, just in case Understood not sure how he wants it handled, such as should we check in a built HTML to the release-notes/FC4/? etc. anything else on this? Nope, email just went to Sopwith No. It's done (for this release). (Hurray !) sweet * quaid cheers I guess that means we're on to DocGuide yeah, or we will be on to it next week, so in preparation stickster: you have point on that work, is there anything you want us to be thinking about in advance of that work? Is the Wiki still the place to look ? elliss: for the DG work? The wiki has my most recently thunk thoughts Please feel free to contribute sidebar question then ... is the Wiki working for this stuff? or is it better to use BZ? For jotting quick thoughts I prefer the Wiki... since my process was to start an outline, the Wiki works best I flesh it out over tiem *time ok, just wanting to be sure we haven't enabled too many tools I am not normally a Wiki fan for everything, but for work that you're going to frequently revisit and the changes are not as important as the end state, it works well just building all the docs now brb The biggest view I can give of the Docguide is that the example tutorial will hopefully illustrate (almost) everything in the DocGuide "Learn through doing," in other words yes That's a good way to stay on track or learn through "cutting and pasting" ;-) one issue that we had this last week in collaborating was the differences in environments. tcf: Bingo e.g., I couldn't solve some problems elliss is having with Emacs, and Tommy uses jedit ... all of this is really coding style invisible in the end product. quaid: I might be able to help with the emacs problems if we send me a list You know, I wonder if there is a post-processing tool we could simply place on the CVS commits chain (server level, in other words) that would post-process the files, like "indent" does with C That would help a lot stickster: good point, don't know of any off the top of my head I think the main problem with Emacs and the tools is where we are using different stuff ... such as different versions or updates of FC Yes. E.g. pgsmlx doesn't work for me at all we could also rely upon xmldiff instead of regular diff quaid: Hey, that's a good point quaid: I like that idea I like to see everything in the commit, but maybe editors could be using xmldiff instead makes coding style matter less elliss: psgmlx fails on me sometimes, but in general, it works for me At some point, we have to solve either one of two problems: enforce consistency at the client level, or at the server level agreed we could have a "Coding Style Recommendation" and capture all the best practices that makes collaborating easier,then leave it up to each set of authors I don't think we can do client elliss: exactly Can't stop people running rawhide for ex e.g., I won't support Windows users, but they have to be able to write there if they wish. elliss: Actually, that's something we *have* to enforce yes, you can enforce on the client level within a org or business, but not for a community project In other words, we are documenting the system as is, so the person writing, at some point, has to have a non-rawhide system to test their docs against (follow the steps and see if it works) stickster: true, but that doesn't mean that system is their main workstation stickster: I'd like a standard for testing against, but authoring is separate As for the toolset, though, we could say, you break it, you keep both pieces :-) The toolset should always work on base + updates-released DocBook Wiki creeps in here Keeps it all server-siide yeah, that works for support, we only try to resolve toolchain problems on base + updates and/or rawhide does anyone have ideas on how we could post-process check-ins? It's in the CVSROOT I think quaid: We run test builds for 3 months out of six, so "base" gets confuseded quaid: commitinfo E.g. are you on FC3, FC4 test quaid: nm, I'm st00pid elliss: well, it's in our own interest to solve problems in the toolchain in the current release _and_ the current test but not for e.g. FC2 ok, so this is important stuff to consider for the DG Please, everyone, contribute your thoughts to the bullets on the DocGuide page once FC4 is out the door, we can look at fancy stuff that Sopwith can help with on the server side. http://fedoraproject.org/wiki/DocsProject_2fDocumentationGuide stickster: we can also have an "all DOCG" meeting in a week or two, perhaps after you have enough organized? anything else on the DocG? my install-guide module is empty? hrm quaid: Actually, I will need a little more time than that... I have a big international conference at work that is taking most of my time until June 16 Let's put it a week or two out from that if possible we also covered tool discussions, too stickster: np, you let me know when you are ready, and I'll set it at the top of the agenda for the following meeting. no hurries, no worries :) thx :-) I'm about to have my power cut for a little while we failed city inspection last week for our power setup, the solar guy needs to install another breaker widget. so, last call for meeting content? nothing here nothing here either so, once again, the relnotes were a success regardless of the bugs within them, it is something the entire Documentation Project can feel proud of as a community effort done in the open. I'll be saying the same thing about the IG in a few weeks. last thought ... just noticed that my folder with notes for meetings goes back to mid-April, that means we've only been at this for about 6 weeks. I'm stoked with our progress, everyone on this committee and within the project are engaged and mainly happy. so, don't worry at all about your individual whatevers, you all rock and we couldn't/wouldn't be here without you. Thanks! -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stuart at elsn.org Sat Jun 4 15:34:23 2005 From: stuart at elsn.org (Stuart Ellis) Date: Sat, 04 Jun 2005 16:34:23 +0100 Subject: FedoraBounties In-Reply-To: <1117827266.12368.132.camel@erato.phig.org> References: <1117773397.12368.86.camel@erato.phig.org> <51850.193.195.148.66.1117792952.squirrel@webmail.suretecsystems.com> <1117827266.12368.132.camel@erato.phig.org> Message-ID: <1117899264.4303.44.camel@humboldt.eln.lan> On Fri, 2005-06-03 at 12:34 -0700, Karsten Wade wrote: > On Fri, 2005-06-03 at 11:02 +0100, Gavin Henry wrote: > > > [1] http://fedoraproject.org/wiki/FedoraBounties > > > > There's some cool stuff on there. > > > > Are they just for the Google stuff or things that need doing in general? > > AIUI, these predated the Google challenge and is being highlighted by > that event. I could be incorrect. > > If we have good ideas, we can add multiple bounties, if we wish, hoping > that one will get picked up. If anybody hasn't seen it, one of the existing bounties is for integrating live documentation editing into GNOME (http://www.gnome.org/bounties/Documentation.html). For us, screencasting is something with a lot of potential for documentation/training and advocacy, and this might be a good way of trialling it. We had a small thread about this on the main mailing list fairly recently (https://www.redhat.com/archives/fedora-docs-list/2005- April/msg00282.html and replies), and there was also some discussion of making use of multimedia on the GNOME marketing list. Somebody on one of these lists had some good remarks about producing Windows-friendly formats, but I can't find the post. Off the top of my head: "Screencast Demonstrating Fedora Core Installation Create a screencast that steps through installing Fedora Core with the default options. The screencast should begin with the boot screen, and end with logging in to the completed desktop installation for the first time. The screencast must be produced using Open Source software, but the format must be viewable on a Windows system using either commonly available or pre-installed plug-ins. You may find virtual machine technologies such as Xen and QEMU useful. The Anaconda installation system itself includes support for remote access through VNC and telnet." We could substitute a common desktop task like configuring a dial-up connection for installation, but the Google initiative seems geared toward challenging tasks, and the above allows for quite a wide range of approaches with different technologies. -- Stuart Ellis stuart at elsn.org Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ GPG key ID: 7098ABEA GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Tue Jun 7 19:58:40 2005 From: kwade at redhat.com (Karsten Wade) Date: Tue, 07 Jun 2005 12:58:40 -0700 Subject: Agenda 7 June 2005 meeting Message-ID: <1118174320.12368.235.camel@erato.phig.org> Updates * Release notes really completed * Installation Guide completed, Karsten still editing * DOCG meeting tentative for 27 June New Stuff * Fedora Bounties * Stuart's idea * Others? * Mether is pursuing a kbase idea * AOB -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Tue Jun 7 21:52:23 2005 From: kwade at redhat.com (Karsten Wade) Date: Tue, 07 Jun 2005 14:52:23 -0700 Subject: IRC log 07 June 2005 meeting Message-ID: <1118181143.12368.263.camel@erato.phig.org> For the record: (logged 07 June 2005 from 2100 to 2210 UTC) ## begin perhaps 'docs-common' instead of '-setup' then a docs-common/entities/, d-c/xsl/, etc. quaid: As well, I still like the idea of having each module defined to include the common stuff, saves a step and insures everyone is using the newest stuff... modules file entry reads: "my-tutorial my- tutorial docs-common" stickster: I tend to like that idea, as well we need megacoder's input, and tcf's, so I propose we take this discussion to f-docs-l and table the decision for a week (or for the list consensus, whichever comes first) Right brb ok, anything else on the release notes? not here Everything looks fine Except thanks for the IG plug stickster: as Junior CVS G-Man, would you like to start the thread on f-docs-l that discusses the idea of docs-common? v. docs-setup v. etc. ? * quaid knows to keep stickster's plate clean for a few weeks, but doesn't want to start -all- the important threads himself. np ok then on to IG after this meeting I am finishing my edits, sorry they have taken so long, they are truly minor. 's OK, just happy we got the extra week for it then :-) well, that's partly what happened, I didn't sacrifice this weekend for it :) I guess we should be happy, minor edits means we worked hard enough true no doubt! I'm going to appoint myself Publication Editor (or whatever) for the IG, so that my edit can be the final edit before publication. I would say let's up the and when you commit, unless there's some big beef it should be ready for f.r.c brb (Ben) elliss: any difference of opinion, Stuart? once I am done we can tag the files FC-4, so you can continue development, too Version 1.0 ? sweetr stickster: yes, I have that as a note 1.0! I think we're covered there... make sure URL matches what's in the relnotes and we'll be as golden as FC4 * quaid nods all righty if that's it for the IG for now .... yup yes, let's think about something else :) as noted in agenda, tentative DOCG discussion with this group is 27 June we all need to have reviewed the outline and ideas on the Wiki page by then. Yes, that would be a Monday, right? darn sorry let it be noted I meant 28 June We can fix it in the minutes :-) ;-) I should fix my cal to output with M on the far left, I make this mistake all the time. okay, on to new stuff The outline on the wiki probably needs quite a bit of work... please everyone, feel free to contribute additional ideas, flesh out what's there etc... I will have more time after the 17th but don't want to lose momentum * quaid holds the new stuff for a sec np I was done... sorry, wireless lag stickster: will you make a note to remind all of us to get active on the DOCG after 17 June? :-) ok cool, that will get us a little over a week of thinking closer to the event :) Looking very good: http://fedoraproject.org/wiki/DocsProject/DocumentationGuide I can spend some time on Thurs going through it G2: cool, so noted next? ok, back to moving forward ha first new stuff is the Fedora Bounties Google code I like Stuart's idea of a screencast project to capture installation, that would *rock* Check this out: http://live.gnome.org/Istanbul G2: right, although our only area of influence is the Fedora Bounties :) Posted on Planet GNOME today - video screen capture cool! I definitely want to expand our documentation to include screencasts. Lots of development needed it fits within our mission perfectly. Yup, super sweet what about the vnc flash prog? Gstreamer > VNC ? Thomas used it for Fedoranews or VNC > Flash ? the latter, iirc http://fedoranews.org/casper/vncsnapshot/ --- mrj is now known as mrj_afk anyway right, there is plenty to work with How do this progress as Bounty ? I propose using elliss's wording and adding these links as starting places. then we just add it to the bounty page. OK. elliss: if you want to do that, you should have the access to, and notting gave me permission to add 'something', so I give you the permission to add it :) is the write-up complete enough? OK. I'll e-mail the Istanbul guy first should we run the idea by the f-docs-l first for comments? yes there isn't a whole lot to work from, in terms of how to structure this stuff. I used GNOME bounties as a model --- mrj_afk is now known as mrj http://www.gnome.org/bounties/Documentation.html elliss: will you also email f-docs-l with the suggestion, adding that we (FDSCo) discussed doing a bounty and this is our first idea. OK. elliss: cool, your template is probably better than what we have other places :) The others on the Fedora Wiki are pretty vague IMHO a'yup that was exactly what I was thinking of :) btw, IMHO we can post more than one bounty, to increase the chance of takers. so it will be good if new ideas come up on list, although we want to choose probably no more than three. Did anybody eval DocBook Wiki ? I think the screencast idea is a shoe-in for one, especially if it provides us with a screencasting toolchain :) yeah I think megacoder installed it, or tried to, but that is the last I can recall. elliss: that's a good point, we need to undrop that ball. my major concern is infrastructure elliss: Does this have something to do with Bounties? Sopwith: there is this really great tool that uses a Wiki front- end for DocBook, and we need to talk with someone about hosting. That might be another bounty...somebody on GNOME docs has said they'll do it as the GNOME bounty on the link I gave before Live doc editing ah ah good idea The GNOME spec is vague So that would be used up to a certain point, then the resulting doc spun into CVS? quaid: We have machines for fedora.redhat.com that may be able to host it. elliss: include that idea, either in your email or in a separate thread to keep track if the ideas more easily. stickster: it uses CVS on the back side, iirc Yes PDF toolchain as the third ? Sopwith: who is the best person to start an infrastructure discussionw ith? There's an aspect to this that still makes me a bit uncomfortable, which is the changeability of the doc thru a Wiki elliss: no on the PDF toolchain, Ithink quaid: Me ok, cool stickster: tighter ACLs? OK. Something in the works ? elliss: I'm working on the PDF issue internally, and hope to use the same solution for FDP. OK. Cool. actually, I have this toolchain stuff for a point of other business at the end :) ok, any other bounty discussion can move to the list quaid: Dunno, but I think the idea about the subtlety of language not being the same as subtlety in code enters into my thinking here... probably best discussed offline I mean "offline" == "on f-docs-l" right Sopwith: ok, when we get someone ID'd to work on the fancy Wiki stuff, I'll connect back with you. Cool ok, moving just a note that mether_gone is pursuing a kbase idea using http://sf.net/projects/klear noted. Superb. I approved it this morning as being worth pursing, and the developer of klear is a Red Hat support person, so it's good ol' NIH in action :) I've been wondering how to mobilise all the new people it's a growing part of the RH support documentation, and I don't want to miss the boat with FDP either ... it might be a good solution to some of the FAQ needs. Anybody have a URL to that? Duh... nm :D Laugh while you can, monkey boy elliss: mobilize as kbase authors? Yes stickster: I know, Alzheimers is only a day away (sung to the tune of "Tomorrow") elliss: true Means no dependency on new Doc Guide work DB_DataObject Error: DB Error: connect failed nice klear website klear? oops Or DocBook know-how http://klear.kavefish.net/ Whoopsie :-) Also, less commitment req'd than writing a whole doc yeah, it's not fully ready for primetime ... chicken-egg problem elliss: yes and yes So I'm very interested in this... OK, so are we up to AOB then? elliss: do you want to be connected in with mether_gone and the developer (who is lurking here right now) and all our discussions on this? AOB! all other business I have one, are there others? Sure Alzheimer's Opportunists Beware me too Dyslexics Untie! * quaid unties quaid: You frist roger dodger ha! * quaid is certainly *not* Frist "My legal opinion after watching this episode of Judge Judy is that they should have executed the plaintiff." anyway mrj is working on toolchain concerns inside of Red Hat and we are pursuing the same path that the standard DocBook developers are using, trying to do it with a free software stack all java-based, fwiw i.e., Saxon as an XSL processor instead of xsltproc yeah, so the gcj work plays in, etc. Xerces & FOP + (XML Catalog) resolver classes and as before, I have pledged to twist Java developer arms if we need someone to package something for FC or FE. so I am working on an XSL for PDF output that will work under that toolchain, and hope to carry that fix over to Fedora Documentation. i've got the toolchain working already, but under Sun's jvm we are kind of working on this in reverse, in that our internal need and deadlines are primary and RIGHT NOW, so we don't have time to vet with the community, and may not be able to keep these aligned. * quaid crosses his fingers that we can so I wanted to make FDSCo aware of this status, and solicit input. We can discuss onlist of anyone has long thoughts, etc. Doesn't the use of Java for this imply a fairly huge extra footprint (in aggregate additional package space) for people who want to use our tools? Sorry, I am a Java idiot, and couldn't tell you anything about it that doesn't have to do with grinding beans it might, although I don't know how much footprint. I'm thinking back to the last FC4t3 install I di *did it seems to me it would behoove us to align the FDP toolchain with the upstream DocBook toolchain, if possible, instead of having a parallel method. the problem has been the JVM, and that is what gcj should fix. true, Sun/Ibm's jvms are ~50 MB-ish, gcj not a problem... if we can get it to work under gcj. How do other distro create pdf etc.? ok that's the kicker-get it to work under gcj how does debian create pdf? G2: GNOME pdf creation is also busted I don't think I've seen other distros use PDF stickster: go ahead and start your AOB item debian uses fop or the dsssl toolchain (jade, etc.) mrj: I make PDFs all the time in OO.o, etc.... ah pdf production is a big & widely recognized problem - hence the redesign plans for FOP It used to work on RH7.3 ;-) tie up on this, we'll bring our stuff to the table Real Soon Now Is there a GNOME-centric engine that I'm not using which is busted? ok fine stickster: those are PostScript outputs, from OOo and ps2pdf of some kind used. Ah stickster: we're talking XML -> PDF, right? mrj: apparently not :-D sorry OOo is deceptive because they use XML file format, but don't do a direct conversion (AIUI) quaid: I gotcha they programattically produce a PS, etc. ok, stickster, go ahead 2 AOB: right. we want docbook -> pdf yes, want want linked chapters etc. quaid: sorry to miss the meeting! I got pulled into a crucial project that had to be finished today #1. XML "cleaning" s/want/we/ #2. RHM deadline tcf: no worries, minutes are being written as we go and will go to the list ASAP, should help :) quaid: great, thanks hi tcf tcf: major point for you is watch the list and participate in discussions of 'docs-common' module that Paul will start. * quaid is OK to keep on meeting, if anyone needs to go that's OK too tcf: Plus this bit right here... :-) yeah, just in time for this stuff :) #1... I am looking into XML "cleaning" programs which we should be able to implement on the CVS server, so that XML files are indented and aligned by a server-side process before commit This should help eliminate (hopefully) some of the pain being caused by people on other toolsets Diffs will hopefully become more sane also I'm off. Speak to you on the list. Night all. Two candidates right now are xmlformat and tidy G2: g'night stickster: it must ignore , , and CDATA containers (at least), and probably as well. quaid: xmlformat does that, and I think tidy *might* be trainable to do the same... still looking ok OK, so that's the status: I'm looking at them and trying to suss out weak points for each where they exist Ready for #2? cool, go ahead with #2 sorry guys, gotta go pick up the baby--it is about to storm like crazy here #2: RHM "deadline" is pretty much the 8th tcf: take off, we'll get you in loop later tcf: bye, drive carefully! Colin asked me for, "Could I get a quote/comment about the newly formed FDSCO for an article > I'm writing? Goals, aims, how you're enjoying the job as lead, etc." which I am working on oh sweet, under control then... that was it :-) oh, cool You da man yeah, he's in SF this week I'm trying to see if I have time to drive up for dinner tomorrow ? gregdek? drbyte! oh, sorry missed that one stickster: thanks! bye damn wireless <-- tcf has quit ("Leaving") nah, greg's cool and i'll drive to see him too, but Colin is more of a once-in-a-while opportunity I just saw greg last week and will again this coming week :D s/last/last last/ I'm done then cool did you all catch about the Fedora Marketing Project? anything else? * quaid leaves it open until :10 after what about the FMP? just that it was forming and Colin (note: not a Red Hatter) is the chair of the steering committee? -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Tue Jun 14 20:00:57 2005 From: kwade at redhat.com (Karsten Wade) Date: Tue, 14 Jun 2005 13:00:57 -0700 Subject: Agenda 14 June 2005 meeting Message-ID: <1118779257.15227.27.camel@erato.phig.org> * Karsten reports back from an FC4 post release discussion * Relnotes kudos * IG kudos * CVS status, if anything (Tommy) * ??? * AOB -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Tue Jun 21 19:00:29 2005 From: kwade at redhat.com (Karsten Wade) Date: Tue, 21 Jun 2005 12:00:29 -0700 Subject: staging server draft for discussion Message-ID: <1119380429.22136.69.camel@erato.phig.org> # This is my first brain dump of what a staging server should do for # FDP Fedora Documentation Staging Server (codename: alexandria) The purpose of alexandria is to provide a consistent build environment. The latest code is pulled from CVS continously and is on a rolling autobuild. This eliminates local differences in environment and toolchain. A writer can work locally with whatever envar they prefer, but the final documentation is always pulled from alexandria. Writers who cannot have a local toolchain may use the autobuild as a remote build machine. Writers then edit and check-in, using the autobuild page to view the newly built document or check the error log. This provides a single location that all beta documentation can be viewed, for people inside and outside of the project. ## 30 ## -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Tue Jun 21 19:15:30 2005 From: kwade at redhat.com (Karsten Wade) Date: Tue, 21 Jun 2005 12:15:30 -0700 Subject: Agenda 21 June 2005 Message-ID: <1119381330.22136.77.camel@erato.phig.org> Happy Summer. Here is our agenda for today. * Things getting busy, how to handle it. * Bug reports on relnotes * Translation * Need an active task list ... * Toolchain * FOP is focus * xmlroff and Saxon ... * Discuss staging area write up * See f-dsco-l for today * XML fun * Seen xmlformat being used internally with good results * Paul to escalate the legal questions to the Wiki? * CVS discussion * What's new Enough for now? -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ghenry at suretecsystems.com Tue Jun 28 18:25:11 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Tue, 28 Jun 2005 19:25:11 +0100 (BST) Subject: On for tonight? Message-ID: <54093.192.168.100.90.1119983111.squirrel@webmail.suretecsystems.com> -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From stickster at gmail.com Tue Jun 28 18:33:36 2005 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 28 Jun 2005 14:33:36 -0400 Subject: On for tonight? In-Reply-To: <54093.192.168.100.90.1119983111.squirrel@webmail.suretecsystems.com> References: <54093.192.168.100.90.1119983111.squirrel@webmail.suretecsystems.com> Message-ID: <1119983616.2906.13.camel@localhost.localdomain> As far as I know. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Thu Jun 30 21:38:55 2005 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 30 Jun 2005 17:38:55 -0400 Subject: IRC log, 17 May 2005 Message-ID: <1120167535.3324.6.camel@localhost.localdomain> This is the first in a series of emails to document old meetings and make sure the wiki references have antecedents. :-) = = = = = so, yeah, considering the time-to-release for FC4, that should be most of our time today in discussing anything related to that to start about the release notes: 1. I haven't done any PR this last week, things are the same as they were ... small team. 2. As many of us as can help in anyway, please do, that will define what quality and quantity we can do in this time frame 3. This will all be better for FC5test1 :) 4. I did this to help in collaboration: 4.1 created bz account for relnotes at fedoraproject.org ... you all can watch that email address (bz.r.c -> account > email and watch that email addy) 4.2 this addy will go right to a pre-filled bz ticket for filling in any release notes http://tinyurl.com/73qe when a ticket is filled out, relnotes@ gets notice, that comes to me (as the so-far single person on that list), and anyone watching it sees it to. quaid: what do you mean by clean up, do you mean HTML or editing? the tickets are set to block a single master tracker bug, and the dependency tree shows all open bugs, so we don't lose stuff and have somewhere to discuss with developers tcf: clean up? quaid: you asked me about http://people.redhat.com/sundaram/fedora_notes.html right before you opened the meeting quaid: feel free to table that until later yeah, let' np, sorry to interrupt ;-) let's table it for a minute, it's related but not as high a priority 5. next me (and Sopwith and others) will start bugging all Fedora developers to use that tinyurl to fill out anything they want included. 6. I will keep a latest version of the relnotes at f.r.c/docs/beta for reference 7. I will get the relnotes module in CVS right after this meeting. so ... if anyone can help, you want to take one or more relnotes beats and watch the bug traffic for something that lands in that purview. <-- ideal alt is to do it as ASCII files and I will meld them together at the final. just so we don't have to learn the special DocBook tags that create HTML that Anaconda can render. What's the deadline for the relnotes again? comments? 30 May at the latest quaid: re: RelNotes, were you already aware of the "non-optimal" HTML rendering in the FC4t3 release in Firefox, or does that matter given Rahul's effort to make a more generic PR page? so, 29 May to give me a day to clean up Remember May 30 is memorial day Monday Suggestion: could you file a sample XML file in the CVS module ? stickster: I was not aware, did it suck? ugly fixed-font stickster: and that is hard to say, depends on our efforts to get mether's changes included ah no biggie I can BZ it elliss: we might have to, but I didn't want to give us another hurdle. It was really for the benefit of dull people like me well, it's the right way, let's try it out the only thing is if it makes broken HTML that doesn't render, we don't have a test left to fool around on. so I may still docbook2txt and put that in instead, if we have to. stickster: don't bother with the bz, I'll close it WONTFIX :) :-) k i.e., the objective is to move beyond the text the fact is, we may get super low input in the next week meaning that taking on some of the relnotes beats could be zero to little work. Sopwith: what are the chances that we can get mether's new Firefox default page in for FC4? the idea is to have a Fedorafied version ASAP, if possible. quaid: The default page has historically been the relnotes. We can definitely make the default page be anything you want. I dunno if you want to make mether's page be the intro to the relnotes, or have two separate pages linked to each other, or what. Sopwith: this all came from a discussion on f-devel-l no, just to have a "friendlier" portal page with some marketing foo about how awesome the release is, then links to valuable info locally and out-there Including the FDP ;-) yep :) Sopwith: but I see what you are saying ... I could effect the change by putting mether's page in to start the relnotes, instead of forcing the firefox package to change. oh, we wouldn't change the firefox package for sure. well, how is that default page set? Actually, it woudl be the indexhtml package I think... or is that no longer true? stickster: That's now part of the fedora-release package Sopwith: ah, right ok, so that one is easier to change? quaid: We'd change the contents of the default page without changing the URL of the default page. Right now we create the default index.html file by HTMLifying the relnotes. It can be whatever you want :0 yeah but ... then Anaconda would show that page in the sidebar, right? I believe) Is the fedora-release package built out of the /cvs/fedora module? yes, from the fedora-release module. That was my only question, hope no one's waiting for a follow-up... :-) Anyways, sorry to have distracted from the meeting - main idea I guess is that the fedora_notes page and the relnotes can be related however you want, but I would like it so that people can somehow get to the relnotes from the default index.html right http://people.redhat.com/sundaram/fedora_notes.html Technical Notes -> Release Notes? so its linked right there. or something like that, methinks cool maybe rename it to "detailed release notes" so people looking for the old relnotes won't get lost. ok so the main question on the table is, what release notes beat do each of you want to cover for this release? or would you prefer me to assign them? or are you all telling me to piss off and do it myself? :) let me look at the latest version first quaid: What is lacking content and how far are each along. Sorry if I have missed that, bu tI have Ben on my lap again ;-) G2: to be honest, not entirely sure, but ... ok, here is a best-status: If you really need me to do one, I'll take server config tools... but I'm a weak girlie-man so I need to devote my limited energy to IG for right now A, It's fairly sparse right now B. It covers some vital items, but I'm sure it covers all C. I'm afraid of a last-minute deluge .me wonders what stickster looks like, a girl maybe ;-) oh B. It covers some vital items, but I'm *not* sure it covers all it should got it :-) A last minute deluge can be dealt with by setting the submission deadline early enough for last-minute submissions to be processed. stickster: you already begged off last week, I remember that :) a/k/a "The Scotty Principle" quaid: maybe the better question is "where do you need the most help?" quaid: Are we still following the "release notes beats" e-mail order? are there missing sections you would like someone to try and wrangle up? tcf: yes. to your first question G2: ues yes elliss: your suggestions were good for rearranging the beats OK. quaid: Which ones do you really want. (can't answer none). tcf: I have zero handle on any of the beats ok, so let's go through each section and talk about them tcf: yes, Kernel first Is http://www.fedoraproject.org/wiki/FedoraDocs_2fReleaseNotes_2fCore4Test1 the latest version? G2: I already have Security http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Beats ok about that http://www.fedoraproject.org/wiki/FedoraDocs_2fReleaseNotes_2fCore4Test1 it's dead ok? ok, thanks, that page didn't look right fine. kernel--do we have any info on it? can we put "dead" on that page later yeah, if I can figure out how there are a metric ton of release notes wiki stuff out there all of which should be marked as dead anyway tcf: what do you mean "info in it"? as in, what needs to go in the release notes? the answer is no for _all_ beats unless we have personal knowledge like I do for SELinux stickster: Do you just need that dead page removed, or what? quaid: I mean do we have any info in the current relnotes about the kernel or a kernel developer contact quaid: Do you just need that dead page removed, or what? (Sorry) tcf: yes, there are some, and there is not a trict developer contact s/trict/specific/ stickster: Ronny Buchmann parsed the relnotes into bunch of pages that all #include together somehow, all done under an incorrect namespace. quaid: ah so, yeah, maybe they do need to be vaped we can worry about that later k right, I see bits of kernel info dispersed through the notes doesn't look like anyone wants to be responsible for the kernel stuff ;-) I was going to volunteer for printing when we got to it oh, cool I forgot that there is a module release-notes want me to add my name next to it on the wiki page? tcf: please :) I can easily talk to Tim Waugh about it this week Development tools is a huge one! yeah, many of these just need a contact with some developer(s) and a blessing of something or knowledge there is nothing to note. G2: yeah ... the beats are subject to change, and a group can work on them I am going to pound on the developers to use the tinyurl ... quaid: might be able to get some info about development tools from wcohen quaid: at least the gcc and oprofile stuff quaid: and kprobes but I don't have a contact for the rest of the devel tools jakub is the best person for most of the tools (e.g. gcc glibc) how indepth does it need to be, just package changes etc? first priority is "gotchas" anything that is a surprise and might matter to more than a few corner cases second priority is "new features" third is "fixed stuff" IMO probably the standard stuff--major changes such as new default gcc flags Plus, you can see old x86 release notes on the f.r.c web site under Docs -> Release Notes for guidance any new gcc compile options... yeah okay, Developer Point of Contact column is added excellent and Jakub is in there for devel tools I haven't been following f-d-list have we already tried to ask for additions like ed used to? ed used to get lots of info via bugzilla during the tests, yes tcf: That's one of the things that still needs to happen for FC4final I am about to send a big note to f-devel- and internal devel list in the past, most developers have waiting until the last minute right, back to my deluge :) fwiw ok, so we are trying to be proactive ;-) gotcha *wink* ok, so, you all can see the test notes from CVS and the Beats page megacoder is auditing the meeting and will be back later, I'll ask him then I just added the changes elliss suggested we have 6 mins left btw elliss: can you take one or more beats, just for this release g2: can you take one or more beats, just for this release OK. I'm sending out emails today, btw so hopefully we get some action How can we fill in developer contacts for the other bits ? elliss: samba? daemons? OK, I'll do my best. Just assign me one please. I can't pick Any, really. Sopwith can likely provide guidance Do both and earn the unending gratitude of quaid <-- ignacio has quit (Read error: 104 (Connection reset by peer)) ok, I'm going to do this If you are working on a section and need a contact, please e-mail me (sopwith at redhat.com) and I'll do my best to put you in touch right away. Thanks. Cheers Sopwith I'm going to clean up that page and fill in some of us I'll send email when I'm done if you can't do what I put you under, let me know no worries, this isn't that big of a thing I just want to do a better job than I've been doing solo yep ok, anything else? cool -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Thu Jun 30 21:43:29 2005 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 30 Jun 2005 17:43:29 -0400 Subject: IRC log, 7 Jun 2005 Message-ID: <1120167810.3324.9.camel@localhost.localdomain> hi everyone :) Hi quaid megacoder is auditing the meeting today, fyi today I'm trying a new thing of taking actual minutes during the meeting, we'll see how it goes hi G2 (just starting) ok, we have a quorum Let's do it my final word this release on the release notes: they are really done now, and I'm going to hand them off for translation and hope that Sopwith does a final respin nope FC4 is gold shucks from 6/6? Yea. The relnotes I have are from sometime last week hi oh well no showstopper fixes I know of 's OK quaid, don't let the perfect be the enemy of the good Thanks everyone for doing these release notes - they are very well done even considering the few bugs. Sopwith: we want to tag where the branch was for the record, then we can have at f.r.c/docs/release-notes/ the actual release notes and an updated (errata) notes, for each release I think I tagged it already FC-4 tag I have that as an action, to create that webpage Sopwith: ok, that was a tree wide tag, right? so we wouldn't have seen a commit to f-docs-commits? quaid: Right, tagging operations don't send e-mail. oh, right One thing I'd like to ask for is permission to change the docs-setup module so everything checks out in a 'docs-setup' subdirectory - this prevents my toplevel cvs checkout dir from being cluttered and makes it easier to find the docs-setup stuff. hmmm Sopwith: What's "everything"? stuff won't build, iirc it relies upon relative path names xsl/, common/ etc. quaid: We can fix that stuff - I made it possible in release-notes/FC4/Makefile as part of earlier changes. stickster: common css stylesheet-images xsl README Sopwith: gotcha Sopwith: it's in all the parent XML files, too they call to ../common/ however it may not be that huge of a change, now is the time to make it instead of after we have 4x as many docs modules <-- ignacio|NotHere has quit (Read error: 110 (Connection timed out)) tcf: did you have a reason for separate directories in FC, as opposed to in RHEL where everything -is- in docs-setup/ ? I think this may be why FE uses &common_stuff in their modules flie *file instead we could have a single module that contains all the sub-folders perhaps 'docs-common' instead of '-setup' then a docs-common/entities/, d-c/xsl/, etc. quaid: As well, I still like the idea of having each module defined to include the common stuff, saves a step and insures everyone is using the newest stuff... modules file entry reads: "my-tutorial my-tutorial docs-common" stickster: I tend to like that idea, as well we need megacoder's input, and tcf's, so I propose we take this discussion to f-docs-l and table the decision for a week (or for the list consensus, whichever comes first) Right brb ok, anything else on the release notes? not here Everything looks fine Except thanks for the IG plug stickster: as Junior CVS G-Man, would you like to start the thread on f-docs-l that discusses the idea of docs-common? v. docs-setup v. etc. ? np ok then on to IG after this meeting I am finishing my edits, sorry they have taken so long, they are truly minor. 's OK, just happy we got the extra week for it then :-) well, that's partly what happened, I didn't sacrifice this weekend for it :) I guess we should be happy, minor edits means we worked hard enough true no doubt! and when you commit, unless there's some big beef it should be ready for f.r.c I'm going to appoint myself Publication Editor (or whatever) for the IG, so that my edit can be the final edit before publication. brb (Ben) elliss: any difference of opinion, Stuart? once I am done we can tag the files FC-4, so you can continue development, too Version 1.0 ? sweetr stickster: yes, I have that as a note 1.0! I think we're covered there... make sure URL matches what's in the relnotes and we'll be as golden as FC4 all righty if that's it for the IG for now .... yup yes, let's think about something else :) as noted in agenda, tentative DOCG discussion with this group is 27 June we all need to have reviewed the outline and ideas on the Wiki page by then. Yes, that would be a Monday, right? darn sorry let it be noted I meant 28 June We can fix it in the minutes :-) ;-) I should fix my cal to output with M on the far left, I make this mistake all the time. The outline on the wiki probably needs quite a bit of work... please everyone, feel free to contribute additional ideas, flesh out what's there etc... I will have more time after the 17th but don't want to lose momentum okay, on to new stuff np I was done... sorry, wireless lag stickster: will you make a note to remind all of us to get active on the DOCG after 17 June? :-) ok cool, that will get us a little over a week of thinking closer to the event :) Looking very good: http://fedoraproject.org/wiki/DocsProject/DocumentationGuide I can spend some time on Thurs going through it G2: cool, so noted next? ok, back to moving forward ha first new stuff is the Fedora Bounties Google code I like Stuart's idea of a screencast project to capture installation, that would *rock* Check this out: http://live.gnome.org/Istanbul G2: right, although our only area of influence is the Fedora Bounties :) Posted on Planet GNOME today - video screen capture cool! I definitely want to expand our documentation to include screencasts. Lots of development needed it fits within our mission perfectly. Yup, super sweet what about the vnc flash prog? Gstreamer > VNC ? Thomas used it for Fedoranews or VNC > Flash ? the latter, iirc http://fedoranews.org/casper/vncsnapshot/ anyway right, there is plenty to work with How do this progress as Bounty ? I propose using elliss's wording and adding these links as starting places. then we just add it to the bounty page. OK. elliss: if you want to do that, you should have the access to, and notting gave me permission to add 'something', so I give you the permission to add it :) OK. I'll e-mail the Istanbul guy first is the write-up complete enough? should we run the idea by the f-docs-l first for comments? yes there isn't a whole lot to work from, in terms of how to structure this stuff. I used GNOME bounties as a model http://www.gnome.org/bounties/Documentation.html elliss: will you also email f-docs-l with the suggestion, adding that we (FDSCo) discussed doing a bounty and this is our first idea. OK. elliss: cool, your template is probably better than what we have other places :) The others on the Fedora Wiki are pretty vague IMHO a'yup that was exactly what I was thinking of :) btw, IMHO we can post more than one bounty, to increase the chance of takers. so it will be good if new ideas come up on list, although we want to choose probably no more than three. Did anybody eval DocBook Wiki ? I think the screencast idea is a shoe-in for one, especially if it provides us with a screencasting toolchain :) yeah I think megacoder installed it, or tried to, but that is the last I can recall. elliss: that's a good point, we need to undrop that ball. my major concern is infrastructure elliss: Does this have something to do with Bounties? Sopwith: there is this really great tool that uses a Wiki front-end for DocBook, and we need to talk with someone about hosting. That might be another bounty...somebody on GNOME docs has said they'll do it as the GNOME bounty on the link I gave before Live doc editing ah ah good idea The GNOME spec is vague So that would be used up to a certain point, then the resulting doc spun into CVS? quaid: We have machines for fedora.redhat.com that may be able to host it. elliss: include that idea, either in your email or in a separate thread to keep track if the ideas more easily. stickster: it uses CVS on the back side, iirc Yes PDF toolchain as the third ? Sopwith: who is the best person to start an infrastructure discussionw ith? There's an aspect to this that still makes me a bit uncomfortable, which is the changeability of the doc thru a Wiki elliss: no on the PDF toolchain, Ithink quaid: Me ok, cool stickster: tighter ACLs? OK. Something in the works ? elliss: I'm working on the PDF issue internally, and hope to use the same solution for FDP. OK. Cool. actually, I have this toolchain stuff for a point of other business at the end :) ok, any other bounty discussion can move to the list quaid: Dunno, but I think the idea about the subtlety of language not being the same as subtlety in code enters into my thinking here... probably best discussed offline I mean "offline" == "on f-docs-l" right Sopwith: ok, when we get someone ID'd to work on the fancy Wiki stuff, I'll connect back with you. Cool ok, moving just a note that mether_gone is pursuing a kbase idea using http://sf.net/projects/klear noted. Superb. I approved it this morning as being worth pursing, and the developer of klear is a Red Hat support person, so it's good ol' NIH in action :) I've been wondering how to mobilise all the new people it's a growing part of the RH support documentation, and I don't want to miss the boat with FDP either ... it might be a good solution to some of the FAQ needs. Anybody have a URL to that? Duh... nm :D Laugh while you can, monkey boy elliss: mobilize as kbase authors? Yes stickster: I know, Alzheimers is only a day away (sung to the tune of "Tomorrow") elliss: true Means no dependency on new Doc Guide work DB_DataObject Error: DB Error: connect failed nice klear website klear? oops Or DocBook know-how http://klear.kavefish.net/ Whoopsie :-) Also, less commitment req'd than writing a whole doc yeah, it's not fully ready for primetime ... chicken-egg problem elliss: yes and yes So I'm very interested in this... OK, so are we up to AOB then? elliss: do you want to be connected in with mether_gone and the developer (who is lurking here right now) and all our discussions on this? AOB! all other business I have one, are there others? Sure Alzheimer's Opportunists Beware me too Dyslexics Untie! quaid: You frist roger dodger ha! "My legal opinion after watching this episode of Judge Judy is that they should have executed the plaintiff." anyway mrj is working on toolchain concerns inside of Red Hat and we are pursuing the same path that the standard DocBook developers are using, trying to do it with a free software stack all java-based, fwiw i.e., Saxon as an XSL processor instead of xsltproc yeah, so the gcj work plays in, etc. Xerces & FOP + (XML Catalog) resolver classes and as before, I have pledged to twist Java developer arms if we need someone to package something for FC or FE. so I am working on an XSL for PDF output that will work under that toolchain, and hope to carry that fix over to Fedora Documentation. i've got the toolchain working already, but under Sun's jvm we are kind of working on this in reverse, in that our internal need and deadlines are primary and RIGHT NOW, so we don't have time to vet with the community, and may not be able to keep these aligned. so I wanted to make FDSCo aware of this status, and solicit input. We can discuss onlist of anyone has long thoughts, etc. Doesn't the use of Java for this imply a fairly huge extra footprint (in aggregate additional package space) for people who want to use our tools? Sorry, I am a Java idiot, and couldn't tell you anything about it that doesn't have to do with grinding beans it might, although I don't know how much footprint. I'm thinking back to the last FC4t3 install I di *did it seems to me it would behoove us to align the FDP toolchain with the upstream DocBook toolchain, if possible, instead of having a parallel method. the problem has been the JVM, and that is what gcj should fix. true, Sun/Ibm's jvms are ~50 MB-ish, gcj not a problem... if we can get it to work under gcj. How do other distro create pdf etc.? ok that's the kicker-get it to work under gcj how does debian create pdf? G2: GNOME pdf creation is also busted I don't think I've seen other distros use PDF stickster: go ahead and start your AOB item debian uses fop or the dsssl toolchain (jade, etc.) mrj: I make PDFs all the time in OO.o, etc.... ah pdf production is a big & widely recognized problem - hence the redesign plans for FOP It used to work on RH7.3 ;-) tie up on this, we'll bring our stuff to the table Real Soon Now Is there a GNOME-centric engine that I'm not using which is busted? ok fine stickster: those are PostScript outputs, from OOo and ps2pdf of some kind used. Ah stickster: we're talking XML -> PDF, right? mrj: apparently not :-D sorry OOo is deceptive because they use XML file format, but don't do a direct conversion (AIUI) quaid: I gotcha they programattically produce a PS, etc. ok, stickster, go ahead 2 AOB: right. we want docbook -> pdf yes, want want linked chapters etc. quaid: sorry to miss the meeting! I got pulled into a crucial project that had to be finished today #1. XML "cleaning" s/want/we/ #2. RHM deadline tcf: no worries, minutes are being written as we go and will go to the list ASAP, should help :) quaid: great, thanks hi tcf tcf: major point for you is watch the list and participate in discussions of 'docs-common' module that Paul will start. tcf: Plus this bit right here... :-) #1... I am looking into XML "cleaning" programs which we should be able to implement on the CVS server, so that XML files are indented and aligned by a server-side process before commit yeah, just in time for this stuff :) This should help eliminate (hopefully) some of the pain being caused by people on other toolsets Diffs will hopefully become more sane also I'm off. Speak to you on the list. Night all. Two candidates right now are xmlformat and tidy G2: g'night as well. quaid: xmlformat does that, and I think tidy *might* be trainable to do the same... still looking ok OK, so that's the status: I'm looking at them and trying to suss out weak points for each where they exist Ready for #2? cool, go ahead with #2 sorry guys, gotta go pick up the baby--it is about to storm like crazy here #2: RHM "deadline" is pretty much the 8th tcf: take off, we'll get you in loop later tcf: bye, drive carefully! Colin asked me for, "Could I get a quote/comment about the newly formed FDSCO for an article > I'm writing? Goals, aims, how you're enjoying the job as lead, etc." which I am working on oh sweet, under control then... that was it :-) oh, cool You da man yeah, he's in SF this week I'm trying to see if I have time to drive up for dinner tomorrow ? gregdek? drbyte! oh, sorry missed that one stickster: thanks! bye damn wireless <-- tcf has quit ("Leaving") nah, greg's cool and i'll drive to see him too, but Colin is more of a once-in-a-while opportunity I just saw greg last week and will again this coming week :D I'm done then s/last/last last/ cool did you all catch about the Fedora Marketing Project? anything else? what about the FMP? just that it was forming and Colin (note: not a Red Hatter) is the chair of the steering committee? just in time to grok and explain the FF to us all :) FF? Oh Fedora Foundation Fantastic Four! Lucky Colin :-D Flame on! quaid: I guess nothing else then -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Thu Jun 30 21:46:31 2005 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 30 Jun 2005 17:46:31 -0400 Subject: IRC log, 21 Jun 2005 Message-ID: <1120167991.3324.11.camel@localhost.localdomain> Please excuse the last post (7 Jun 2005), since it is a repeat. = = = = = I'm here! hiiiiiiidey-ho! look, mrj, toolchain and XML on the agenda :) how was everyone's Solstice? even-tempered Just happy I can justify putting the kids to bed *earlier* in a couple months All righty, let's hit it then :-) I put busy-ness at the top of the agenda just to open the discussion door see if we can spark some ideas to spin off and work on. the problem, I think, is that too much work still is in our hands, so when the relnotes@ address heats up, we are effected. A lot of the reports seemed to be other bugs It was kind of a surge with the FC4 release, but not much in the last 24 hrs... still, would be good if we had more hands :-) elliss: right you are A "how to report bugs" page ? yeah, it's the vagaries of getting more attention, you get more email about rnd crap elliss: Not a bad idea... a "How to Bugzilla" tutorial I think I scribbled something about this on the ever-growing Doc Guide wish list Fantastic ? Somebody has to write all this stuff though :) that you scribbled in the right place :-) elliss: Patience, grasshopper, DocG meeting still on the horizon OK - specific idea put the link at the bottom of a checklist So they don't see it till they've hopefully read all the other options ok, that's a good idea Checklists with very short bullets garner more eyeball time :-) We could put an interim page on the also ever-growing Wiki, if it's an immediate issue elliss: can you (ironically) use the pre-filled bugzilla and file that as a suggestion against the relnotes? well, I think this is all part of the lack of active task list. Sure (with no irony). this committee has tasks that we track, but we need some project task mastering can we do this collaboratively via the Wiki? http://fedoraproject.org/wiki/DocsProject/FedoraDocsSchedule That's the issue - Tommy put the page in place, but for some reason we haven't used it I did, but very little is in it Whaddya mean "we" paleface? :D should I transfer our tasks from the minutes to that page after every meeting? I prefer BZ since it makes it easier to see dependency trees without me having to spend time formatting text I added my stuff to the page ;-) quaid: superb idea I agree, adding to it after the meeting is a good idea stickster: I agree, yet without a visible list all can see it's hard to delegate :) I like it b/c it gives me a task list bugzilla contains more than my fedora stuff ;-) I'm not fond of Bugzilla because the comments just get longer quaid: good point until you have a really long list elliss: one bug per task, blocking one or more master tracker bugs Wikis are nice whiteboards, IMO It would be awesome if one could web-share projects using Imendio Planner :-D :) well, unless it's really cool That's probably the best answer I don't use project management tools much, so I don't know how useful they are... many people in our contractor shop swear by the stuff oh, definitely, if you have many dependencies especially. We currently have Bugzilla or Wiki, or managing TODO files in CVS (yuk) essential for heavy dependency stuff like building bridges or software. Actually .ics files as well, for time-based stuff - for those that do Evolution hey, G2, we're discussing how to handle our task list(s) Ugh, Planner still apparently too early in development to demand much... ignore that chatter :-) for now, we can try this: 1. Whiteboard projects on Wiki Hi, sorry. Just got Ben to sleep. 2. Convert each task into a bug report My time will be freeing up over the next two weeks too!! At last. 3. Make one or more master tracker bugs brb 4. Use the dependency tree in bugzilla to track tasks reason to use bugzilla is that it is a common tool that will do enough of what we need, as long as we use a manual workflow on top of it. so, tasks could be documents with their own set of dependencies, or a chapter, a feature request, etc. tasks can be infrastructure related, so for example with alexandria (staging server), we break it down into the pieces that need work. *: by gang, auditing trail on! megacoder: have a good trip megacoder: bye then the Wiki becomes a place that links to specific master tracking bugs. s/the Wiki/http://fedoraproject.org/wiki/DocsProject/FedoraDocsSchedule/ quaid: I'm so down with that oh, well, you know what I mean even though that s/// will choke :) The EditorAssignments pages pretty much works like that exactly there will be many pages that are a series of links to bugzilla trackers, depending on the page What are the chances that we can get BZ accounts with a slight edge on rights, so we can support having ownership of our own bugs? yeah, it's nice to use the Wiki as an aggregator of content as opposed to the source. stickster: I have zero idea how ACLs work in bz, so for example, was mether_gone closing bugs that you could not? Correct we could certainly ask for a bump on everything that is in the fedora-docs component, that makes good sense for all FDSCo members. That would be completely sufficient, methinks ok, task so noted :) ok, last piece in the first agenda item was about trans I sent email to the internal trans list asking for help with the following: 1. one-time assistance to verify the quality and faithfulness of the two translations we have for the relnotes 2. or recommendations or vouching for the two translators 3. Help with making a process to deal with translations, something like: A. A translation is submitted from a trusted translator. B. Another trusted translator confirms the translation. C. The translation is posted to fedora.redhat.com/docs I haven't sent that email yet, I'm looking for other thoughts on this matter. the bottom line is, translators are asking for a process to use, and we need one. The relnotes are arguably special because they ought to go out simultaneously in all langs yes, they need a faster turn around -and- the quality must be checked more thoroughly. yes, they should go out with release i.e., be translated during test cycles and only updated for the release final, allowing them to ship with fedora-release package. I thought about trans of the DocG and got scared :-) oh, I think it will be a while until we get a trans of any of our guides, maybe tutorials. whatever we do, it will start with what we decide for the relnotes process. We perhaps need to work with the idea of cut-off points yes, he have to Where the a frozen copy of the master is marked for trans Which works fine for relnotes right, we tag it perhaps If we can stick to deadlines :) we have to for the relnotes the rest I don't care about, really do we have a schedule up? it will be good to have the IG updated for release, but that's about the only one. no, FC5 schedule is still in the air aiui So could we have docs/trans are part of the main schedule ? figure we have a few months to work it out, though :) good point, yes I should say so elliss: I think that would be good ok, I have the task of making sure we get on the schedule, won't be that hard what we need prior to that is some kind of window of time which we have to work out with trans prolly on f-trans-l, too ok, I'll send this email to the internal folk, mainly because I want to ask about verifying translators work without insulting the translators by appearing not to trust their work, then we'll take up on f-trans-l and I'll carry over any relevant points to f-docs-l please join f-trans-l if you have not already :) ack! another list... :-( The burdens of responsibility :) what, disk space isn't cheap enough for you? :) it's my time that's expensive ;-) stickster: we'll find some nice keywords you can use gmail to label with, trim down the excess :) np, I'm just being cantankerous Evo rules == :-) oops, s/rules/filters/ all right, let's see what else is important to cover today on the toolchain ... I personally think we should be spending energy on FOP and Saxon, then xmlroff, but ... are there any enlightenments from here? megacoder is gone, unfortunately ... we can continue to discuss on list, too I mean, is it just mean, or are we suffering from either Java-hate or NIH? NIH? Not Invented Here I have no preference, as long as it works in Fedora and is an open source tool (And comes in Core/Extras) The latter is the main point, IMO quaid: clarification for notes -- elliss says the main point is "open source," not "in Core/Extras" Yes. Java isn't necessarily now closed, but *may* be idealy any XSL processor will work the same for HTML, but the creation of formatting objects (FO) is the problem for PDF creation. FOP works but requires Java, people say xmlroff is worth a look but I've no idea yet if it works. Suggestion: Set criteria or test cases The IG rendering I've seen looks good but was missing the images If xmlroff can do the IG with graphics + relnotes then it can probably do anything else quaid: wow yeah, they are fast Can they write it as well ? :) not if they are anything like our internal translators, their specialty is language, not technical issues or research. j/k - we should be quicker Anyway - is the Java solution testable in some way ? If a solution doesn't technically work then we can discount it for the record, megacoder is looking into adding Saxon to xmlto as a target, and using gcj to compile sAxon and FOP elliss: I think that is the test, it has to a) build entirely free, then b) make a sane PDF. sane == everything is there and we don't have to break (many) DocBook or XML rules to make formatting work. i.e., we can resolve all formatting issues on the XSL side,. ok, I've got the task to assign for making test cases/criteria, probably hand that to Tommy as well anything else on this? if not, any comments on the staging server (codename: alexandria)? write up posting to f-dsco-l today Just read it 60 sec before meeting... looks like a good idea... will Elliot or someone else provide the infrastructure? Or will they do something nifty like Xen this off a current system? aiui, Sopwith said there is some infrastructure we could appropriate sweet One thing - SSH seems implicit, can/should our main CVS keys be transferred ? this would likely be our only 'dedicated' server, however it comes about, and it could also run builds of translations and any other fun stuff with XML and PO files we can manage with a Makefile. elliss: why is ssh implicit? I don't see anyone interacting with the box itself, save the sysadmin. the box may not need a CVS account either, it could use anon and pserver alexandria would simply pull CVS and build, right? I assumed manual building would be possible. To see the outputs and then make adjustments. Emphasis on assume here I don't know how this *should* work Not having the experience the basic idea is what stickster said you commit to CVS, wait some interval, then check the URL I would think we would leave manual building to the users on their own systems... otherwise any choices we make for tools could ostensibly be used for Evil Purposes the idea here is that ppl can have local build environments but don't have to' what Evil Purpose are you thinking? naughty content? this covers, btw, people who are writing on non-Fedora systems, etc. without implicitly supporting, we provide them some support. That's what confused me - with no build env you have to guess, wait and hope, so to speak No... if there is a security hole in xmlroff or something, a logged in user could exploit it elliss: yes, except you -can- review your own XML first :) I've seen it in action before, it's not too bad the autobuild would output an error log that gives clues as to what is broken, basically just putting stdout on a webpage. stickster: no user logins. If there's a time delay then perhaps e-mail is better You get it when it's ready quaid: right, that's my point elliss: yeah, the system I worked with did an alert for each broken build with link to the error log stickster: I don't understand then. how could an xmlroff exploit be run by a logged in user if there are no user logins? quaid: My original point was that SSH was not required... now the lag has made that redundant :-) Let's move on :) I'll work on the description to make it more clear stickster: only comment on XML today is, we have a smart person using it internally for some stuff, so if you get into a technical jam and need some help, let me know and I'll see if I can rustle up some. sorry guys, gotta go pick up the baby have a great night! I have a pretty decent .conf file... I am pretty impressed with xmlformat, and since it only requires a single .pl file, there's no need to piddle about with getting it into Extras tcf: g'night <-- tcf has quit ("Leaving") Finally asleep. I catch up on the list. Sorry again :( stickster: can you post your license question to http://fedoraproject.org/wiki/FedoraLegalIssues ? I'll push on Greg to get them answered. hang on... dredging up email whilst you do that, I'll finish with the CVS thing, since megacoder had to jet ... last week we did the changes to make docs-common and no complaints so far. :) I switched my docs over and it's worked perfectly sweet I'll put a link to the email there... I think it's pretty open and shut. A much shorter license makes for easier answers I did the same for mirror-tutorial... which is *still* waiting for publishing (nudge, nudge) ah, speaking of dropping process through the cracks, I haven't been using bugzilla properly for tracking docs to publish. teehee on that note, is there anyone interested in learning to update the f,r,c webpages? I built a test env a while ago stickster: yeah, I have a bunch of stuff to rebuild and post ref. the UTF-8 and the relnotes etc., so I'll get mirror-tutorial in that now. per the instructions quaid: we're always willing to learn ok, I think I can add you to the ACLs, or have it done, and that would be good support to have. not a problem Editing wiki for LegalIssues right now ok, that's the last thing I have :) anything else before I bang the gavel? One thing - CVS branching yes IG in CVS is FC4, but FC5 will require a branch. Will an Fc3 release also ? Not sure how to progress this ok, Sopwith can make this clearer and we can ask megacoder later ... ya got me aiui, we usually tag the files I was going to 'cvs tag -F FC-4' for all the IG Well it's basically frozen for FC4 I think - any changes would be a for a release attached to another version or arch right <-- G2 has quit ("oops") ok, this is what I -think- we do ... 1) we tag the current as FC-4, which is the tag used for the overall release aiui What? 2) you cvs up and then move your local sandbox copy to, e.g., install-guide-FC-4/ Sopwith: trying to figure out how to branch/tag docs by release/test elliss: ultimately, we need megacoder in this discussion, so perhaps we can have it on list, with whatever insight Sopwith has for us. quaid: I had placed an FC-4 tag earlier on when I was doing the release. quaid: It should be fairly straight forward to place the appropriate tags on the appropriate content. Sopwith: yeah, we just need to work out a bit of a procedure for those of us who don't quite get all the CVS intricacies to follow :) Sopwith: it all lives in one module, yes? I've seen two methods: 1 - module-name/FC4/content and cp, cvs add, rinse and repeat per release (relnotes does this) 2 - module-name/[content] and you tag and use those as branching points. I don't fully understand how 2 works, although I did that regularly in Perforce so I get the concept ... I think #2 could work just as well on the local side, do we just have multiple directories i.e. module-name-TAG/, do a special co to get them, and when we work and commit within that local tree, it does the Right Thing in CVS? Yes You'd just check out with the branch tag. However, my impression is that once you've done docs for a release (e.g. FC4) you're not very likely to need to come back and revisit them. right, and everything that is check in within that checkout gets the same branch tag forever until manually retagged? no, not likely, although there could be errata fixes Yes, that checkout stays 'on' that branch until you change it. I don't know that we would want those fixes to have the same tag though, right? You'd want them to have the same branch, but they wouldn't need to have the same tag A tag is a name for a particular version of a file. A branch is a special type of tag that keeps progressing forward as commits come in. progression being you branch at 1.2 for a file, and then it is 1.2.1, 1.2.2, 1.2.3 etc.? yes with 1.2.* being the errata versions for example ok, I think I understand enough OK, I need to roll... did we finish the agenda then? I prefer branching and such because it is the Right Way although not necc. the easiest way to understand. yes, oh yes -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Thu Jun 30 21:47:54 2005 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 30 Jun 2005 17:47:54 -0400 Subject: IRC log, 28 Jun 2005 Message-ID: <1120168074.3324.13.camel@localhost.localdomain> Welcome all ;-) howdy, one sec while I get my notepad ready Hey, we have enough folks here that my user window is scrolling! ok, here's a quick agenda: * website update darn paste! * tidy-bowl looking good! * bugzilla ACLs update * task process update * website update * update on docs trans discussions * alexandria update * AOB so, megacoder, how ya feeling about the tidy-bowl and friends? I'd like a few more people to beat on it by changing files in the "xml-normalize" project. Only files checked into that area will be normalized, er, reformatted. IIRC, stickster was going to send an invitation to the list. an invite to beta test? yup Yes... still working on it, sorry... I had a number of other things intervene since last evening unfortunately I'll finish and send shortly after meeting cool Good. I'm done with it until something breaks. suh-weet stickster: anything else on this subj? No, check commits list for some examples... appears to do what we wanted the way we wanted :-) ok about bugzilla ACLs, which will help me and mether to deal with bugs I sent out a full request to dkl to upgrade everyone on FDSCo cool he later sent an email internally asking all managers to do something similar, one email with the access levels included. so he might be waiting to do them all at once, however oh wait, what access do you need? I have experienced him making changes as requested but not telling us, so feel free to try "advanced" access rights stuff at any time and let me know what happens if it works Sopwith: all FDSCo members full rights to fedora-docs component Sopwith: so we can all close, reassign, etc. quaid: OK... Right now, joining the 'fedorabugs' group in Fedora Account System will do the same thing (not just for fedora-docs, but for all bugs I think) wow, really? Sopwith, yes that does for all components hmm, I wonder if we all -need- that level of access I tend to be a least privilege type of person. quaid, well you can have this setup now till we get more granularity well, yeah, if that is the project mode, I can roll with it. stickster: go ahead and join fedorabugs group through admin.fedora.redhat.com righty-o ok, next thang I didn't do anything more with the task tacking process, I am pushing that off until next week (deadlines -n- all that) I'll try to have something for us to discuss next week. so, now, about the website I have a small pile of updates that need to happen, and it's getting bigger I'm wondering if anyone is interested in helping update the website? it's easy stuff quaid, what is involved? Do you need a FDSCo person in particular? not per se, no but it certainly needs to be someone who is up to speed with mostly everything happening at a particular time updates for the website are simple, you check out the website and set up a local sandbox for checking. updates are checked into CVS and tagged LIVE, all live content is swept in hourly. our DocBook stuff needs to run through a tfox script and be checked, it works 90% of the time but there are some odd corner cases with HTML output from XML. maybe a couple of people? G2 from FDSCo, and mether, who doesn't have enough to do already? quaid, Ya I could pick up *some* of the content I can get somethings sorted next week. g2, mether: how about we do some training on it next week, after the FDSCo meeting? quaid, ok. I need to learn to handle cvs properly there's the tools and I want to capture some of the habitual process I've used to this date. mether: cool, we'll make that part of the training. I can handle the current workload, but it's increasing and I don't want to get caught with my drawers down :) ok, moving on ... quaid, well the current content is outdated enough for that ;-) btw, anyone else is welcome to the training and ACLs, just want to get some designated people too quaid, we will document it quaid, others can pick it up mether: yes, but not the content for this project, that is fairly updated right yeah, that would be great FDSCo members should probably all have access to update, in case of urgent needs, etc. but in the future we will want one or two specific "Web publishers" who go down a checklist for each document as part of publishing it, etc. Fine. quaid, would you give us a better idea on what needs to be updated specifically quaid, the content under the docs wing? mether: yes, that is our focus quaid, ok mether: I'm thinking specifically right now of publishing tutorials that are waiting (mirror-tutorial) and translations. ok, one sec while I dig up my notes on trans process. yeah, only thing I can find is IRC log :/ here is the summary, I will go through the log and write up something better: we're going to make translation of the relnotes part of the hard deadlines this will enable them to be included in the release so, for each test release, we will have a freeze several days before the relnotes need to be in the test, and trans has a chance to get as many in as they can. the tools guy for the trans team is willing to work with us on some automagic for example, they use this http://elvis.redhat.com/cgi-bin/i18n-status that lets them keep track of who is translating what, and people do CVS locks etc. I want to keep all the trans in their CVS as canonical, just MHO but it feels right. so the process would be like this: 1. we write like crazy until doc freeze 2. we freeze and send a message to f-trans-l that the relnotes are ready for trans 3. Bernd Groh (tools guy) opens the floodgate in their tools that lets the system automatically pull our modules from our cvs tree 4. translators do their thing, and whatever is in the tree at 100% by the test trans freeze goes out with the test release rinse, wash, repeat for each test up to release by release time, they should be only having to translate a smaller percentage. by then, we will have a chance to look at xmldiff type stuff, which will make a huge difference in how difficult trans is. Looks pretty reasonable... as long as we can coordinate with $PERSON for our deadlines also, the rh.com based translators will commit to being the relnotes translators for the time being, considering the importance of the materials, and move it into the community as we can. the deal is, the trans team has big time processes that allow them to get their shit down on time, every time. <-- tcf has quit ("Leaving") we benefit in efficiency by attaching into those processes. sweet Moving on then? yep alexandria update is, I haven't written up a better draft of the staging server yet, also pushing out to next week. stickster: your tidy-bowl invidation has made it to the list. I added a short addendum. from there it's a matter of engaging Sopwith in what can and cannot work. I'd like megacoder and stickster to work closely with Sopwith and I on defining and implementing the staging server stuff. ok, fine, fer sure, fer sure Valley Coder Tennessee Valley Coder ;-) Like, gag me with a mouse y'all "Like, Java sucks, give me machine language, gawd!" :-D Kung-fu? I know "tire tool"! ok, open for other discussions and such I probably forgot something with my off-the-cuff agenda DocGuide status run away!! ah, yes Um, I suck? 'Cause, like, that's *totally* the status. No, what I mean to say is... I am working on condensing the many disparate suggestions into a more formal outline of the guide from which I will be able to ask for volunteers for writing those sections... relying on, of course, the expertise of tcf (hey, where'd she go?) for advice and assistance Maybe she was actually gagged, back there a moment or so. repeat: this is not related to any agenda but did anyone here try out gplflash or swfdec? not I -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: