On Tue, Dec 09, 2008 at 08:13:02AM -0500, John J. McDonough wrote:
----- Original Message ----- From: "Karsten Wade" <kwade(a)redhat.com>
Sent: Monday, December 08, 2008 2:24 PM
Subject: Re: Some thoughts on beat writing
kind of a separate subject so a separate reply ...
I just added you to 'gitfedora-doc-utils', which is this:
That is where we can put any scripts and such that help us get the
Docs work done.
> This is similar to the long requested, sometimes provided,
> and always dubious "list of packages changed for this release."
Yes, well, I've made a couple of runs at this. I have one hack that
generates a MediaWiki import file containing the yum description and
table of versions for a beat. It is kind of a trail of bread crumbs,
though, and probably not all that useful to anyone but me.
Not sure, sounds potentially useful. If we can do it without much
hassle, let's do it -- _into_a_special_namespace_. We don't want all
this to pollute the wiki search. Alternately, we can just publish to
a scratch location on docs.fp.org
A slightly less hack-ey, but still somethng of a hack, I did more
recently following a thread with Paul, maybe on IRC I can't recall. But
I got to wondering whether I could do something that someone else might
actually use. Still a bit of a hack but again, given a list of packages
in the beat, compares two sqlite files. Thus, a beat writer could keep
the primary.sqlite from F10, grab the primary.sqlite from rawhide, and
see what has changed. I mentioned this during the last docs meeting,
hoping to get some input from others but no joy. I think this, perhaps
prettied up somewhat and with substantial guidance, actually gives the
beat writer a shot.
Does this get more information than 'repodiff'? Sorry if you haven't
seen this page, more leaking carpenter's roof:
The writer is still faced with figuring out what is actualy in the
and this is harder than it sounds. An obvious place would be the
PackageKit groups, but these are a lot less helpful than you would
suspect. There is a lot of room for judgement in assigning a package to
a group, and, IMO, many just plain errors. In some cases when you see a
package in some odd group you can imagine how someone felt it belonged
there. But even in those cases, you would be hard pressed to imagine
groups that you should check. And with 11,000 packages, you just glaze
over pawing trough package after package.
There are a few ways we can define the beats. The way I thought of it
originally was an association with a sub-project or sub-component of
the distro. This way the beat writer is embedded within the team.
This puts the onus on the team to keep their writer up to date.
What that does for us here is to distribute the question of what
packages should be watched for a beat, versus trying to figure it out
for ourselves for N beats.
The problem is getting the various sub-groups to accept and follow
this arrangement. So far, it's been a pretty light adoption, but we
haven't really pushed it that far. One thing we can do is guarantee
zero coverage without an embedded writer; we've done that ad hoc in
the past, but then someone who is not the beat writer comes in and
helps fill a bit of information. For example, didn't you do that for
Databases this time? So, we keep not fully providing the consequences
for sub-groups that don't support the beat writing process.
Karsten 'quaid' Wade, Community Gardener