On Wed, Feb 7, 2018 at 5:37 AM, Alexandre Oliva <aol...@redhat.com> wrote: > Hi, > > In this round of GCC stabilization, I've noticed a larger than usual > number of bugs that carried over from earlier cycles, with notes > indicating it was too late to fix them during stabilization. > > I wish we had some means to mark such bugs clearly, so that they could > be found easily earlier in the development cycles, instead of lingering > on until we find it's too late again. > > Just targeting it to a future release might be enough during > stabilization, but later on, it will be hard to tell these cases apart > from other bugs for which we didn't make such assessment, and that could > in theory still be addressed during the next round of stabilization. > > What I wish for is some means to find these bugs easily, while we're > earlier in a development cycle. We could mark them as we go through the > current regressions list, so that others wouldn't look at them again in > this cycle, but could find them at any point in the next. > > Just bumping the target milestone would address part of the problem: it > would help exclude it from bug lists that need fixing in this cycle. > However, it wouldn't help locate these bugs during the next cycle, since > at some point GCC8 will be out and the target milestone for all unfixed > bugs will be bumped. Also, when we get to GCC9 stabilization, it would > be nice to have some means to defer again any bugs that, during the > earlier stabilization cycles, were deemed unfixable in the stabilization > phase, so as to defer them again. > > Any thoughts on how to mark such bugs in bugzilla?
Add a 'defered' keyword? Richard. > -- > Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ > You must be the change you wish to see in the world. -- Gandhi > Be Free! -- http://FSFLA.org/ FSF Latin America board member > Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
