Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Jun 2012 21:25:43 -0800
From:      Royce Williams <royce.williams@gmail.com>
To:        freebsd-hackers@freebsd.org
Subject:   Re: Upcoming release schedule - 8.4 ?
Message-ID:  <CA%2BE3k93Kkdozi5SA3RCsfe0cmZJCcFUzZxJqDs%2BH2qLr_Dpbgg@mail.gmail.com>
In-Reply-To: <CAJ-VmonEi411MPd9cXJAdJkYRsFLqfNyc5DJe7zkGxsLXBiSxw@mail.gmail.com>
References:  <alpine.BSF.2.00.1206111537310.19012@kozubik.com> <alpine.BSF.2.00.1206121545560.19012@kozubik.com> <CAJ-Vmomw7Tnce2Gyo443smS_%2BZQ4jLhWUqxhuZ2m-F%2Bxi81=Nw@mail.gmail.com> <201206130853.32687.jhb@freebsd.org> <CAGH67wTJ7zwAtf0g009_bxyJP5VXBUkeebNGvZCm%2B-0-8RfjvA@mail.gmail.com> <20120614042602.GA6638@lonesome.com> <CAJ-VmonEi411MPd9cXJAdJkYRsFLqfNyc5DJe7zkGxsLXBiSxw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 surpasse=
d)
>> 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" bran=
ch.
>
> 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.h=
tml
[2]. http://lists.freebsd.org/pipermail/freebsd-hackers/2012-January/037310=
.html



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BE3k93Kkdozi5SA3RCsfe0cmZJCcFUzZxJqDs%2BH2qLr_Dpbgg>