i just did a quick conversion of the alpha release notes into publican. a built copy of the html-single can be viewed here: http://ryanlerch.fedorapeople.org/alpharelnotes/ there is also a tarball of the source up there as well: http://ryanlerch.fedorapeople.org/Alpha_Release_Notes.tar.gz cheers, ryanlerch On Wed, Feb 4, 2009 at 4:58 AM, Paul W. Frields <stickster(a)gmail.com&gt; wrote:

Paul W. Frields wrote: I am Done (almost). Only thing we might need to add is a brief intro to what Fedora is what we expect out of the alpha release, maybe at the end. Not sure that is necessary still. Thoughts? Rahul

On Wed, 2009-02-04 at 07:19 +0530, Rahul Sundaram wrote: I started contributing after the F10 Alpha, so forgive my disorientation. Is the goal for the Alpha relnotes[1] to be as close to complete as possible? A snapshot up to this point? If so, why isn't it based off the page[2] which transcludes all the current beats? There are beats updated for F11 which aren't included on "one-sheet". I do realize there are cutoffs and deadlines for moving content around. I just had the impression last time that content moved through the pipeline quickly/automagically after being updated in a beat. I could be deluded though (I know Karsten worked his butt off). If only the text on this one-sheet page[1] is going to go into creating the static end result[3], it seems it might be helpful to users if we at least link from this one-sheet page to the more complete (albeit inconsistent at this early stage) Beats in progress jumbo page[2]. /me still stubbornly thinks of the wiki content as the end result rather than a way point. I realize that isn't practical for L10N though. [1] http://fedoraproject.org/wiki/Fedora_11_Alpha_release_notes [2] http://fedoraproject.org/wiki/Docs/Beats see bottom [3] http://ryanlerch.fedorapeople.org/alpharelnotes/ -- Dale Bewley - Unix Administrator - Shields Library - UC Davis GPG: 0xB098A0F3 0D5A 9AEB 43F4 F84C 7EFD 1753 064D 2583 B098 A0F3

On Wed, Feb 04, 2009 at 07:32:22PM -0500, John J. McDonough wrote: I'd hope we're not summarizing 100+ changed packages on any beat, right? That would seem like overkill to me. Off the top of my head I can't think of a justification for telling people about any specific package that wasn't widely used and had changed substantially enough to be notable. I think last release cycle I removed that information from one of the beats, by general consensus, because it differed so much from the way all the other beats worked. For general package updates, someone could always run the script for diff'ing the repos -- I don't recall its name or where it's kept, but I know it exists -- and post that information somewhere suitable on the wiki. Once the initial conversion to XML was done for a Preview Release, changes tended to be easy to do. A team of two could usually get them done in an evening or less. The procedure would consist of looking at the history of each beat page, seeing there were revisions since the port to XML, then looking at the total diff to see the changes. On occasion that would expose another quick edit needed for style or grammar, which we'd make. Then we'd look at the new diff including our changes, and just edit it into the XML, commit, etc. After all that is done, we'd make the new POT, update the PO, and push everything out. Really? I don't recall any particular frustration with you! Either I have a short memory, or all's well that ends well. ;-) We eschewed doing a big publication for Alpha or Beta because there were so many details still in flux that people outside the Docs team wanted the flexibility of adding or revising content quickly on the wiki for the days immediately around the release date. If it's not too much of a pain for someone to keep up with as far as republishing, great. We found it too demanding given our resources at the time, but it's good to see that things are evolving to the point where it's not as much of a concern! -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

----- Original Message ----- From: "Paul W. Frields" <stickster(a)gmail.com&gt; To: <fedora-docs-list(a)redhat.com&gt; Sent: Thursday, February 05, 2009 2:26 PM Subject: Re: F11 Alpha Release Notes one-sheet I hope not. However, the Amateur Radio beat, for example, has 35 changed/new packages. Some of the changes are minor, but quite a few are totally new packages, some very interesting, and a large number of the changes are very significant, at least to folks who use those packages. I forsee over 70 changes in Devtools. Many require action on the part of the user so really need to be there. In that case, though, I think I can do a lot of breaking up into smaller groups. Actually, I kind of did that on the AR apps, too. But after I see what they all look like i will certainly do some winowing or perhaps grouping. Last time we had big bunches of app descriptions. That was just an error. On changes, though, I'm a little torn. A long list of changes is pretty unexciting to read through, but if you are the person affected by that change, it could be critical. As a minimum you need a heads-up on the change and a link to the upstream's release notes, if such a thing exists. Unfortunately, it seems like in a lot of cases the upstream release notes are nonexistent or very weak, and it takes some detective work to sort out what changed. I feel bad about leaving that to the reader, but I don't want to end up with an encyclopedia, either. So we play the balancing act. --McD

On Wed, Feb 04, 2009 at 04:17:10PM -0800, Dale Bewley wrote: Here's the quick history. We used to do a full conversion from wiki to XML for Alpha and Beta. We included time for translation. There were almost no positive effects we could detect, but the list of negatives was big: * Lots of churn after Alpha and Beta; l10n wasted a lot of time translating content that got thrown away a week later. * More effort to keep the churning wiki content in sync with the XML once converted. Heartache and grief. * Increased complexity lead to more mistakes, missed deadlines, and distraught people. * Putting more humans in the path from "this needs to be in the release notes for the Alpha" and "people can now read this important release note." Content for the release notes for the Alpha and Beta is often arriving at the last minute. There are lots of ways those problems could be solved and still do a conversion from wiki to XML. First, don't bother having them translated. Second, have automagic between the wiki and XML. Third, have a tightly woven schedule that everyone understands. Fourth, use automagic + CMS to make it possible for content to be pushed at the last minute. Unfortunately, we don't have any of those save the first. I recommend we keep the one-sheet as-is for Alpha and Beta until Fedora 12; we need tools, processes, and experience in place to make it not come to bloodshed and tears. :) This was only for the Preview Release and forward; that is when we did the conversion and manually kept content in sync. It could be interesting to link to the Beats at this point; they are much cleaner than usual for this part of the release cycle. It's more than that, but it's all problems that can be solved by computers. Here is some capture of the process as how it has been to this point: http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Process#The_Process - Karsten -- Karsten 'quaid' Wade, Community Gardener http://quaid.fedorapeople.org AD0E0C41