[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> What we don't have is buy-in from -core; and the only way that will
> happen is if enough people voice their concern. It's hard to work from
> the inside if you're on the outside, and no one's asking you in.
Do you believe that if you make valued contributions (like analyzing the
cores and submitting patches), follow the steps to becomming a committer,
etc. that the core team will tell you to go away? I disagree.
The issue, admittedly as I see it, is not core's willingness to help or
allow others to help... But rather finding time to cater to everyone's
requests. If we had a core team that was 3x the size, with 20x the
userbase and 5x the systems programming experience... there would still
be someone saying "Hey, why did it take so long to fix my problem?" The
answer in that case would still be, "Because we can only do so much in a
given amount of time."
I guess I see people arguing that "core isn't helping them" - I think
core's trying to help, based upon past experience, but they're buried in
other tasks. (Sometimes project-related, sometimes life-related.) Since
you can't demand time from volunteers, the only solution is finding more
qualified help. That's something we're always trying to do... So, in a
sense, the entire community is already busy working on your problem.
What initially started this thread was a post indicating production use of
stable, and resulting frustrations when stable breaks. No indication of a
staging process was included. (Although this sort of thing is common in
environments where you're moving code around.) Suggestions were made
indicating how some mitigate the risk of migrating a development branch of
code into a production environment, and those suggestions will indeed
often reduce frustration resulting from production breakage. Asside from
taking safeguards to protect yourself from breakage, unless you're writing
the code to fix your problems, you can't really do much more than report
your issues with send-pr. If you do fix your own problem, then you can
submit the patch and a core member will assist as needed. I guess I don't
see how that process is broken.
I look forward to seeing your unique solution to your problem set.
(Everyone has opinions based upon typical usage patterns, etc.) Please
don't take my posts as a desire to NOT see FreeBSD improve... Or as
resistance to change... Or as an attempt to (as previously stated)
belittle the significance of your issues. I believe everyone here wants
to see FreeBSD improve. However, I also think that many of the issues
facing us today are resource related, and that's something that won't
likely go away in the near future (no matter how many processes we put
into place). Can we agree to that? I.e. Even if you and Marc start doing
verbose boots and saving cores for all issues you encounter... Going from
data gathering to a working, tested solution takes time. This, in
turn, goes back to having a proper staging process in place... Then your
production servers aren't broken while fixes are being developed.
To Unsubscribe: send mail to majordomo@xxxxxxxxxxx
with "unsubscribe freebsd-stable" in the body of the message