on the nature of BROKEN

[Greg Troxel <gdt%lexort.com@localhost>]

I know there are two schools of thought:

  1) If we know a package won't build (because of something that is a bug,
  including 'ought to be more portable but isn't), set BROKEN or
  BROKEN_ON to

    a) clue in the human trying to build right away

    b) avoid wasting cycles in bulk

  2) Don't set BROKEN because it masks failures and it's useful to see
  them in bulk reports.

Broadly I think 1 is what's in the guide and maintstream doctrine and 2
is jperkin's view.

I am somewhat sympathetic to 2 but not nearly enough to throw 1
overboard, and we as a group not all doing the same thing isn't good.

So, I wonder if we should have an IGNORE_BROKEN that people doing bulk
builds can set, to get the kind of results they want, while the people
that want the guide-described semantics get those.  Then there would be
no conflict, and we can have the best of both worlds.

Having thought this, I'm going to return to "just follow 1" instead of
feeling a little conflicted about point 2.

If I'm confused, and there are multiple kinds of BROKEN, such that
category 2 people think some that should cause package builds to be
skipped in bulk builds and some should run and fail, please explain.

jperkin: Does IGNORE_BROKEN as a concept work for you?