visibility of release process

[Kevin Day]

On Dec 8, 2008, at 10:25 AM, Ken Smith wrote:
>
> Bottom line is my communication skills suck and of the bazillion other
> things I could do with my time these sorts of housekeeping chores wind
> up at a low enough priority they don't get done.  But as you and  
> others
> have made clear the priority needs to get raised and I need to deal  
> with
> it.  That's the part being worked on.


Personally, as a end user, developer and cluster manager there are a  
few things that I would find extremely useful. I mean no disrespect to  
you or any of the work anyone on the team is putting forth for this -  
it's way more than I'm contributing so I'm grateful of what's being  
done now. This is just a wishlist. :)

* Make the release notes a working document throughout the development  
cycle. Major caveats that anything in it before it's actually released  
is subject to change, but until the release notes are published I have  
a really tough time knowing what the next release even has in it. Is  
it worth holding off upgrading 50 servers for something we'd actually  
use, or are the changes of no concern? Is it something I didn't even  
know was in the tree that I might backport myself? If the release  
notes actually are available somewhere before the final stages of a  
release, I haven't been able to find them.

* More notice to hubs@ before the release notes are generated. The  
releases always come with a "At the time of this writing, these  
mirrors have the full distribution" list. If it was announced to us  
mirror operators before that list is made, we could make sure we were  
synced in time to be included. Maybe even a semi-shaming of "These  
mirrors do not appear to have the required bits:". The difference in  
bandwidth we see on our public mirror (ftp3.us) is pretty extreme if  
we're listed there or not, which seems to be a 50/50 coin-toss on the  
last few releases. I'm honestly not sure why, since we can easily pull  
 >50mbps from ftp-master.

* The published release schedules are usually pretty far out of date.  
Beta/RCs get put up but the schedule says they haven't been, schedules  
sometimes have obviously slipped but it's unclear if it's affecting  
the final release date or not, etc. I know there aren't always answers  
to the unknowns, but more information would help.

* Where are the BETA/RCs announced? Taking a page from apple, a mini- 
release notes saying "These items have changed since the last release/ 
beta/rc:" "These areas could use additional testing:" "These bugs are  
believed to be fixed, if you're still experiencing them let us know:"  
would probably get more people testing them. and give more insight  
into what's new. On anything other than a -RELEASE, make mention of  
this document in /etc/motd. I understand this would require effort  
from people working on those features, but if the beta readme file was  
in CVS and it was easier for developers to add to it themselves... If  
I'm not on the right mailing list, I won't see the "Call for testers"  
email that some send out.

* Non FreeBSD users have a tough time with understanding that FreeBSD  
6.4 was released after 7.0. I don't think the version numbering system  
should change, but new/novice users need a clearer guide as to which  
version to install on a fresh system. For example, the /releases/ page  
says:

Release 7.0 (February 2008)
Release 6.4 (November 2008)

Which one of those is considered stable? If I know nothing about  
FreeBSD which one is "better" for me? Maybe a page that lists new  
features in rows, and a column/notes about its status in each version.  
FreeBSD has support for the Q1235 RAID controller from FooWare, but  
what version did it gain that?

I'd love to help, but I'm not sure how/were an outsider can really  
make much impact here. But, I'm semi-volunteering. :)

-- Kevin