IRC log, 21 Jun 2005

[Paul W. Frields]

Please excuse the last post (7 Jun 2005), since it is a repeat.

= = = = =

<meeting>
<tcf>	I'm here!
<stickster>	hiiiiiiidey-ho!
<quaid>	look, mrj, toolchain and XML on the agenda :)
<quaid>	how was everyone's Solstice?
<megacoder>	even-tempered 
<stickster>	Just happy I can justify putting the kids to bed *earlier*
in a couple months
<stickster>	All righty, let's hit it then
<quorum>  :-)
<quaid>	I put busy-ness at the top of the agenda
<quaid>	just to open the discussion door
<quaid>	see if we can spark some ideas to spin off and work on.
<quaid>	the problem, I think, is that too much work still is in our
hands, so when the relnotes@ address heats up, we are effected.
<elliss>	A lot of the reports seemed to be other bugs
<stickster>	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 :-)
<stickster>	elliss: right you are
<elliss>	A "how to report bugs" page ? 
<quaid>	yeah, it's the vagaries of getting more attention, you get more
email about rnd crap
<stickster>	elliss: Not a bad idea... a "How to Bugzilla" tutorial
<elliss>	I think I scribbled something about this on the ever-growing
Doc Guide wish list
<stickster>	Fantastic
<elliss>	?
<elliss>	Somebody has to write all this stuff though :)
<stickster>	that you scribbled in the right place :-)
<stickster>	elliss: Patience, grasshopper, DocG meeting still on the
horizon
<elliss>	OK - specific idea
<elliss>	put the link at the bottom of a checklist
<elliss>	So they don't see it till they've hopefully read all the other
options
<quaid>	ok, that's a good idea
<stickster>	Checklists with very short bullets garner more eyeball
time :-)
<elliss>	We could put an interim page on the also ever-growing Wiki, if
it's an immediate issue
<quaid>	elliss: can you (ironically) use the pre-filled bugzilla and
file that as a suggestion against the relnotes?
<quaid>	well, I think this is all part of the lack of active task list.
<elliss>	Sure (with no irony).
<quaid>	this committee has tasks that we track, but we need some project
task mastering
<quaid>	can we do this collaboratively via the Wiki?
<stickster>	http://fedoraproject.org/wiki/DocsProject/FedoraDocsSchedule
<elliss>	That's the issue - Tommy put the page in place, but for some
reason we haven't used it
<stickster>	I did, but very little is in it
<megacoder>	Whaddya mean "we" paleface?
<quaid>	:D
<quaid>	should I transfer our tasks from the minutes to that page after
every meeting?
<stickster>	I prefer BZ since it makes it easier to see dependency trees
without me having to spend time formatting text
<tcf>	I added my stuff to the page ;-)
<stickster>	quaid: superb idea
<tcf>	I agree, adding to it after the meeting is a good idea
<quaid>	stickster: I agree, yet without a visible list all can see it's
hard to delegate :)
<tcf>	I like it b/c it gives me a task list
<tcf>	bugzilla contains more than my fedora stuff ;-)
<elliss>	I'm not fond of Bugzilla because the comments just get longer
<stickster>	quaid: good point
<elliss>	until you have a really long list
<quaid>	elliss: one bug per task, blocking one or more master tracker
bugs
<elliss>	Wikis are nice whiteboards, IMO
<stickster>	It would be awesome if one could web-share projects using
Imendio Planner
<stickster>	:-D
<quaid>	:)
<quaid>	well, unless it's really cool
<elliss>	That's probably the best answer
<stickster>	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
<quaid>	oh, definitely, if you have many dependencies especially.
<elliss>	We currently have Bugzilla or Wiki, or managing TODO files in
CVS (yuk) 
<quaid>	essential for heavy dependency stuff like building bridges or
software.
<elliss>	Actually .ics files as well, for time-based stuff - for those
that do Evolution
<quaid>	hey, G2, we're discussing how to handle our task list(s)
<stickster>	Ugh, Planner still apparently too early in development to
demand much... ignore that chatter :-)
<quaid>	for now, we can try this:
<quaid>	1. Whiteboard projects on Wiki
<G2>	Hi, sorry. Just got Ben to sleep.
<quaid>	2. Convert each task into a bug report
<G2>	My time will be freeing up over the next two weeks too!! At last.
<quaid>	3. Make one or more master tracker bugs
<G2>	brb
<quaid>	4. Use the dependency tree in bugzilla to track tasks
<quaid>	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.
<quaid>	so, tasks could be documents with their own set of dependencies,
or a chapter, a feature request, etc.
<quaid>	tasks can be infrastructure related, so for example with
alexandria (staging server), we break it down into the pieces that need
work.
<megacoder>	*: by gang, auditing trail on!
<quaid>	megacoder: have a good trip
<stickster>	megacoder: bye
<quaid>	then the Wiki becomes a place that links to specific master
tracking bugs.
<quaid>	s/the
Wiki/http://fedoraproject.org/wiki/DocsProject/FedoraDocsSchedule/
<stickster>	quaid: I'm so down with that
<quaid>	oh, well, you know what I mean even though that s/// will
choke :)
<elliss>	The EditorAssignments pages pretty much works like that
<quaid>	exactly
<quaid>	there will be many pages that are a series of links to bugzilla
trackers, depending on the page
<stickster>	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?
<quaid>	yeah, it's nice to use the Wiki as an aggregator of content as
opposed to the source.
<quaid>	stickster: I have zero idea how ACLs work in bz, so for example,
was mether_gone closing bugs that you could not?
<stickster>	Correct
<quaid>	we could certainly ask for a bump on everything that is in the
fedora-docs component, that makes good sense for all FDSCo members.
<stickster>	That would be completely sufficient, methinks
<quaid>	ok, task so noted :)
<quaid>	ok, last piece in the first agenda item was about trans
<quaid>	I sent email to the internal trans list asking for help with the
following:
<quaid>	1. one-time assistance to verify the quality and faithfulness of
the two translations we have for the relnotes
<quaid>	2. or recommendations or vouching for the two translators
<quaid>	3. Help with making a process to deal with translations,
something like:
<quaid>	A. A translation is submitted from a trusted translator.
<quaid>	B. Another trusted translator confirms the translation.
<quaid>	C. The translation is posted to fedora.redhat.com/docs
<quaid>	I haven't sent that email yet, I'm looking for other thoughts on
this matter.
<quaid>	the bottom line is, translators are asking for a process to use,
and we need one.
<elliss>	The relnotes are arguably special
<elliss>	because they ought to go out simultaneously in all langs
<quaid>	yes, they need a faster turn around -and- the quality must be
checked more thoroughly.
<quaid>	yes, they should go out with release
<quaid>	i.e., be translated during test cycles and only updated for the
release final, allowing them to ship with fedora-release package.
<stickster>	I thought about trans of the DocG and got scared :-)
<quaid>	oh, I think it will be a while until we get a trans of any of
our guides, maybe tutorials.
<quaid>	whatever we do, it will start with what we decide for the
relnotes process.
<elliss>	We perhaps need to work with the idea of cut-off points 
<quaid>	yes, he have to
<elliss>	Where the a frozen copy of the master is marked for trans 
<elliss>	Which works fine for relnotes
<quaid>	right, we tag it perhaps
<elliss>	If we can stick to deadlines :)
<quaid>	we have to for the relnotes
<quaid>	the rest I don't care about, really
<G2>	do we have a schedule up?
<quaid>	it will be good to have the IG updated for release, but that's
about the only one.
<quaid>	no, FC5 schedule is still in the air aiui
<elliss>	So could we have docs/trans are part of the main schedule ?
<quaid>	figure we have a few months to work it out, though :)
<quaid>	good point, yes I should say so
<G2>	elliss: I think that would be good
<quaid>	ok, I have the task of making sure we get on the schedule, won't
be that hard
<quaid>	what we need prior to that is some kind of window of time
<quaid>	which we have to work out with trans
<quaid>	prolly on f-trans-l, too
<quaid>	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,
<quaid>	then we'll take up on f-trans-l and I'll carry over any relevant
points to f-docs-l
<quaid>	please join f-trans-l if you have not already :)
<stickster>	ack! another list... :-(
<elliss>	The burdens of responsibility :)
<quaid>	what, disk space isn't cheap enough for you? :)
<stickster>	it's my time that's expensive ;-)
<quaid>	stickster: we'll find some nice keywords you can use gmail to
label with, trim down the excess :)
<stickster>	np, I'm just being cantankerous
<stickster>	Evo rules == :-)
<stickster>	oops, s/rules/filters/
<quaid>	all right, let's see what else is important to cover today
<quaid>	on the toolchain ... I personally think we should be spending
energy on FOP and Saxon, then xmlroff,
<quaid>	but ... are there any enlightenments from here?   megacoder is
gone, unfortunately ...
<quaid>	we can continue to discuss on list, too
<quaid>	I mean, is it just mean, or are we suffering from either
Java-hate or NIH?
<stickster>	NIH?
<elliss>	Not Invented Here
<stickster>	I have no preference, as long as it works in Fedora and is
an open source tool
<stickster>	(And comes in Core/Extras)
<elliss>	The latter is the main point, IMO 
<stickster>	quaid: clarification for notes -- elliss says the main point
is "open source," not "in Core/Extras"
<elliss>	Yes.  Java isn't necessarily now closed, but *may* be 
<quaid>	idealy any XSL processor will work the same for HTML, but the
creation of formatting objects (FO) is the problem for PDF creation.
<quaid>	FOP works but requires Java, people say xmlroff is worth a look
but I've no idea yet if it works.
<elliss>	Suggestion:
<elliss>	Set criteria or test cases
<elliss>	The IG rendering I've seen looks good but was missing the
images
<elliss>	If xmlroff can do the IG with graphics + relnotes  then it can
probably do anything else
<elliss>	quaid: wow
<quaid>	yeah, they are fast
<elliss>	Can they write it as well ? :)
<quaid>	not if they are anything like our internal translators, their
specialty is language, not technical issues or research.
<elliss>	j/k - we should be quicker
<elliss>	Anyway - is the Java solution testable in some way ?
<elliss>	If a solution doesn't technically work then we can discount it
<quaid>	for the record, megacoder is looking into adding Saxon to xmlto
as a target, and using gcj to compile sAxon and FOP
<quaid>	elliss: I think that is the test, it has to a) build entirely
free, then b) make a sane PDF.
<quaid>	sane == everything is there and we don't have to break (many)
DocBook or XML rules to make formatting work.
<quaid>	i.e., we can resolve all formatting issues on the XSL side,.
<quaid>	ok, I've got the task to assign for making test cases/criteria,
probably hand that to Tommy as well
<quaid>	anything else on this?
<quaid>	if not, any comments on the staging server (codename:
alexandria)?  write up posting to f-dsco-l today
<stickster>	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?
<quaid>	aiui, Sopwith said there is some infrastructure we could
appropriate
<stickster>	sweet
<elliss>	One thing - SSH seems implicit, can/should our main CVS keys be
transferred ?
<quaid>	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.
<quaid>	elliss: why is ssh implicit?
<quaid>	I don't see anyone interacting with the box itself, save the
sysadmin.
<quaid>	the box may not need a CVS account either, it could use anon and
pserver
<stickster>	alexandria would simply pull CVS and build, right?
<elliss>	I assumed manual building would be possible.
<elliss>	To see the outputs and then make adjustments.
<elliss>	Emphasis on assume here
<elliss>	I don't know how this *should* work
<elliss>	Not having the experience
<quaid>	the basic idea is what stickster said
<quaid>	you commit to CVS, wait some interval, then check the URL
<stickster>	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
<quaid>	the idea here is that ppl can have local build environments but
don't have to'
<quaid>	what Evil Purpose are you thinking?  naughty content?
<quaid>	this covers, btw, people who are writing on non-Fedora systems,
etc. without implicitly supporting, we provide them some support.
<elliss>	That's what confused me - with no build env you have to guess,
wait and hope, so to speak
<stickster>	No... if there is a security hole in xmlroff or something, a
logged in user could exploit it
<quaid>	elliss: yes, except you -can- review your own XML first :)
<quaid>	I've seen it in action before, it's not too bad
<quaid>	 the autobuild would output an error log that gives clues as to
what is broken, basically just putting stdout on a webpage.
<quaid>	stickster: no user logins.
<elliss>	If there's a time delay then perhaps e-mail is better
<elliss>	You get it when it's ready
<stickster>	quaid: right, that's my point
<quaid>	elliss: yeah, the system I worked with did an alert for each
broken build with link to the error log
<quaid>	stickster: I don't understand then.
<quaid>	how could an xmlroff exploit be run by a logged in user if there
are no user logins?
<stickster>	quaid: My original point was that SSH was not required...
now the lag has made that redundant :-)
<stickster>	Let's move on
<quaid>	:)
<quaid>	I'll work on the description to make it more clear
<quaid>	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.
<tcf>	sorry guys, gotta go pick up the baby
<tcf>	have a great night!
<stickster>	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
<stickster>	tcf: g'night
<--	tcf has quit ("Leaving")
<G2>	Finally asleep. I catch up on the list. Sorry again :(
<quaid>	stickster: can you post your license question to
http://fedoraproject.org/wiki/FedoraLegalIssues ?
<quaid>	I'll push on Greg to get them answered.
<stickster>	hang on... dredging up email
<quaid>	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. :)
<elliss>	I switched my docs over and it's worked perfectly
<quaid>	sweet
<stickster>	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
<stickster>	I did the same for mirror-tutorial... which is *still*
waiting for publishing (nudge, nudge)
<quaid>	ah, speaking of dropping process through the cracks, I haven't
been using bugzilla properly for tracking docs to publish.
<stickster>	teehee
<quaid>	on that note, is there anyone interested in learning to update
the f,r,c webpages?
<elliss>	I built a test env a while ago
<quaid>	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.
<elliss>	per the instructions
<stickster>	quaid: we're always willing to learn
<quaid>	ok, I think I can add you to the ACLs, or have it done, and that
would be good support to have.
<stickster>	not a problem
<stickster>	Editing wiki for LegalIssues right now
<quaid>	ok, that's the last thing I have :)
<quaid>	anything else before I bang the gavel?
<elliss>	One thing - CVS branching
<quaid>	yes
<elliss>	IG in CVS is FC4, but FC5 will require a branch.
<elliss>	Will an Fc3 release also ?
<elliss>	Not sure how to progress this
<quaid>	ok, Sopwith can make this clearer and we can ask megacoder
later ...
<stickster>	ya got me
<quaid>	aiui, we usually tag the files 
<quaid>	I was going to 'cvs tag -F FC-4' for all the IG
<elliss>	Well it's basically frozen for FC4 I think - any changes would
be a for a release attached to another version or arch
<quaid>	right
<--	G2 has quit ("oops")
<quaid>	ok, this is what I -think- we do ...
<quaid>	1) we tag the current as FC-4, which is the tag used for the
overall release aiui
<Sopwith>	What?
<quaid>	2) you cvs up and then move your local sandbox copy to, e.g.,
install-guide-FC-4/
<quaid>	Sopwith: trying to figure out how to branch/tag docs by
release/test
<quaid>	elliss: ultimately, we need megacoder in this discussion, so
perhaps we can have it on list, with whatever insight Sopwith has for
us.
<Sopwith>	quaid: I had placed an FC-4 tag earlier on when I was doing
the release.
<Sopwith>	quaid: It should be fairly straight forward to place the
appropriate tags on the appropriate content.
<quaid>	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 :)
<quaid>	Sopwith: it all lives in one module, yes?  I've seen two
methods:
<quaid>	1 - module-name/FC4/content and cp, cvs add, rinse and repeat
per release (relnotes does this)
<quaid>	2 - module-name/[content] and you tag and use those as branching
points.
<quaid>	I don't fully understand how 2 works, although I did that
regularly in Perforce so I get the concept ...
<Sopwith>	I think #2 could work just as well
<quaid>	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?
<Sopwith>	Yes
<Sopwith>	You'd just check out with the branch tag.
<Sopwith>	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.
<quaid>	right, and everything that is check in within that checkout gets
the same branch tag forever until manually retagged?
<quaid>	no, not likely, although there could be errata fixes
<Sopwith>	Yes, that checkout stays 'on' that branch until you change it.
<quaid>	I don't know that we would want those fixes to have the same tag
though, right?
<Sopwith>	You'd want them to have the same branch, but they wouldn't
need to have the same tag
<Sopwith>	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.
<quaid>	progression being you branch at 1.2 for a file, and then it is
1.2.1, 1.2.2, 1.2.3 etc.?
<Sopwith>	yes
<Sopwith>	with 1.2.* being the errata versions for example
<quaid>	ok, I think I understand enough
<stickster>	OK, I need to roll... did we finish the agenda then?
<quaid>	I prefer branching and such because it is the Right Way although
not necc. the easiest way to understand.
<quaid>	yes, oh yes
</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/c8f28728/attachment.sig>