a couple suggestions for fedora web page for test releases

[Jeff Spaleta]

On 5/4/05, Robert P. J. Day <rpjday at mindspring.com> wrote:
> i could properly see that as a sub-topic under "Where to download/How
> to get/How to install" or something like that, with all of the
> variations documented there.

Just a somewhat static link back to
http://fedora.redhat.com/download/test.html is the only thing the
schedule page needs. All the other potential channges additions should
be on the
http://fedora.redhat.com/download/test.html page.

> 
> at the moment, however, there's just too much stuff closely-related
> stuff scattered across more than one page.  the schedule for test
> releases is under "Participate->Schedule", while getting a test
> release is under "Download->Test Releases".

Fine.. then just link to the test release from the schedule. The
schedule is what it is... its not meant to be a walk-through of that
what and wheres of test release installation.

> given that messing with test releases is a specialized subject, i
> think everything related to that topic should be in one place.  

I dont think so. I think the schedule serves exactly one purpose... to
provide a schedule.
Really clever people will configure their calendering clients with the
provided .ics file and never have to go back to that schedule page
ever again.

> Test Releases
>   What is a test release?
>         Danger, danger ... etc, etc. ... might eat all of the
>         cheese in your house ...
>   The schedule for test releases
>   How to install a test release
>         Variations here, including rawhide
>   Keeping up to date with test updates
>         Appropriate yum.conf entries for a test release
>   Mailing list for test releases
>         NO, do not use the standard fedora mailing list ...

The fedora project webpage are not dynamically managed with a CMS
'yet'. Until it is, duplicating information across pages add fragility
and increases the chances that some information will get updated and
some will not, when pages need to be reworked. Simply cross link the
schedule from the test release page  and link the test release page on
the schedule.

Everything so far in that list except the schedule is fodder for the
test release download page in the download section. Simply crosslink
the two pages and be done with it.  If testers using the webpages
can't follow html links to a schedule or to the test release download
page... I highly doubt they are going to be able to handle filing
useful bugreports.

I think every effort to re-oganize the test release information should
center on the question on how to get higher quality bugreports
generated from reporters who are willing to followup.  I don't think
making it extremely easy and convient for anyone interested in
downloading and installing a test release is necessarily helpful to
the overall goal of testing.  Since it requires 'thought' to file a
bugreport and followup on it... I'm perfectly fine with test release
webpages that require a minimum of 'thought' as well.  For example
installing directly from rawhide can be a huge pain in the ass,
depending on what rawhide looks on the day you attempt it. This is not
something novice testers should be encouraged to try with a simple
blurb on an introductory webpage when they don't have a competent
understanding of what rawhide 'feels' like.  Advertising 'features'
like that on a page meant for first time or novice test release users
is either going to give them a really bad taste in their mouth or
worse result in an avalache of pointless bugreports about rawhide
installs not working.


>   FAQ for test releases

Depending on what you want for FAQ items this is either impossible or
just something someone needs to hack together and submit for review.

If you want items that you expect to add or update every week as
specific test issues arise, thats totally not going to happen, unless
the site goes to a CMS backend and can allow outside contributors to
attempt keep up with pages.  This is a really manpower intensive issue
for test releases. The landscape as to problems and solutions changes
significantly everyday because of the rawhide churn. I don't see how
anyone is going to keep up with communicating 'breaking news' or
'frequently asked questions' that are test release specific with how
the site is generated currently.  And even after the site goes CMS,
you are still going to be swapped with trying to keep up with daily
package churn brokenness.  At best right now, the questions you can
address are process questions that would remain rather static and not
questions that you expect to update answers for from test1 to test2 to
test3.

>   Current test version and package list

Just point people to the os/ tree on a mirror AND the rawhide tree. 
I'm really not sure why we need to waste time prettying up the
packagelist for test releases as a new url location, especially since
packages expire between test releases.   If you are really interested
in the package list issue as it developers you really need to watch
rawhide and the rawhide build reports.


-jef