I agree with Jianxia that a dashboard would be helpful. Not every bug that affects a release should necessarily be a release blocker. Factors like low severity, existence in prior versions and time to fix might all play a role in deciding that a bug should be fixed in a later version. So we need a way to track what issues are considered a release blocker separately from what versions are affected. Ideally we'd use something like a blocked-releases fields. We don't have that right now, so I propose we use a blocks-1.14.0 label.
I started on a dashboard that tracks these here<https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12336052>. Everyone should have access to view it. The dashboard shows all issues with the label. There are two lists one with open issues and one with resolved issues. I propose that we keep the blocker label on an issue if we resolve the issue, but remove it if we decide against resolving it in this version. In that case we might want to consider already tagging it with a future version (e.g. blocks-1.14.1), so that it stays top of mind. We should only do that though if we indeed want to fix it in that version. Once the list of open issues marked as blockers is down to a handful, we should revisit the discussion about cutting the release branch. If we agree that this is the right approach, I'll need all of your help in going back to open tickets and labeling them as release blockers where appropriate. How does that sound? ________________________________ From: Jacob Barrett <jabarr...@vmware.com> Sent: Monday, January 4, 2021 16:40 To: dev@geode.apache.org <dev@geode.apache.org> Subject: Re: [DISCUSS] Geode 1.14 > On Jan 4, 2021, at 3:42 PM, Owen Nichols <onich...@vmware.com> wrote: > > How to tell whether develop is stable? Same way we tell if a release branch is stable. Listen, cutting a release branch from the develop branch shouldn’t result in weeks worth of stabilization of the release branch. That is a smell that we have bad things going into develop. If there are bad things in develop then we are introducing new things to develop on top of bad things, which will just end up being more bad things. It isn’t cut or dry. I am not saying release from develop on an arbitrary day. I am saying we know develop isn’t stable. We know a release branch will take weeks to repair. Lets turn that around, lets make develop stable so a release branch takes days to release, not weeks. Yes there will be issues found on a release branch that have to be fixed but that should be an exception, not the norm. -Jake
