On 11/25/2016 02:15 AM, Richard Biener wrote:
That's a good question ;) The stage 3 definition has a loophole via
"go file a bug about feature X, then it's a bugfix!".
Right. That loophole has existed since we've moved to the current model
-- we extend a level of trust to our developers not to abuse the
loophole. I think that level of trust is warranted and hasn't been
significantly violated.
I'm all open for a more sensible definition, like constraining the kind
of non-regression fixes that we want to allow, but I fear the most
sensible option would be to simply ditch the notion of different
"stages" and make it "general development" and "regression fixing".
(though if you try hard enough and go back in time you'll find that
almost all non-enhancement bugs are regressions in some sense)
Similarly, I'm always open for improvements. My worry is if we went to
development/regression bugfixing cycle, then non-regression bugs would
largely be ignored.
General bugfixing is, IMHO, a good period -- it gets a larger portion of
our developers fixing bugs and gives folks with a heavy review load a
chance to flush out their queues of stuff that came in right at the end
of stage1.
I'm not really pushing to open a "development cycle" discussion right
now, but I do sense that our cycles could use some refinement.
And yes, current stage3 still feels too much like stage1 ;)
Hasn't seemed that way to me, but obviously experiences will differ. My
biggest worry about this cycle is the higher than typical (compared to
the last few years) regression bug counts.
That worry is somewhat mitigated by the belief that we're marking
regressions much much more consistently this year, so we're a lot less
likely to get a big jump in marked regressions like we saw last year.
*If* that is the case (and my light poking around seems to indicate
that's true), then we're likely ahead of the gcc-6 cycle, but behind the
gcc-5 cycle.
jeff
