IRC log FDSCo meeting 19-JUL-2005

Tue Jul 19 21:49:35 UTC 2005

Having problems pasting the IRC log inline in the body of the message,
going to do an attachment and see how that looks in the online archives.
If not, it's debugging time.

IRC log attached.
-- 
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 --------------
# FDSCo meeting 19-JUL-2005
<quaid> <meeting>
<quaid> how about reversing the agenda?
<quaid> do the quick AOB first, then get into publishing some stuff
<elliss> Good idea
<stickster> goferit
<quaid> stickster: any barriers to expanding tidy-bowl?
* quaid can't recall if he had a bug in it ... something about new lines for <ulink>?
<stickster> The ulink is the only drawback, but it's important to remember it's only a bug as long as we think of it that way
<stickster> :-)
<G2> aye
<stickster> By which I mean, if the commit is consistent, and the content of the doc is unchanged, it really doesn't matter
<quaid> true
<stickster> Although I made every effort to mirror the way I thought it should look
<quaid> the bugginess is -not- being able to affect it's behavior, that's all ...
<stickster> There's one other "bug" in it which is also exceedingly minor since it's consistent
<stickster> After <xref> tags open, the next line (usually where the url gets placed due to fill-width considerations), spacing is wrong from left-margin.  I think I know *what* it's doing, but I have no chance of figuring out *why*
<quaid> ok, the deal is, once we deploy it, we have to deal with resolving these bugs in an orderly manner.
<stickster> Again, probably matters very little since it (1) is consistent, and (2) doesn't change the doc content
<quaid> that is, we can fix it, but we have to warn people to do a special normalizing-then-commit
<quaid> I think these should be stand-alone commits with zero other content changes ... just something we'll make part of the process, I reckon.
<quaid> but ok
<quaid> any other concerns about rolling out tidy-bowl officially?
<quaid> and did Tommy and Paul
<quaid> 's write-ups suffice for how-to?
<elliss> Is xml-normalize staying as a test area ?
<elliss> Or should it be dropped ?
<quaid> yes, I guess, for the development of the normalization tools
<quaid> so we can use it for testing new changes, etc.
<stickster> We should definitely hold on to it
<quaid> ok, in that case ... 
<stickster> quaid: I can see if the xmlformat author can help resolve the strangeness... I haven't contacted him at all
<quaid> stickster: do you want to do that -before- a full rollout, then?
<stickster> Sure, why not... if he can/will help, it shouldn't take him long
<stickster> I think if I give him sample docs he can probably find the problem easier than any of us
<quaid> we can shoe-horn this into the publishing as soon as it's ready, it's just a step to add and doesn't change content or publishing details.
<stickster> exactomundo
<quaid> stickster: ok, do that when you can, and then we'll prepare an announcement of what to do and how to do it, to be mirrored in the DocG eventually :)
<quaid> all right, next item
<quaid> bugzilla components
<quaid> I wrote up an email for the list to ask for additions to that, which Versions to add, and a full description
<stickster> aka The Great Email Flood of 2005
<quaid> Paul thought of adding a 'docs-request' for non-document specific RFEs
<stickster> I have a couple others, and an apology to make first to Stuart (I think?)
<quaid> fight! fight!
<stickster> He suggested a master tracking bug, and I think maybe we need *almost* such a thing
<stickster> a "project-tracking" bug to hold things like "docs without ideas" tracker, "orphaned docs" tracker...
<stickster> Things which can't be tied to toolchain or any specific CVS module
<quaid> ah, that's a good idea
<quaid> that's where the trackers make sense, where you don't have an existing search field
<stickster> That may be what he meant and I misinterpreted it -- or more likely, I'm just foolish and didn't realize how good the idea was until I started going through BZ
<quaid> it's the user configurable field :)
<stickster> OK... so "project-tracking" is good
<stickster> Also...
<stickster> "umaintained" or "orphaned-docs" component for things where we want to log bugs, but the doc has either not yet made it to CVS or dropped out and might return one day
<stickster> Hmm
<stickster> Now that I write that, I'm not sure it's very smart
<stickster> This happens a lot to me
<quaid> yeah, it should be in CVS no matter what?
<elliss> I don't think we should use Bugzilla for that
<stickster> right... if it was ever there, it should stay there
<quaid> we can't support other repositories, can we?
<stickster> if we drop a doc, bugs are closed as WONTFIX
* quaid answers his own question, "cvs.fedora is the One True Fedora CVS'
<quaid> stickster: right, and we have the Version field for docs that only go so far and are gone to Legacy
* stickster notices quaid has "I'm With Stupid" shirt pointing this way
<quaid> stickster: the finger on that shirt spins
<quaid> stickster: I got you down for creating the project tracking tracker bug and blocking it with the other project bugs, k?
<quaid> the rest of this, let's do on list.
<stickster> OK, will do... so, does making new entries in owners/owners.list automatically give us new BZ components? Or does Sopwith have to do some magic on it?
<Sopwith> automatically
<stickster> :-)
<stickster> He's like the ghost in the machine, this guy
<quaid> aye
<stickster> sorry, moving on then..
<quaid> stickster: ok, so commit away :)
<quaid> all right
<quaid> just wanted to make sure all who were on screencasting caught the discussion on fedora-marketing
<quaid> and I saw Stuart pop in there earlier
<quaid> that was all I wanted, if anyone else wants to comment about it, or thoughts, etc.
<elliss> The screencasting HOWTO is a good idea
<stickster> Absolutely
<stickster> I'll be fascinated to read it myself
* quaid lols
<elliss> We could use Wiki to start documenting experiments
<quaid> I'll push that back onto the Marketeers, ask them to at least write up a structured text or Wiki version for someone to start with
<quaid> and consider owning it themselves :)
<elliss> Yes.  In our CVS it wouldn't be so visible until it was complete
<quaid> good point
<quaid> ok, anything else on that?
* quaid prepares to move on
<stickster> ... wait for it ...
* quaid is cvs up'ping in preparation for publishing something
<quaid> stickster: if you have anything in your local f.r.c/docs that you want to commit and have me review/sanity check, go ahead or ask away.
<quaid> otherwise, I can handle the Web publishing to keep things moving along.
* quaid notes that he doesn't have anything to publish yet, probably next week with the SELinux FAQ
<stickster> I made trivial changes in relnotes this morning, just speling errors
<stickster> and a term change to standard English
<stickster> I haven't pushed it to the web site yet, so if you want to...
<quaid> ok, there are other fixes in there good for publishing
<elliss> speling errrors ? :)
<quaid> elliss: it's a joke, get it? :)
<stickster> elliss: you got the joke, then  ;-)
<stickster> q.v. Apache module 
<quaid> yeah, I saw that one :)
* quaid recently fixed his b0rked aspell
<stickster> I am working on yum-software-management and will have it done by end of week
<stickster> I think we had discussed merging this with desktop-up2date... what's the story on that?
<elliss> They were part of the same doc
<elliss> I split it because yum CLI is more technical
<elliss> Although we're forced to recommend it for desktop users for software installation right now
<stickster> Right... are you able to "commonize" (my new word, no need to thank me) some of the sections to make upkeep easier?
<quaid> btw, there -is- a way to xref across guides, jlaska was doing that iirc
<quaid> maybe leave <!-- LINK TO SOMEWHERE --> in the XML for once we figure this out
<elliss> The only commonalities would be "Abouts
<stickster> elliss: That's not bad, though... I can think of at least one other document that would be useful for (mirror-tutorial)
<stickster> could go in docs-common for instance
<quaid> yeah!
<elliss> Worth trying. 
<elliss> Is there a link for the cross-document xref ?
<stickster> That makes the cross-doc linking less of an issue for now
<elliss> I have an Installation Servers chapter sat on my hard drive
<elliss> So there will be a few overlaps, or possible discussion on merging some docs later
<stickster> Make sure you read mirror-tutorial first and see what we can just include in there
<elliss> I have
<stickster> I think if we put PXE stuff in there, we'll be in pretty good shape
<elliss> Mmm.
<stickster> Well, just bounce something to f-docs-l and talk about what's *not* in common, and we can go from there
<quaid> I'll find out about the cross-ref stuff and report back
<stickster> I just hate having to maintain overlapping docs wherever possible
<elliss> That's why it's still sat on my hard drive :)
<stickster> hmm, that sentence doesn't parse
<stickster> (mine, I mean)
<elliss> Didn't want to make a muddle
<elliss> With the mirror doc you are writing
<elliss> What other docs are pending ?
<stickster> I think quaid sent something to f-dsco-l
<stickster> or f-docs-l, sorry
<stickster> Ah, here you go:
<stickster> * Hardening Fedora
<stickster> * Yum Software Management
<stickster> * Mirror Tutorial
<stickster> * Proxy Guide
<stickster> * FC4 Release Notes (updated)
<stickster> * SELinux FAQ
<stickster> * Sudo Tutorial
<stickster> * USB Hotplug (out of date?)
<quaid> so
<stickster> Move usb-hotplug to legacy
<quaid> what we need is everyone to grab dibs on something in that list to edit, then edit, CVS in the changes, and we publish
<stickster> udev has superseded it
<quaid> stickster: thought so :)
<quaid> we can get the low hanging fruit (sudo tutorial, mirror tutorial, proxy guide) to get the hang of it
<stickster> That leaves 7 docs... I have "yum"  :-)
* quaid is publishing the relnotes right now
<stickster> tcf: Whaddaya say, docs lady?  :-D
<quaid> G2: have you seen the Hardening tutorial?  is that a topic you feel conversant with?
<quaid> because we do need to do technical and writing edits.
<tcf> stickster: sorry, I totally didn't realize it was past 4, some surge fried a bunch of our machines, and I am trying to do damage control
<tcf> stickster: what do you need me to do?
<stickster> 's ok, just being friendly
<stickster> sorry to bug
<quaid> oh, crum
<quaid> I updated the wrong RELEASE-NOTES-en.xml in CVS
<quaid> this is why branching is Good and little directories to get forgetful in is Bad
<stickster> whoops
<quaid> anyone with how I revert a file in CVS?
<stickster> oh wait...
<quaid> just to previous version
<tcf> quaid: cvs up -pr 1.1 filename.xml > filename.xml
<stickster> Damn, she's good
<tcf> quaid: that just gets you version 1.1, you still have to commit it back to CVS
<G2> quaid: not yet, I would be interested in that
<tcf> stickster: thanks ;-)
<quaid> tcf: so you revert by just recommitting a copy of the previous version, it's not an actual rollback?
<quaid> that's fine with me :)
<tcf> yes
<tcf> it is bizarre, but that works the best
<tcf> there is a way to co a specific version with a sticky tag, but then it only works for your local repo
<tcf> and you have that darn sticky tag to deal with that sometimes prevents you from getting the actual latest revision
<quaid> crap^2
<quaid> I just noticed we've all been working in release-notes/FC4
<quaid> this is why branching is Good and little directories to get forgetful in is Bad
<elliss> Yes. Perhaps ask megacoder about moving the layout to branches ?
<quaid> good lord yes
<quaid> or, rather
<quaid> we can just start doing that moving forward
<stickster> all right
<quaid> the FC-4 tag has been applied, so I can rely upon that to represent the as-released version
<quaid> I never did apply the FC-4-ERRATA1 tag for the content that went into the errata 
<quaid> Sopwith: what is the status on fedora-release errata?  I don't recall seeing it anywhere
<quaid> but I can go back and recreate that somehow, I think
<quaid> so ... this afternoon I'll merge the changes from that errata into the new content and make that HEAD
<Sopwith> quaid: Looks like it got built for a testing update
<quaid> and possibly work out the ERRATA1 point ... though unlikely since those changes never landed on the same files that are in FC4/
<Sopwith> Do you have new content to push as an erratum?
<quaid> Sopwith: OK, that's fine, then I know it's worth preserving the state of that data in CVS as a tag somehow
<quaid> sure could
<quaid> Sopwith: but I was just going to update the Website
<Sopwith> I was just wondering if you wanted to push a new erratum, or find out about the existing one.
<quaid> Sopwith: my point with the fedora-release was to get the default Firefox page to look prettier :)
<Sopwith> aha
<quaid> Sopwith: find out about the existing one
<quaid> although Tommy's point about the <appendix> almost makes it necessary to do another, since that leaves us accidentally in a potentially weird legal spot.
<quaid> Sopwith: so I may follow up with a request for a new erratum
<quaid> right now we are updating the f.r.c/docs/release-notes/fc4/errata/ 
<-- mariusm has quit (Client Quit)
<Sopwith> What's on HEAD of release-notes/FC4 right now is what you'd like released?
<quaid> close
<quaid> I need to troll the bug reports, too
<stickster> I need to run... gig soundcheck at 6:00 local
<quaid> kewl, ciao
<elliss> night
<stickster> bye all
<-- stickster has quit ("And then the CHUDs came.")
<quaid> ok, I'm going to work on the release notes
<elliss> Time for the gavel ?
<quaid> and will be here if anyone else wants to continue chatting/working to publishing.
<quaid> aye
-------------- 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/20050719/7a69e7a7/attachment.sig>