Some thoughts on beat writing

Karsten Wade kwade at redhat.com
Tue Dec 9 20:18:13 UTC 2008


On Tue, Dec 09, 2008 at 08:13:02AM -0500, John J. McDonough wrote:
>
> ----- Original Message ----- From: "Karsten Wade" <kwade at redhat.com>
> To: <fedora-docs-list at 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:

https://fedorahosted.org/fedora-doc-utils/

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:

http://fedoraproject.org/wiki/Docs/Beats/PackageChanges

> The writer is still faced with figuring out what is actualy in the beat, 
> 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
-- 
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/docs/attachments/20081209/7fcda490/attachment.bin 


More information about the docs mailing list