Re: FYI: 15stable-amd64-quarterly has had 2 successful builds, despite not being distributed yet

On Oct 10, 2025, at 06:55, Olivier Certner <olce@freebsd.org> wrote:

>> I like "Total" for the above.
> 
> Great.
> 
>> Are you suggesting to change the content of the that list
>> and the whole page to make no reference to the "scope
>> of the build" information (no count, no list for such)?
> 
> We should probably keep it, as it has (like all the other lists on the page) a search box that can be used to determine quickly if a package was supposed to be addressed.
> 
> Adding a status column to that list would be useful.  It would say either:
> - "Up-to-date" in case of an incremental build and the package already exists.
> - Any of the already existing statuses ("Built", "Failed", "Skipped", "Ignored", "Fetched", "Remaining").
> With this, users can jump to the relevant status-specific table and consult the additional columns there (such as Log) for a specific port.  This makes it easier to find the fate of a specific package by not having to search in all tables.  We can then imagine refinements (a link automatically filling the search box of the right table and jumping to it), but already just having the status info seems valuable.

Official builds are probably almost always "bulk -a" or
"bulk -ca" instead of a more specific list, leading to
the Queued Ports "Reason" column then saying "listed"
for everything and all port-packages to be considered
for further classification.

In other cases, the Queued Ports list could be smaller.

And that makes another reason for use of "All . . ."
naming to be inappropriate.

Your idea above does involve updating rows of a
frequently large table on the fly instead of adding
new rows as builds complete. An alternative would
be to just have something like "already built at start"
and "not yet built at start". That would be more of an
up-front, one-time large-table build. That could make
an implementation more likely to happen --or happen
sooner than the above, possibly forming a separate
step in a sequence of updates.

The first submittal is:

https://github.com/freebsd/poudriere/issues/1264

and sticks to the simpler, more-static extra
column --and only as an optional thing going
with the rename to "Build scope" (instead of
"Queued Ports").

It may be a bit before I submit anything for the
dynamic table update idea that would  have more
detailed information.

>> Are you suggesting that the list should only list the
>> port-packages that are in the "Total" and, so, that
>> the "entries" figure would have the same value as
>> "Total"?
> 
> No.  And, if we add the status column as evoked above, I don't think there is a need to even add this list of non-up-to-date packages as a separate section.

Okay.

>> (Calling the items ports when a port can define multiple packages
>> and pacakges are what is built is odd these
>> days --and has been for a long time.)
> 
> If you view a port as an origin + a flavor, there's still a 1:1 correspondence, but that doesn't seem to be the common acceptation for a "port" and could be considered a stretch of the mind.  That's why using "packages" seems preferable to using "ports".  Not too sure if saying "port-packages" is better, as it might cause more confusion.

I listed "port-packages" because there are now
also "base-packages" and pkg has established a
repeatedly-used context where just "packages"
(a mix of both types) are handled without
distinctions when pkgbase is also in use
--and this has lead to some confusions of its
own that I've observed.

So I'm personally biased to be explicit whenever
only one of the 2 types is involved/relevant.
(Not the same as everything needing to follow my
convention for dealing with the issues.)

>> So if the "scope of the build" information is
>> kept, I expect that its terminology should be
>> changed to avoid ambiguity.
>> 
>> I could imagine having lists and figures for
>> both:
>> 
>> ) "Total's port-packages"
>> and:
>> ) "All port-packages"
> 
> I really think these two terminologies are too close and thus confusing (why would the "Total" and "All" numbers differ? that's really unintuitive).  "Build scope" seems much better (further improvements welcome).

See earlier above about my own reason for
"All port-packages" to be inappropriate.

Okay. "Build scope" is what I referenced
in:

https://github.com/freebsd/poudriere/issues/1264


>> Note:
>> If I understand right, such may well be changes to
>> how poudriere works for providing html pages.

I looked around and found that the build-details page
is from poudriere output during the build
(poudriere-devel context example):

# grep -r "card-body" /usr/local/poudriere/data/logs/bulk/.html/build.html 
/usr/local/poudriere/data/logs/bulk/.html/build.html:                <div class="card-body fs-5">Build</div>
/usr/local/poudriere/data/logs/bulk/.html/build.html:                <div class="card-body fs-5">Jobs</div>
/usr/local/poudriere/data/logs/bulk/.html/build.html:                <div class="card-body fs-5">Built Ports</div>
/usr/local/poudriere/data/logs/bulk/.html/build.html:                <div class="card-body fs-5">Skipped Ports</div>
/usr/local/poudriere/data/logs/bulk/.html/build.html:                <div class="card-body fs-5">Inspected Ports</div>
/usr/local/poudriere/data/logs/bulk/.html/build.html:                <div class="card-body fs-5">Ignored Ports</div>
/usr/local/poudriere/data/logs/bulk/.html/build.html:                <div class="card-body fs-5">Fetched Ports</div>
/usr/local/poudriere/data/logs/bulk/.html/build.html:                <div class="card-body fs-5">Queued Ports</div>
/usr/local/poudriere/data/logs/bulk/.html/build.html:                <div class="card-body fs-5">Remaining Ports</div>

(While I do personal poudriere-devel builds, I do
not use the web page interface for my own builds,
just for monitoring the official FreeBSD build
activity. So this was not familiar.)

> All these changes are cosmetic except the new status column in the "Build scope" (or whatever) list.  That specific change is anyway a nice-to-have and could be done separately in a second step once the existing names are fixed, which really is the priority.
> 

Sounds like separate submittals against poudriere on FreeBSD's github.
I've started with the first submittal being:

https://github.com/freebsd/poudriere/issues/1264


===
Mark Millard
marklmi at yahoo.com