On 23.08.2011 20:07, Mark Phippard wrote:
> On Tue, Aug 23, 2011 at 1:52 PM, Hyrum K Wright
> <hyrum.wright_at_wandisco.com <mailto:hyrum.wright_at_wandisco.com>> 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
Received on 2011-08-23 21:03:49 CEST