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?


> --
> 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

Reply via email to