Re: "missing" SAs/ENs?

On 8/10/22 16:14, Kyle Evans wrote:
> On Wed, Aug 10, 2022 at 12:36 PM David E. Cross
> <david@crossfamilyweb.com> wrote:
>> We just had a big dump of multiple SAs and ENs yesterday.  At least one
>> of those I know has been pending for months (and AFAIK was ready to go
>> technically within days).  Additionally I know of and personally have
>> been hit by 3 other things that I feel really should have been ENs and
>> out by now (and am maintaining my own patches for):
>>
>> 1. loader handling of root geli disks is broken.
>>
>>       This one is a big deal, it completely bricks systems, there has
>> been a patch for months.
>>
>> 2. userboot.so doesn't work when compiled with BIND_NOW. relatively
>> minor, affects few people with non-standard build options, but likewise
>> known for a long time, patch committed.
>>
>> 3. compile hang in certain circumstances with LLVM with CPU targeting on
>> AVX512 processors.  Again, minor, affects few people with non-standard
>> build options, but also know for a long time with a patch
>>
>>
>> I suspect by the fact that I've personally hit these 3 that there exist
>> many others that other people have hit that I have not (yet.
>>
>>
>> It feels like there is a backup or stoppage of EN/SA processing.
>>
> I'm not familiar with #1/#3, but I didn't feel that #2 warranted an EN
> and thus, didn't fill out a template for it. This is a non-standard
> build configuration and has been broken for a long enough time that
> there's almost certainly nobody else trying this at all, given that
> yours was the first report. Errata notices are only issued on an
> as-needed basis, when someone fills out the template and submits it.
>
> Thanks,
>
> Kyle Evans


#2 wasn't even me who reported it, I (mercifully) found all of these 
issues by searching existing bug reports (which also shows this is 
hitting multiple people, some of us just may squeak louder than 
others).  Also why I didn't file an EN request, I thought it was handled.


I definitely appreciate that non-standard compile or execution options 
can complicate decisions on what all to include as an EN; these (to me) 
seem to fit that.  They are a result of configuring the system in a way 
that is documented to work, are hard breaks (removing functionality) 
when it doesn't work, and the patches for all are trivial (no more than 
a few lines).  For example if 'device foobar' prevented the kernel from 
compiling, or caused a panic, even if 'foobar' was not in GENERIC, I'd 
expect an EN to be issued.  if it just worked poorly, maybe not, 
especially if it was dozens of lines.


Where is the EN template?  I'll gladly fill out 3 for these.