Date: Thu, 14 Jun 2012 21:54:26 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Garrett Cooper <yanegomi@gmail.com> Cc: freebsd-hackers@freebsd.org, Royce Williams <royce.williams@gmail.com> Subject: Re: Solving the great resource problem, take 42 (Re: Upcoming release schedule - 8.4 ?) Message-ID: <20120614215426.00007095@unknown> In-Reply-To: <CAGH67wT-XLNiwMzADhNtsEAEYFOqWKxAqfLVCiirjJDdBKrrcQ@mail.gmail.com> References: <CAGH67wT-XLNiwMzADhNtsEAEYFOqWKxAqfLVCiirjJDdBKrrcQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 13 Jun 2012 23:06:15 -0700 Garrett Cooper <yanegomi@gmail.com> wrote: > On Wed, Jun 13, 2012 at 10:25 PM, Royce Williams > <royce.williams@gmail.com> wrote: > > On Wed, Jun 13, 2012 at 8:30 PM, Adrian Chadd <adrian@freebsd.org> > > wrote: > >> On 13 June 2012 21:26, Mark Linimon <linimon@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. =A0IMHO we've reached (or > >>> surpassed) the limit of what is reasonable to ask volunteers to > >>> commit their spare time to. =A0This 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]): =A0Push 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. =A0Only 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. =A0(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. =A0This can keep people's interest > > long enough to give FreeBSD a serious try. =A0Some 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. >=20 > 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. --=20 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120614215426.00007095>