David-Paul Niner wrote:
Those are some truly great suggestions; No one reasoning logicallyshould have any reason whatsoever to be offended.
I am fairly hard to offend - what you read was disagreement.
It would be nice if the newly-revamped Fedora governing body could include representation from the non-technical community. I realize this is probably a "pie-in-the-sky" expectation, and I can't imagine how one would go about selecting a person (or persons) for this role, but if this could somehow be accomplished then the distribution itself would be more universally appealing.
Could you explain a little deeper about how inclusion of "representation from the non-technical community" at the beginning of your paragraph gets Fedora to be "more universally appealing" by the end?
1. Pre-release non-technical user testing.
The test releases merely need to be given to non-technical users -- by, eg, you -- for this to happen.
Why? I know why a commercial product is marketed, the goal is to maximize profit. But I'm not sure of the application to Free software. If you have some philosophical basis for it I am interested to hear it, but you just assume marketing Free software is a righteous goal.
From the parent post:"Upgrading needs to be fail proof from version to version. Previously installed drives with personal user data needs to be able to be retained without fail from upgrade to upgrade if the user isn't doing a cleaninstall."Response: "Fedora is very decent at this already." This sort of response shows no willingness to re-examine current practices and is very off-putting to people looking to become involved in the project.
That "sort of response" in fact shows my excellent experience with an rpm-based upgrade system, eg, upgrading boxes from FC1 through FC4 using yum. As I said Fedora IS very decent at this already thanks to the solid basis of RPM. If you believe otherwise please elaborate.
Before you bother flaming, I realize these are very general statements. The point is to foster discussion.
If you want to foster discussion, please issue considered argumentation, not unreasoned bulletpoints.
Description: S/MIME Cryptographic Signature