Date: Wed, 13 Jun 2012 23:06:15 -0700 From: Garrett Cooper <yanegomi@gmail.com> To: Royce Williams <royce.williams@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Solving the great resource problem, take 42 (Re: Upcoming release schedule - 8.4 ?) Message-ID: <CAGH67wT-XLNiwMzADhNtsEAEYFOqWKxAqfLVCiirjJDdBKrrcQ@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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 surpass= ed) >>> 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" bra= nch. >> >> 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). > > - 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. 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 . This is really starting to get philosophical and away from the original intent behind the original post, but given past discussions and the fact that these topics end up going around in circles/cycling through periodically (I've seen it on ports, current/stable/hackers, etc), here's my perspective after having read these discussions a few times and given what I've seen with the project over the last 5-10 years (granted, I've become a jaded realistic/pessimist in past years, so YMMV): Problem Statement (or the "I want to have my cake and eat it too" Issue): - Users want stability, but want latest and greatest driver code and features. These are [generally] mutually exclusive. Impedance: - There aren't enough volunteer resources to do what consumers of FreeBSD want beyond what's being done, with exception of developers and other volunteers going above and beyond in extraordinary circumstances to get the job done, or doing something his/her day job requires. The former case tends to be more of the exception than the norm. The latter happens sporadically. - There are plenty of companies out there wanting to "solve this problem of release cycles", but no one group (or groups) is standing up and actively ponying up dedicated resources on a regular basis to make this a reality. What happens: Trivial tasks, like MFCing, testing, triaging, etc are being done by "lead developers" in a particular domain, which steals cycles from enhancement/bugfixing work in those areas [or other surrounding areas]; instead of investing time writing regression tests so others can do the work, no one other than the lead developers in a given area can do the work if it requires domain knowledge and/or specific hardware resources to complete the task. Eventually something happens, the developer becomes less active in the community (gets a family, no longer does FreeBSD work, gets a job, number of different things), and depending on the bus factor the particular area being maintained may remain unmaintained for some time. Alternatively, contact is done infrequently enough that interested parties willing to contribute code get discouraged and "go off and do their own thing" (be it support their own custom distro, switch to another OS, etc). In the former case, there's duplication of effort, some (or most) of which is discarded at a later date, depending on how active the supporting group. In the latter case, the party won't partake in FreeBSD, and instead the project/community misses out on an outreach opportunity. Some bugs end up going into the PR queue, where (if lucky) the item is resolved promptly; timeframes vary depending on the category, the maintainer, and the difficulty of the bug, but sometimes it can take days, months, or years. Otherwise it rots in the PR queue for some time. So, rather than do things this way by posting wishlist projects that won't happen in the immediate future, why not make developers' lives easier by spreading the load, increasing the domain knowledge in one or more areas, and improving the community in the meantime? Affected companies/the Foundation should have more than enough funds to devote towards a handful of staff to make this a reality, even if the position is part-time. Remember: low hanging fruit -> more likely to succeed -> quicker/better RoI results. Thanks, -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGH67wT-XLNiwMzADhNtsEAEYFOqWKxAqfLVCiirjJDdBKrrcQ>