On 23.08.2011 20:07, Mark Phippard wrote: > On Tue, Aug 23, 2011 at 1:52 PM, Hyrum K Wright > <[email protected] <mailto:[email protected]>> wrote: > > In theory, we could end up shooting ourselves and our users in the > feet by scuttling every RC between tag and release as issues become > known. That's obviously a bit absurd, but it's worth asking where we > draw that line? > > > This is my problem too. During the RC cycles we are always so > sensitive to these bugs, as if we are going to have a perfect release. > We all know we could find issues in our tracker that are just as bad > as these we have been discussing and we also know that once we release > the software we do not treat these bugs with the same urgency. We try > to react relatively quickly to bugs that could cause DoS or other > exploits, as well as dataloss bugs but those are all pretty rare and > not what we are talking about here. For normal bugs if this nature > they would not show up in a fix release until enough similar fixes > have been nominated and backported to warrant a new release. > > I am also fine with a re-roll though I would like to see us clear > STATUS if we do. Meaning, let's remove the items that are not going > to be in 1.7.x and get the votes for the rest. Otherwise, why not go > with the RC we have (which already has the required votes for release).
I wonder if it even makes sense to fix this case for upgrade. After all, we could just tell users to unlock files before upgrading their working copies. -- Brane
