status of freebsd on ultrasparc?

[Royce Williams]

Mark Linimon wrote, on 6/9/2008 3:40 PM:
> On Tue, Jun 10, 2008 at 01:23:16AM +0200, Pietro Cerutti wrote:
>> |> It's Tier 2, core@ silently demoted it when updating the tier
>> |> document last February.
>> |
>> | This is now updated.
>>
>> too bad... :-( sigh
> 
> We need more people using and testing on sparc64 and contributing
> fixes back.  It's as simple as that.  (When I last asked for more
> testers, back in November, a few people did respond, but we need more.)

Wow ... did I miss an announcement about this somewhere?

Unfortunately, neither dropping sparc64 to Tier 2, nor doing so
without notifying the user community (if that's really what happened),
is likely to inspire more usage or testing - in fact, quite the
opposite.  It's a chicken-and-egg problem, except we've put the egg
back in the chicken. :-)  I understand the reasoning, though.

I suspect that folks would help more if it was easy to turn a spare
box into a 'tester'.

Anything that we can do to reduce time/effort for developers and
testers would help.  Off of the top of my head, with varying degrees
of pipe-dreaminess:

- Volunteer list: Start a list of volunteers (and their associated
hardware).  The wiki might be a good place for this, except it makes
it harder for non-committer testers to self-organize.

- Howto: A howto for novice testers might be helpful.  Suggestions for
content welcome.

- Developer-tester matching: Make it easier for testers to find
patches needing testing.  (Combing through a mailing list can be
time-consuming; how else could we do this?).

This is wild pie-in-the-sky, but what if we created a portaudit-like
tool to match up developers with testers, that would work like:

    - Developer adds their patch with applicable branch information
      to the DEVXML (or whatever).  It has information on where to
      pull the patch from (like port makefiles) and how to apply them
      (like the security advisories do).  Some of this could be
      automatically generated from a developer dropping a patch into a
      directory with a couple of tags/comments/whatever.

    - Tester runs patchmatch(8) (or whatever) to check for patches
      that need testing on their hardware/setup/whatever.
      patchmatch.conf could configure what sorts of things they want
      to help test.  patchmatch displays a pre-patch README or
      something that says "This is supposed to fix fxp watchdog
      timeouts on hardware X.  To see if you are affected by this
      issue, do X." and then "Apply patch?" and then "Did it fix
      the problem or not?" that sends the output back to the
      developer semi-automatically.

- Incremental version rollback/forward: People tracking -HEAD or a
-STABLE often update and make world at widely different times.  A
patch is only useful for a certain window of time on a certain branch.
 If I could patch my system (like freebsd-update) to a particular
point in time (like portsnap), I could quickly prepare a system to
test a given patch.


This isn't just "gee, I wish someone would do this"; I find these
ideas interesting and will tinker with the concepts a bit.
Suggestions welcome.


Royce

-- 
Royce D. Williams                                   - http://royce.ws/
    And yet I pity those they torture not.  - Percy Bysshe Shelley