Re: python woes in netbsd-10 bulk builds

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

Taylor R Campbell <riastradh%NetBSD.org@localhost> writes:

>> We had this discussion before.  The adopted policy values freshness for
>> security purposes over availability.  That's not going to change on my watch.
>
> Why do you think I am suggesting changing that priority?

Because that's really what it sounds like.

> If some package _currently_ listed in bulk-test-essential is holding
> things up, then when the alarm is raised -- like it should have been
> back at the end of June when setuptools failed to build -- we can
> review whether that package should still be considered essential.

To first and second order, there are no essential packages.  There is
only "are there packages which have failed in this
about-to-be-symlink-moved official build, which generally build on the
branch when other people do builds."

Evaluating that would be very helpful, and Benny has been quietly very
constructive about it with bulk tracker.  What's needed is some logic
from that database that identifies regressions over time and things
missing in one build of a platform that are present in multiple other
builds.

The hard part of getting from here to there is having enough people
doing bulk builds that we have multiple data points at all times.   And,
doing it on pkgsrc head, so that we have this information as we go
along.   mef@'s builds have been very helpful.

> So is the pmc-endorsed criterion whether firefox builds?  (That is,
> after all, the only concretely evaluable criterion that is actually
> listed at <https://pkgsrc.org/quarterly>: `In case A, it is better to
> wait for the resolvable problems to be resolved, and then move the
> symlink, so that users don't upgrade and e.g. end up with firefox
> missing.')

That's an example.  "Resolvable" means somebody can say "I think I can
have this fixed in 48h".  Not "It hasn't built for months and nobody has
noticed."

Also, you are making a huge big deal out of the change to the "get the
recent packages" link.   People who do not like the behavior that new
bits appear promptly at the risk of some packages being missing can:

  Observe that "pkgin upgrade" gives a warning.   And if it doesn't when
  it should, file a bug.

  Read https://ftp.netbsd.org/pub/pkgsrc/packages/README.md and use
  explicit links of their choosing.

I am not aware of any complaints over the last year of "symlink moved to
new branch and $TERRIBLE_THING happened to me".

And, if you care about things being broken, then we need to look at
package updates and other commits that cause breakage, understand why
that happens, and address that.  I've put a huge amount of effort into
that over the last 5 or so years.  While it may not seem like things are
better, they are IMHO vastly better than they would have been, and the
damage caused by unstable upstreams that do not respect portability
cannot be ignored.

So basically I think you're addressing 5% of what's wrong in a way that
is not a good improvement/effort ratio.

> I would also appreciate input on the other specific changes I
> proposed:
>
> 2. put each build in a separate single-use directory and use 302
>    redirects instead of symlinks into a repeated-use directory
> 3. include bulklogs or link to bulklogs in package upload
> 4. have a program to evaluate QA criteria and update the redirects
> 5. disable the cron job that regenerates pkg_summary and rely on
>    builders to do it

You are overlooking that volunteer time to do all of this is scarce and
thus anything that makes things more complicated is not really credible.
Thus 2 and 4 I am very skeptical of.

3 sounds good, and the path to that is enhancing pbulk and other scripts
to do this automatically.  All of these should be public, as there is
nothing special about official TNF builds other than they are done in a
trusted computing environment and uploading to the official server.

5 I don't know the details and as this is about specific setups and
bespoke scripts it is probably best to talk to individuals.  Although
you could look at pbulk to see if prepare/upload scripts are there and
if they have support for this workflow.