minutes/log 31-May-2005 meeting

[Karsten Wade]

<quaid> <meeting>
<quaid> sorry about the lack of agenda, I'm like a headless chicken
<_stickster_> Good with mushrooms and wild rice?
<quaid> exactly
<tcf> yum!
--> mariusm (~mariusm at littledude.inetfast.com) has joined #fedora-docs
<quaid> 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
<tcf> ok, so maybe we should start with relnotes status
<quaid> yeah, those things
<quaid> ok, here's a quick agenda then:
<quaid> * relnotes status
<quaid> * install guide status
<quaid> * doc guide thoughts (time coming soon)
<quaid> * tools status
<quaid>  </>
<nasrat> AOB
<quaid> Annals of Botany
<_stickster_> sounds good to me
<quaid> ?
<_stickster_> All Other Business?
<quaid> ah
<_stickster_> Aggravating Opal Bunnies?
<quaid> yeah, dict failed me on that one
<tcf> I asked twaugh about printing for the relnotes, and he said there
is nothing significant to mention
<G2> just feeding ben be with you all in a minute
<quaid> no worries
<quaid> ok, relnotes officially went to bed yesterday
<quaid> and that was immediately followed by a bunch of bug reports from
notting, warren, et al
<quaid> 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.
<quaid> all in all, I'd say the new process worked out great.
<tcf> cool, just wanted to let you know so you knew why I didn't commit
anything about printing
<quaid> those who had time to contribute stuff in had an impact and
helped make the whole thing much smoother.
<quaid> tcf: cool
<quaid> 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.
<tcf> great, CVS access couldn't have come at a better time
<quaid> 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
<quaid> 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.
<tcf> seems like it might be easier to read for the end user
<G2> hi all
<elliss> Hi.
<quaid> yeah, one data point we'll want is how the PPC users found it
this time with the PPC stuff inline
<quaid> G2: hello!
<tcf> 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)
<G2> Sorry I haven't been much help with the realnotes
<tcf> G2: hi!
<G2> quaid knows why
<_stickster_> I think someone threw in the idea of conditional building
to allow separate builds of the HTML/txt
<tcf> _stickster_: yes, we've done it in the past, so I think it is just
a matter of should we
<quaid> and we have to switch to profiling from conditionals, aiui
<quaid> ok, we'll table the discussion on the future of the relnotes for
a few weks.
<_stickster_> k
<G2> elliss: RHEL4
<G2> quaid: OK
<elliss> Better than Debian (I'll stop):)
<G2> elliss: OT
<G2> 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))
<quaid> yes, and if there is anything more I should sneak in, now is the
time.
<quaid> on to the IG ...
<G2> Are they up on the wiki?
<G2> moving along...
<quaid> no, relnotes not on the wiki yet
<_stickster_> Stuart, I yield
<_stickster_> Sock it to em big guy!
<quaid> good point though, we can do that for release
--- _stickster_ is now known as stickster
<quaid> elliss: how are you feeling about the IG?
<G2> elliss: did you do all the IG?
<elliss> All the screenshots are in.
<elliss> G2: Most of original draft.  Stickster added lots of editing
magic
<stickster> quaid taught me everything I know
<quaid> only via osmosis
<elliss> I've said that I won't declare it complete, but it looks
shippable
<quaid> cool
<stickster> That's a good summation I think
<quaid> I plan on doing a cover2cover read this week, anyone else might
want to as well.
<G2> I'll take a look tomorrow. Is it a cvs co ?
<quaid> 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.
<stickster> G2: yup
<quaid> install-guide module
<G2> ok.
<elliss> Is it feasible to talk about adding it to the ISOs ?
<quaid> stickster, elliss: unless you *want* us committing changes
directly to CVS :D
<stickster> quaid: ACK
<stickster> 8-O
<G2> Has there been anymore discussion on a fedora-doc.rpm  ?
<quaid> elliss: we don't have a documentation RPM of our own,
unfortunately.
<quaid> not really
<stickster> elliss: Sopwith said this *would* be possible
<stickster> elliss: Sorry, that was in particular about putting it on
the ISO
<stickster> Or was it Jeremy?  Someone told me...
<stickster> I think it was Elliot
<elliss> Well, if the files sit next to the README they would be in a
good spot.
<tcf> might be better to have a separate RPM per manual
<stickster> elliss: exactly
<tcf> even though we don't have any docs right now, might as well think
big ;-)
<stickster> tcf: Right, but source RPM could come right out of the
CVS... then build fedora-doc-install-guide, fedora-doc-documentation-
guide, etc
<stickster> tcf: Or is that stupid?
<G2> I'm going to have come in and go out etc., Ben won't settle.
<quaid> G2: no worries
<stickster> G2: lots of parents here, you're in the clear buddy
<G2> What does RH do for rpms?
<tcf> stickster: Sounds like one SRPM would be OK. If I think of any
cons, I'll let you know.
<quaid> 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?
<G2> I remember stealign tammy's one form RH9 to do one for my company
<elliss> quaid:  You're a faster typer
<stickster> quaid: right... it's the other guides that would be more
helpful
<quaid> we do separate RPM
<quaid> s per guide
<tcf> and separate SRPMs as well
<quaid> right
<G2> what would their dependancies be? Firefox?
<stickster> No dependencies, really
<tcf> I made htmlview a dep when I was building them
<G2> some kind of viewer
<stickster> Build should include .txt
<quaid> it might depend ... we could look at docs to see if they need
packaging together (all security, all package m anagement, etc.)
<G2> yeah.
<G2> what about a man page format?
<tcf> b/c htmlview just points to whatever the default browser is (just
a little script)
<G2> for the console?
<G2> or just use lynx etc?
<elliss> This is kind of longer-term - generate an OMF file to add
direct into Yelp.
<stickster> That's what links is for :-)
<tcf> or rather, maybe I called htmlview...yeah, sorry it has been a
while ;-)
<stickster> elliss: There you go, one-stop shopping
<tcf> I made the menuitem call htmlview so it would use the default
browser
<G2> cool
<stickster> tcf: Right, I remember using that many times... :-)
<stickster> All this and more can be accomplished in the fullness of
time... or for FC5, whichever comes first
<tcf> stickster: yes, there is always a chance you don't have htmlview
installed, but making it a dep seems wrong
<tcf> elliss: yes, adding to yelp would be nice
<quaid> elliss: Yelp will read XML, aiui
<tcf> quaid: yes, it will
<tcf> quaid: but it was slow at first
<quaid> ah
<quaid> anything more you gents need for the Installation Guide?
<elliss> To go full circle
* quaid smiles :)
<stickster> A big fat corporate sponsorship
<stickster> With free booze and broads
<quaid> working on it 
<quaid> broadswords?
* stickster apologizes to any offended by the term "broads"
<G2> I was.
<elliss> Can we add alongside README for this release, without
considering the RPM (slow typer)
<quaid> hmm
<elliss> Since desktop integration doesn't matter here so much
<stickster> elliss: Let's send an email to whoever spins the ISOs, to
ask for the inclusion of a single no-chunk HTML version
<quaid> have to ask Sopwith
<elliss> It insures that users get it you see.
<stickster> quaid: I think Sopwith told me he could make this happen if
we had it done by this week
<stickster> Should I confirm with him?
<quaid> yes
<stickster> k
<quaid> also
<quaid> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156151
<quaid> that has a Makefile that supports no chunks
<quaid> the XSL is already checked in, but I haven't patched any of the
Makefiles yet
<tcf> jlaska had already patched the XSL to do this
<quaid> 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.
<quaid> tcf: that's the one
<tcf> quaid: cool!
<tcf> quaid: he was hoping his patches would get applied
<elliss> er... "no chunks" ?
<quaid> his patches were nicely waiting for me when I needed them
yesterday, OSS at it's finest
<tcf> elliss: one html file instead of multiple html files
<elliss> Aah
<tcf> quaid: yes ;-)
<quaid> multiple files == chunking
<quaid> ok, so stickster will check with sopwith about including a no
chunks HTML with the README, that's cool
<quaid> anyone with time to read it this week and offer edits, great
<quaid> and I'll get it ready for f.r.c/docs in time for the release.
<stickster> 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
<quaid> ok
<stickster> (I'm writing the "confirm?" email right now)  :-)
<quaid> yeah, be prepared for him to say no, just in case
<stickster> Understood
<quaid> not sure how he wants it handled, such as should we check in a
built HTML to the release-notes/FC4/? etc.
<quaid> anything else on this?
<stickster> Nope, email just went to Sopwith
<elliss> No.  It's done (for this release).  (Hurray !)
<stickster> sweet
* quaid cheers
<stickster> I guess that means we're on to DocGuide
<quaid> yeah, or we will be on to it next week, so in preparation
<quaid> stickster: you have point on that work, is there anything you
want us to be thinking about in advance of that work?
<elliss> Is the Wiki still the place to look ?
<quaid> elliss: for the DG work?
<stickster> The wiki has my most recently thunk thoughts
<stickster> Please feel free to contribute
<quaid> sidebar question then ... is the Wiki working for this stuff?
<quaid> or is it better to use BZ?
<stickster> For jotting quick thoughts I prefer the Wiki... since my
process was to start an outline, the Wiki works best
<stickster> I flesh it out over tiem
<stickster> *time
<quaid> ok, just wanting to be sure we haven't enabled too many tools
<stickster> 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
<G2> just building all the docs now
<G2> brb
<stickster> The biggest view I can give of the Docguide is that the
example tutorial will hopefully illustrate (almost) everything in the
DocGuide
<stickster> "Learn through doing," in other words
<quaid> yes
<elliss> That's a good way to stay on track
<tcf> or learn through "cutting and pasting" ;-)
<quaid> one issue that we had this last week in collaborating was the
differences in environments.
<stickster> tcf: Bingo
<quaid> e.g., I couldn't solve some problems elliss is having with
Emacs, and Tommy uses jedit ...
<quaid> all of this is really coding style invisible in the end product.
<tcf> quaid: I might be able to help with the emacs problems if we send
me a list
<stickster> 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
<elliss> That would help a lot
<tcf> stickster: good point, don't know of any off the top of my head
<quaid> 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
<elliss> Yes.
<elliss> E.g. pgsmlx doesn't work for me at all
<quaid> we could also rely upon xmldiff instead of regular diff
<stickster> quaid: Hey, that's a good point
<tcf> quaid: I like that idea
<quaid> I like to see everything in the commit, but maybe editors could
be using xmldiff instead
<quaid> makes coding style matter less
<tcf> elliss: psgmlx fails on me sometimes, but in general, it works for
me
<stickster> At some point, we have to solve either one of two problems:
enforce consistency at the client level, or at the server level
<tcf> agreed
<quaid> 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
<elliss> I don't think we can do client
<quaid> elliss: exactly
<elliss> Can't stop people running rawhide for ex
<quaid> e.g., I won't support Windows users, but they have to be able to
write there if they wish.
<stickster> elliss: Actually, that's something we *have* to enforce
<tcf> yes, you can enforce on the client level within a org or business,
but not for a community project
<stickster> 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)
<tcf> stickster: true, but that doesn't mean that system is their main
workstation
<elliss> stickster: I'd like a standard for testing against, but
authoring is separate
<stickster> As for the toolset, though, we could say, you break it, you
keep both pieces :-)
<stickster> The toolset should always work on base + updates-released
<elliss> DocBook Wiki creeps in here
<elliss> Keeps it all server-siide
<quaid> yeah, that works for support, we only try to resolve toolchain
problems on base + updates and/or rawhide
<quaid> does anyone have ideas on how we could post-process check-ins?
<stickster> It's in the CVSROOT I think
<elliss> quaid: We run test builds for 3 months out of six, so "base"
gets confuseded
<stickster> quaid: commitinfo
<elliss> E.g. are you on FC3, FC4 test <latest>
<stickster> quaid: nm, I'm st00pid
<quaid> elliss: well, it's in our own interest to solve problems in the
toolchain in the current release _and_ the current test
<quaid> but not for e.g. FC2
<quaid> ok, so this is important stuff to consider for the DG
<stickster> Please, everyone, contribute your thoughts to the bullets on
the DocGuide page
<quaid> once FC4 is out the door, we can look at fancy stuff that
Sopwith can help with on the server side.
<stickster>
http://fedoraproject.org/wiki/DocsProject_2fDocumentationGuide
<quaid> stickster: we can also have an "all DOCG" meeting in a week or
two, perhaps after you have enough organized?
<quaid> anything else on the DocG?
<G2> my install-guide module is empty?
<quaid> hrm
<stickster> 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
<stickster> Let's put it a week or two out from that if possible
<quaid> we also covered tool discussions, too
<quaid> 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.
<quaid> no hurries, no worries :)
<stickster> thx :-)
<quaid> I'm about to have my power cut for a little while
<quaid> we failed city inspection last week for our power setup, the
solar guy needs to install another breaker widget.
<quaid> so, last call for meeting content?
<stickster> nothing here
<tcf> nothing here either
<quaid> 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.
<quaid> I'll be saying the same thing about the IG in a few weeks.
<quaid> last thought ...
<quaid> 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.
<quaid> I'm stoked with our progress, everyone on this committee and
within the project are engaged and mainly happy.
<quaid> so, don't worry at all about your individual whatevers, you all
rock and we couldn't/wouldn't be here without you.
<quaid> Thanks!
<quaid> </meeting>
-- 
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: <http://listman.redhat.com/archives/fedora-dsco-list/attachments/20050603/faddd006/attachment.sig>