On Wed, Jun 13, 2012 at 8:30 PM, Adrian Chadd <[email protected]> wrote: > On 13 June 2012 21:26, Mark Linimon <[email protected]> wrote: >> On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: >>> The only way that this would really work is if there were dedicated >>> sustaining engineers working on actively backporting code, testing it, >>> committing it, etc. >> >> I'm going to agree with Garrett here. IMHO we've reached (or surpassed) >> the limit of what is reasonable to ask volunteers to commit their spare >> time to. This is doubly true when we have more than one "stable" branch. > > I totally concur.
Ah, but you can get the same effect by freeing up those engineers to work on the hard stuff. This is my usual soapbox (see [1], [2]): Push more of the mundane work out to the edges, so that the developers can focus more on the core (like more releases/features/testing/projects). Here are some ideas. Only developers can implement them, but they would start paying for themselves immediately ... in developer time. - Frequent snapshots, with tools to automatically apply them and roll them back (freebsd-update + ZFS snapshots?). - Tools to do binary walks of snapshots to pinpoint when a bug appeared. (Think 'git bisect' + freebsd-update.) - A taggable FAQ that supports faceted search, and a quick way to add entries (or propose them for approval). - A way to search for known fixes to transient bugs and hardware issues [1]. - General debugging and testing tools for non-developers, including tools for filing smarter bug reports. - A way to automatically upload crash dumps for bulk analysis (like Windows does). - A dmesg analyzer that downloads a list during install, and looks for known issues (or workarounds) with your hardware for that version of FreeBSD (or recommend a different version!). Tools like these would also help more people achieve the "I tried it, and it Just Worked" moment. This can keep people's interest long enough to give FreeBSD a serious try. Some of them might enter the volunteer pool. I'm not a developer, but if some of the above could be tackled, they might free up enough Developer Equivalents (DEs, a term which I have just made up) to be more than worth the effort. Royce [1]. http://lists.freebsd.org/pipermail/freebsd-doc/2011-September/018865.html [2]. http://lists.freebsd.org/pipermail/freebsd-hackers/2012-January/037310.html _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[email protected]"
