On 5/4/05, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> 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