IRC log, 7 Jun 2005

[Paul W. Frields]

<meeting>
<quaid>	hi everyone :)
<stickster>	Hi quaid 
<quaid>	megacoder is auditing the meeting today, fyi
<quaid>	today I'm trying a new thing of taking actual minutes during the
meeting, we'll see how it goes
<quaid>	hi G2 
<quaid>	(just starting)
<quaid>	ok, we have a quorum 
<stickster>	Let's do it
<quaid>	my final word this release on the release notes:
<quaid>	they are really done now, and I'm going to hand them off for
translation
<quaid>	and hope that Sopwith does a final respin
<Sopwith>	nope
<Sopwith>	FC4 is gold
<quaid>	shucks
<quaid>	from 6/6?
<Sopwith>	Yea. The relnotes I have are from sometime last week
<G2>	hi
<quaid>	oh well
<quaid>	no showstopper fixes I know of
<stickster>	's OK quaid, don't let the perfect be the enemy of the good
<Sopwith>	Thanks everyone for doing these release notes - they are very
well done even considering the few bugs.
<quaid>	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
<Sopwith>	I think I tagged it already
<Sopwith>	FC-4 tag
<quaid>	I have that as an action, to create that webpage
<quaid>	Sopwith: ok, that was a tree wide tag, right?  so we wouldn't
have seen a commit to f-docs-commits?
<Sopwith>	quaid: Right, tagging operations don't send e-mail.
<quaid>	oh, right
<Sopwith>	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.
<quaid>	hmmm
<stickster>	Sopwith: What's "everything"?
<quaid>	stuff won't build, iirc it relies upon relative path names
<quaid>	xsl/, common/ etc.
<Sopwith>	quaid: We can fix that stuff - I made it possible in
release-notes/FC4/Makefile as part of earlier changes.
<Sopwith>	stickster: common css stylesheet-images xsl README
<stickster>	Sopwith: gotcha
<quaid>	Sopwith: it's in all the parent XML files, too
<quaid>	they call to ../common/
<quaid>	however
<quaid>	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))
<quaid>	tcf: did you have a reason for separate directories in FC, as
opposed to in RHEL where everything -is- in docs-setup/ ?
<stickster>	I think this may be why FE uses &common_stuff in their
modules flie
<stickster>	*file
<quaid>	instead we could have a single module that contains all the
sub-folders
<quaid>	perhaps 'docs-common' instead of '-setup'
<quaid>	then a docs-common/entities/, d-c/xsl/, etc.
<stickster>	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"
<quaid>	stickster: I tend to like that idea, as well
<quaid>	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)
<stickster>	Right
<G2>	brb
<quaid>	ok, anything else on the release notes?
<stickster>	not here
<G2>	Everything looks fine
<stickster>	Except thanks for the IG plug
<quaid>	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. ?
<stickster>	np
<quaid>	ok
<quaid>	then on to IG
<quaid>	after this meeting I am finishing my edits, sorry they have
taken so long, they are truly minor.
<stickster>	's OK, just happy we got the extra week for it then :-)
<quaid>	well, that's partly what happened, I didn't sacrifice this
weekend for it :)
<stickster>	I guess we should be happy, minor edits means we worked hard
enough
<G2>	true
<quaid>	no doubt!
<revision> and when you commit, unless there's some big beef it should
be ready for f.r.c
<quaid>	I'm going to appoint myself Publication Editor (or whatever) for
the IG, so that my edit can be the final edit before publication.
<G2>	brb (Ben)
<stickster>	elliss: any difference of opinion, Stuart?
<quaid>	once I am done we can tag the files FC-4, so you can continue
development, too
<elliss>	Version 1.0 ?
<stickster>	sweetr
<quaid>	stickster: yes, I have that as a note 1.0!
<stickster>	I think we're covered there... make sure URL matches what's
in the relnotes and we'll be as golden as FC4
<quaid>	all righty
<quaid>	if that's it for the IG for now ....
<stickster>	yup
<elliss>	yes, let's think about something else :)
<quaid>	as noted in agenda, tentative DOCG discussion with this group is
27 June
<quaid>	we all need to have reviewed the outline and ideas on the Wiki
page by then.
<stickster>	Yes, that would be a Monday, right?
<quaid>	darn
<quaid>	sorry
<quaid>	let it be noted I meant 28 June
<stickster>	We can fix it in the minutes :-)
<G2>	;-)
<quaid>	I should fix my cal to output with M on the far left, I make
this mistake all the time.
<stickster>	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>	okay, on to new stuff
<stickster>	np I was done... sorry, wireless lag
<quaid>	stickster: will you make a note to remind all of us to get
active on the DOCG after 17 June?
<stickster>	:-)  ok
<quaid>	cool, that will get us a little over a week of thinking closer
to the event :)
<G2>	Looking very good:
http://fedoraproject.org/wiki/DocsProject/DocumentationGuide
<G2>	I can spend some time on Thurs going through it
<quaid>	G2: cool, so noted
<G2>	next?
<quaid>	ok, back to moving forward
<G2>	ha
<quaid>	first new stuff is the Fedora Bounties
<G2>	Google code
<quaid>	I like Stuart's idea of a screencast project to capture
installation, that would *rock*
<elliss>	Check this out: http://live.gnome.org/Istanbul
<quaid>	G2: right, although our only area of influence is the Fedora
Bounties :)
<elliss>	Posted on Planet GNOME today - video screen capture
<quaid>	cool!
<quaid>	I definitely want to expand our documentation to include
screencasts.
<elliss>	Lots of development needed
<quaid>	it fits within our mission perfectly.
<stickster>	Yup, super sweet
<G2>	what about the vnc flash prog?
<elliss>	Gstreamer > VNC ?
<G2>	Thomas used it for Fedoranews
<elliss>	or VNC > Flash ?
<quaid>	the latter, iirc
<G2>	http://fedoranews.org/casper/vncsnapshot/
<G2>	anyway
<quaid>	right, there is plenty to work with
<elliss>	How do this progress as Bounty ? 
<quaid>	I propose using elliss's wording and adding these links as
starting places.
<quaid>	then we just add it to the bounty page.
<elliss>	OK.
<quaid>	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 :)
<elliss>	OK.  I'll e-mail the Istanbul guy first
<quaid>	is the write-up complete enough?
<quaid>	should we run the idea by the f-docs-l first for comments?
<stickster>	yes
<quaid>	there isn't a whole lot to work from, in terms of how to
structure this stuff.
<elliss>	I used GNOME bounties as a model
<elliss>	http://www.gnome.org/bounties/Documentation.html
<quaid>	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.
<elliss>	OK.
<quaid>	elliss: cool, your template is probably better than what we have
other places :)
<elliss>	The others on the Fedora Wiki are pretty vague IMHO
<quaid>	a'yup
<quaid>	that was exactly what I was thinking of :)
<quaid>	btw, IMHO we can post more than one bounty, to increase the
chance of takers.
<quaid>	so it will be good if new ideas come up on list, although we
want to choose probably no more than three.
<elliss>	Did anybody eval DocBook Wiki ?
<quaid>	I think the screencast idea is a shoe-in for one, especially if
it provides us with a screencasting toolchain :)
<G2>	yeah
<quaid>	I think megacoder installed it, or tried to, but that is the
last I can recall.
<quaid>	elliss: that's a good point, we need to undrop that ball.
<quaid>	my major concern is infrastructure
<stickster>	elliss: Does this have something to do with Bounties?
<quaid>	Sopwith: there is this really great tool that uses a Wiki
front-end for DocBook, and we need to talk with someone about hosting.
<elliss>	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
<elliss>	Live doc editing
<stickster>	ah
<quaid>	ah
<quaid>	good idea
<elliss>	The GNOME spec is vague
<stickster>	So that would be used up to a certain point, then the
resulting doc spun into CVS?
<Sopwith>	quaid: We have machines for fedora.redhat.com that may be able
to host it.
<quaid>	elliss: include that idea, either in your email or in a separate
thread to keep track if the ideas more easily.
<quaid>	stickster: it uses CVS on the back side, iirc
<elliss>	Yes
<elliss>	PDF toolchain as the third ?
<quaid>	Sopwith: who is the best person to start an infrastructure
discussionw ith?
<stickster>	There's an aspect to this that still makes me a bit
uncomfortable, which is the changeability of the doc thru a Wiki
<quaid>	elliss: no on the PDF toolchain, Ithink
<Sopwith>	quaid: Me
<quaid>	ok, cool
<quaid>	stickster: tighter ACLs?
<elliss>	OK.  Something in the works ?
<quaid>	elliss: I'm working on the PDF issue internally, and hope to use
the same solution for FDP.
<elliss>	OK.  Cool.
<quaid>	actually, I have this toolchain stuff for a point of other
business at the end :)
<quaid>	ok, any other bounty discussion can move to the list
<stickster>	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
<stickster>	I mean "offline" == "on f-docs-l"
<quaid>	right
<quaid>	Sopwith: ok, when we get someone ID'd  to work on the fancy Wiki
stuff, I'll connect back with you.
<Sopwith>	Cool
<quaid>	ok, moving
<quaid>	just a note that mether_gone is pursuing a kbase idea using
http://sf.net/projects/klear
<G2>	noted.
<elliss>	Superb.
<quaid>	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 :)
<elliss>	I've been wondering how to mobilise all the new people
<quaid>	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.
<stickster>	Anybody have a URL to that?
<stickster>	Duh... nm
<quaid>	:D
<stickster>	Laugh while you can, monkey boy
<quaid>	elliss: mobilize as kbase authors?
<elliss>	Yes
<quaid>	stickster: I know, Alzheimers is only a day away (sung to the
tune of "Tomorrow")
<quaid>	elliss: true
<elliss>	Means no dependency on new Doc Guide work
<G2>	DB_DataObject Error: DB Error: connect failed nice
<G2>	klear website
<quaid>	klear?
<quaid>	oops
<elliss>	Or DocBook know-how
<G2>	http://klear.kavefish.net/
<stickster>	Whoopsie :-)
<elliss>	Also, less commitment req'd than writing a whole doc
<quaid>	yeah, it's not fully ready for primetime ... chicken-egg problem
<quaid>	elliss: yes and yes 
<elliss>	So I'm very interested in this...
<stickster>	OK, so are we up to AOB then?
<quaid>	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?
<quaid>	AOB!
<quaid>	all other business
<quaid>	I have one, are there others?
<elliss>	Sure
<stickster>	Alzheimer's Opportunists Beware
<stickster>	me too
<mrj>	Dyslexics Untie!
<stickster>	quaid: You frist
<quaid>	roger dodger
<stickster>	ha!
<quaid>	"My legal opinion after watching this episode of Judge Judy is
that they should have executed the plaintiff."
<quaid>	anyway
<quaid>	mrj is working on toolchain concerns inside of Red Hat
<quaid>	and we are pursuing the same path that the standard DocBook
developers are using, trying to do it with a free software stack
<mrj>	all java-based, fwiw
<quaid>	i.e., Saxon as an XSL processor instead of xsltproc
<quaid>	yeah, so the gcj work plays in, etc.
<mrj>	Xerces & FOP + (XML Catalog) resolver classes
<quaid>	and as before, I have pledged to twist Java developer arms if we
need someone to package something for FC or FE.
<quaid>	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.
<mrj>	i've got the toolchain working already, but under Sun's jvm
<quaid>	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>	so I wanted to make FDSCo aware of this status, and solicit
input.  We can discuss onlist of anyone has long thoughts, etc.
<stickster>	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?
<stickster>	Sorry, I am a Java idiot, and couldn't tell you anything
about it that doesn't have to do with grinding beans
<quaid>	it might, although I don't know how much footprint.
<stickster>	I'm thinking back to the last FC4t3 install I di
<stickster>	*did
<quaid>	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.
<quaid>	the problem has been the JVM, and that is what gcj should fix.
<mrj>	true, Sun/Ibm's jvms are ~50 MB-ish, gcj not a problem...
<quaid>	if we can get it to work under gcj.
<G2>	How do other distro create pdf etc.?
<stickster>	ok
<mrj>	that's the kicker-get it to work under gcj
<quaid>	how does debian create pdf?
<mrj>	G2: GNOME pdf creation is also busted
<elliss>	I don't think I've seen other distros use PDF
<quaid>	stickster: go ahead and start your AOB item
<mrj>	debian uses fop or the dsssl toolchain (jade, etc.)
<stickster>	mrj: I make PDFs all the time in OO.o, etc....
<G2>	ah
<mrj>	pdf production is a big & widely recognized problem - hence the
redesign plans for FOP
<G2>	It used to work on RH7.3 ;-)
<quaid>	tie up on this, we'll bring our stuff to the table Real Soon Now
<stickster>	Is there a GNOME-centric engine that I'm not using which is
busted?
<stickster>	ok
<G2>	fine
<quaid>	stickster: those are PostScript outputs, from OOo
<quaid>	and ps2pdf of some kind used.
<stickster>	Ah
<mrj>	stickster: we're talking XML -> PDF, right?
<stickster>	mrj: apparently not :-D
<stickster>	sorry
<quaid>	OOo is deceptive because they use XML file format, but don't do
a direct conversion (AIUI)
<stickster>	quaid: I gotcha
<quaid>	they programattically produce a PS, etc.
<quaid>	ok, stickster, go ahead
<stickster>	2 AOB:
<mrj>	right. we want docbook -> pdf
<G2>	yes, want want linked chapters etc.
<tcf>	quaid: sorry to miss the meeting! I got pulled into a crucial
project that had to be finished today
<stickster>	#1. XML "cleaning"
<G2>	s/want/we/
<stickster>	#2. RHM deadline
<quaid>	tcf: no worries, minutes are being written as we go and will go
to the list ASAP, should help :)
<tcf>	quaid: great, thanks
<G2>	hi tcf 
<quaid>	tcf: major point for you is watch the list and participate in
discussions of 'docs-common' module that Paul will start.
<stickster>	tcf: Plus this bit right here...  :-)
<stickster>	#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
<quaid>	yeah, just in time for this stuff :)
<stickster>	This should help eliminate (hopefully) some of the pain
being caused by people on other toolsets
<stickster>	Diffs will hopefully become more sane also
<G2>	I'm off. Speak to you on the list. Night all.
<stickster>	Two candidates right now are xmlformat and tidy
<stickster>	G2: g'night
<literal> as well.
<stickster>	quaid: xmlformat does that, and I think tidy *might* be
trainable to do the same... still looking
<quaid>	ok
<stickster>	OK, so that's the status: I'm looking at them and trying to
suss out weak points for each where they exist
<stickster>	Ready for #2?
<quaid>	cool, go ahead with #2
<tcf>	sorry guys, gotta go pick up the baby--it is about to storm like
crazy here
<stickster>	#2: RHM "deadline" is pretty much the 8th
<quaid>	tcf: take off, we'll get you in loop later
<stickster>	tcf: bye, drive carefully!
<quaid>	Colin asked me for, "Could I get a quote/comment about the newly
formed FDSCO for an article
<quaid>	> I'm writing? Goals, aims, how you're enjoying the job as lead,
etc."
<quaid>	which I am working on
<stickster>	oh sweet, under control then... that was it :-)
<quaid>	oh, cool
<stickster>	You da man
<quaid>	yeah, he's in SF this week
<quaid>	I'm trying to see if I have time to drive up for dinner tomorrow
<stickster>	?
<stickster>	gregdek?
<quaid>	drbyte!
<stickster>	oh, sorry missed that one
<tcf>	stickster: thanks!
<tcf>	bye
<stickster>	damn wireless
<--	tcf has quit ("Leaving")
<quaid>	nah, greg's cool and i'll drive to see him too, but Colin is
more of a once-in-a-while opportunity
<quaid>	I just saw greg last week and will again this coming week :D
<stickster>	I'm done then
<quaid>	s/last/last last/
<quaid>	cool
<quaid>	did you all catch about the Fedora Marketing Project?
<quaid>	anything else?
<stickster>	what about the FMP?
<quaid>	just that it was forming and Colin (note: not a Red Hatter) is
the chair of the steering committee?
<quaid>	just in time to grok and explain the FF to us all :)
<stickster>	FF?
<stickster>	Oh
<stickster>	Fedora Foundation
<quaid>	Fantastic Four!
<stickster>	Lucky Colin  :-D
<stickster>	Flame on!
<stickster>	quaid: I guess nothing else then
</meeting>


-- 
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: <http://listman.redhat.com/archives/fedora-dsco-list/attachments/20050630/dbdb8101/attachment.sig>