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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
