Hello all,
Just some suggestions that might be helpful for everyone, break the
release notes into two sections. One for people new to Fedora/Redhat and
one section for those who have previous experience with Fedora/Redhat.
And yes I have read the current release notes thank you very much. :-)
An introduction to the project is a nice way to break someone into the
community.
Hardware requirements are a must as well as certain errata about out of
box support for some of the more common hardware problems (i.e. wireless
g cards, current Nvidia drivers, etc) This does not have to be long and
involved just a mention about if certain things will work out of box or
if it will require tweaking.
I also think it would be prudent to cover major package/software issues
like the Flash plug-in for Mozilla. It's not an involved answer but it
would save us about 50 posts a day explaining that compat-libstdc++
needs to be installed for Flash to function properly until the new
plug-in is released.
The new handling of updates needs to be explained better, it's nice that
it is mentioned that up2date now uses yum and where to find the
configuration files, but for people who have not used yum in the past, a
little explaining needs to be done. Such as how to obtain updates, how
many repositories you should have in your configuration files and a
brief tutorial on how to obtain new RPMs using yum.
I know all of this seems very expansive and might be a bit much for a
Release Notes / README file, but providing this information somewhere on
the website even would give Fedora an image of being more user friendly.
Damon Fister
RHCT
On Mon, 2003-11-24 at 16:54, Edward C. Bailey wrote:
> Hello all,
>
> OK, now that I have your attention...
>
> I can make the claim I did in $SUBJECT because I wrote them (actually,
> others have made the same claim, but I digress)... :-)
>
> I'll be making changes in the way the release notes are done for Fedora
> Core 2, but first I want to collect some data.
>
> Basically, what do you want the release notes to look like?
>
> Currently, the release notes includes the following sections:
>
> o An Introduction to the Fedora Project (Should this be kept? Might be
> a good way for newbies to get hooked into the Fedora community)
>
> o Hardware Requirements (CPU, disk space, memory)
>
> o Installation-Related Notes (Anything that impacts the user during
> installation)
>
> o General Notes (Anything else that doesn't fall into any of the other
> sections)
>
> o Package Changes (packages that have been added/deleted/deprecated)
>
> o Kernel Notes (If it relates to the kernel, it goes here)
>
> These sections came into existence organically (meaning that nobody really
> thought about it :-) and I think it shows. The biggest thing I dislike
> about this structure is that the "General Notes" section becomes so
> overwhelmingly large that it's difficult to find anything in there.
>
> Some differing approaches come to mind:
>
> o Make it all package based
>
> Pros:
>
> - If you want to see whether package foo has anything of interest,
> it's easy enough to find out -- look in section foo.
>
> Cons:
>
> - Way too many sections with way too little content in each one
>
> o Make it partially package based (select which packages get their own
> section based on packages that are "important" or "big" or "changed"
> enough -- everything else goes into a "none-of-the-above" section)
>
> Pros:
>
> - Still pretty easy to find stuff (you look for a specific section,
> if nothing, look in "none-of-the-above")
>
> Cons:
>
> - How to select which packages get sections in a meaningful way and
> with a minimum of flames ("Hey, why didn't 'foo' get a section --
> it's really important/big/changed?")
>
> o Make it based on function (for example, "Desktop", or "Programming")
>
> Pros:
>
> - If chosen well, sections would make sense
>
> Cons:
>
> - While most packages would be easy to categorize, there will
> always be ones that might straddle sections -- what then? And
> there's still probably need to be a "none-of-the-above" section,
> though it should be minimal in size (if the functions are chosen
> well)
>
> My instinct says a function-based approach would probably be best, but
> maybe someone out there has an entirely different approach that would be
> even better.
>
> In any case, I'm sure that I can't do as good a job coming up with ideas as
> everyone reading this. :-) So, let's hear it -- what do you want the
> release notes to look like?
>
> Ed
