On Sun, 25 Sep 2016 16:54:45 -0000
"Timothy Ward" <gtwa001(a)gmail.com> wrote:
Although I agree with the above then may be a builder should have a
rawhide VM running with these updated critical packages if only for
testing purposes to expose this type of failure.
Sure, as I noted perhaps we should move some of the staging ones to
branched or rawhide. But thats just the start/easy part. Then someone
has to watch for failed builds, sort out which ones are caused by
package error or other packages or whatever and find the few caused by
the builder state and track them down.
So, basically it's this problem x N. I personally don't have many free
hours a week to devote to this, and I doubt the kernel maintainers do
either. :)
The other concerns is that the package should have issued some sort
of critical error message to the appropriate log before the limit was
reached. and then start shutting down or limiting the process's or
threads running. Is easy to say but may be a lot harder to actually
achieve.
Yep. Would be nice, not sure how hard it is to do.
Although the change was communicated there needs to be a process
that
effective communication of these sorts of changes is sent to ensure
that it will be picked up by more than just the fedora team leader
which already has a fairly big workload.
Well, the change was communicated only in the NEWS file burried in
a bunch of other changes.
It is a corner case at the extreme end as most testers probably would
not have the hardware or knowledge to test effectively. Supplying
info on how to test effectively may be a solution but will require
someone to do it.
But I feel Kevin's and others involved frustration and the amount of
time that trouble-shooting this would have taken.
Yeah, I just want to try and improve things so perhaps it doesn't
happen again/as much/as soon.
kevin