Build series naming

[David Holland <dholland-pkgbulk%netbsd.org@localhost>]

I just finished clearing a couple years' worth of stale reports out of
my pkgsrc-bulk inbox, and while that experience is fresh I'd like to
suggest that we adopt a convention for the Subject: line names of
build series.

Right now almost everyone's reports are slightly different, which is
not a problem for identifying multiple builds of the same series, but
is a nuisance for less frequently built targets where successive
comparable builds may not come from the same builder and thus often
don't sort together.

Since your mailer can sort by date, sorting by subject should sort by
other stuff of interest first and the build date should be last.

Also, the pkgsrc branch should be towards the end because the other
metadata is more fundamental and when e.g. sparc netbsd builds move
from Q1 to Q2 you want them to still sort together. Right now there's
a tendency for the pkgsrc branch to be first, which isn't that
helpful.

I'm going to suggest the following as an arbitrary proposal:

   Subject: results $(OS) $(COMPILER) $(MACHINE) $(DETAILS) $(PKGSRC) $(DATE)

where all of the fields should be obvious in outline, but I'll suggest
the following details:

OS: OS name and version, e.g. NetBSD-9.0; "current" and not "HEAD",
for MacOS include both the number and the name (number first so it
sorts properly).

COMPILER: use the pkgsrc compiler string

MACHINE: this should identify the userland (doesn't need to identify
the kernel) so it needs to include stuff like "hf". Ideally, use the
string that pkg_install will use to determine if the result packages
are compatible with someone's install.

DETAILS: any other pertinent stuff (e.g. "restricted", "-Wall"),
otherwise empty.

PKGSRC: pkgsrc branch in the form pkgsrc-2021Q3 or pkgsrc-current (not
HEAD)

DATE: format doesn't really matter as the email date is sufficient for
mailer purposes.


Adopting some scheme like this seems like it will make pkgsrc-bulk
inboxes and archives easier to work with (at least in the long run),
but it also seems kinda bureaucratic to even suggest it, so...
thoughts?

-- 
David A. Holland
dholland%netbsd.org@localhost