Solving the great resource problem, take 42 (Re: Upcoming release schedule - 8.4 ?)

[Jason Hellenthal]

On Wed, Jun 13, 2012 at 11:06:15PM -0700, Garrett Cooper wrote:
> On Wed, Jun 13, 2012 at 10:25 PM, Royce Williams
> <royce.williams at gmail.com> wrote:
> > On Wed, Jun 13, 2012 at 8:30 PM, Adrian Chadd <adrian at freebsd.org> wrote:
> >> On 13 June 2012 21:26, Mark Linimon <linimon at 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).
> >
> > - 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 .
> 
> 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.
> 

Garrett,

This should be posted up somewhere permanent and linked to by a FAQ or a
few other articles. This is the longest "interesting" article I have
read in a while I could not stop reading... [Not being sarcastic]

Anyway...

It is too bad that in times like these that three main communities of
BSD users and programmers alike could not come to a common sense to
forge an aliance to build a better stronger (C)ommonBSD. There is a lot
more to be had by converging resources and reaching a middle ground that
fits the ideals of all three projects that would benefit more than just
users but "large" vendors and developers as well.


The resources are out there... someone just has to take the first step.




-- 

 - (2^(N-1))