On Wed, 13 Jun 2012 23:06:15 -0700 Garrett Cooper <yaneg...@gmail.com> wrote:
> On Wed, Jun 13, 2012 at 10:25 PM, Royce Williams > <royce.willi...@gmail.com> wrote: > > On Wed, Jun 13, 2012 at 8:30 PM, Adrian Chadd <adr...@freebsd.org> > > wrote: > >> On 13 June 2012 21:26, Mark Linimon <lini...@lonesome.com> 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). There's a GSoC project underway for this. > > - 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. > > No offense, but speaking from experience, these are referred to as > "wishlist projects" -- many of which get shelved until developers get > enough time to work on them. This makes more sense when there are more > resources so engineers can work in a less distracted manner as BSD is > not Linux as far as BSD's design stratagem is concerned . We have the ideas list for this (http://wiki.freebsd.org/IdeasPage). While it does not attract that much people during the year, it attracts a lot of students which want to participate in the GSoC. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
