On Wed, Jul 19, 2017 at 5:57 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote:
And I agree with you, perhaps with one small exception. It depends on your definition of "help", but the delay *is* sometimes effective in a sense that without the delay (and the force function), the fix would not appear fast (in stable updates shortly after release) or even at all. It is not a good way to approach things, but I don't see many other options. Developers' time is limited and blocker bugs do set project priorities. I agree that it should definitely be used very conservatively.On Wed, Jul 19, 2017 at 12:24:16PM +0200, Kamil Paral wrote:
> > Another consideration that might be relevant: is this a *new* issue or
> > something that also affects the current release (either as released or
> > with updates)? If something is a clear-cut blocker criterion violation
> > but isn't a regression *and* we're running late, using further release
> > delay as a forcing function feels like cutting off our nose to spite
> > our face.
> I'm not in favor of this one. Too many important bugs have been waived in
> the past (even those easily fixable) just because "it's not a new bug". I
> don't see why it should matter. Sure, we can use the existing data to
> better estimate the impact (how often people complain about this, bug
> duplicates, etc). But that's just better input data. It should not affect
> the decision process. Or is the thinking process something like "users are
> already used to suffer from this bug, and perhaps can even work around it,
> so we don't need to try that hard to fix it"? I don't agree to that.
We should definitely fix these things. I just think that delaying the
release is a very big hammer -- in a case where maybe a hammer isn't
even called for. Delaying the release means that users are denied all
sorts of other improvements, and developers can't get their stuff in
the hands of users. The release delay itself doesn't _help_ the fix in
any way. We're just using it as a forcing function, and I think that
causes more problems than it actually solves.
But all of that above is a separate problem. What I'd like to understand is why you think existing bugs should be treated differently from new bugs. What is the rationale? And if you want to treat them differently, then how? Because if we accept new problem A as a blocker, but waive problem B because it has already existed for some time, even though they have completely equal impact on users, then without any other means to push for B resolution during the lifetime of the fedora release, it's very likely that the problem will not get fixed. Do you see PrioritizedBugs as an efficient way to help this? Or something else?
_______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
