On Sat, Dec 18, 2021 at 10:49:53AM -0800, Adam Williamson wrote:
> This makes sense to me. It might also make sense for big changes
to also
> include proposed updates to the validation criteria, just as modern software
> development expects new features to come with tests for those features.
We do this, but only for *functional* requirements, which I think is
correct. I don't want us to be pinning software versions and what
specific implementation of a given function "must be" used in the
release criteria, in general, because it seems like a terrible
mechanism for it, and one that really wouldn't scale.
Okay, fair enough — and I'm definitely not wanting to add _more_ automatic
blockers. :)
But it does seem like we should have _some_ set of automated testing that's
linked to intentional, acccepted changes. Nano-as-default in Fedora Server
is another one.
Maybe even something where "getting the test hooked up" is the next step for
the change owner after the change is accepted. Is there a way where change
owners could plug into some of our existing automated testing to do that?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader