Re: "up to date at all costs" is a failed approach

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

We don't really have an "at all costs" doctrine.  We have a documented
expecation that when committing, everything that used to build will
still build.  We have some people that follow that and some that do not.

As Jonanthan says, we don't have full pbulk on every supported platform
for every commit, with merge approval gated on results.  I don't see
that happening unless there is a huge source of funding to pay for a
bunch of hardware resources and maybe 4 FT release engineers, just
picking a number out of a hat.  I wouldn't mind moving somewhat towards
this, which shouldn't surprise anyone as I have dropped "before updating
foo, qgis must be tested to build with it" sorts of comments.

As I see it, we have multiple kinds of commits to pkgsrc:

  - diffs proposed and often tested, for scary infrastructure things.
    These tend to get adjusted and while there is some fallout it seems
    fixed quickly and does not manifest in the quarrterly bnanches.

  - micro updates, and well-considered larger updates that do not cause
    much trouble

  - some updates of packages that are not particularly stable and have
    very wide footprints, often done soon after releases


The central problem is that if an update is maybe or maybe not wise, and
10 people look at it, and 9 decide that maybe it shouldn't happen and
don't, and 1 just updates and doesn't take responsibility for the
breakage, we end up with an update.

The fix as I see it is

  to demand immediate reverts if an update causes breakage that is major
  or that the updater does not fix really fast (48h if only a little is
  broken)

  to require group consensus before updating an increasingly large list
  of packages that have caused trouble

I think this would get us 90% of the value of jperkin's stable workflow
with 10% of the cost.   It might mean losing a few contributors, but I
think that's ok as the other side of the coin is losing other
contributors.