> > since we want to release ASAP > Help me understand how to reconcile this statement with the fact that improvements and other nice-to-have optional tickets are being created and worked on in even 4.0-alpha as recently as this past week. While *you* and many others may want to release ASAP (including myself fwiw), this is a large project with a large number of participants and I think it inaccurate to speak for everyone.
Do we gain much by introducing yet another view on Jira that nobody will > properly maintain? > I don't share your belief that this will not be maintained, as I will be one of three people keeping an eye on maintaining a view like this for the hopefully small number of months leading up to 4.0 GA. It seems we currently have a state that is not being demarcated - what is MVP for scope on release vs. what is optional but targeting it. Rather than forcing peoples' tickets out of the release even if they still have every intent to get them in, I would prefer we have additional metadata and allow signaling of "targeting release" vs. "required for release". Alternatively, we could revert to using 4.0.X or 4.X as we once did to indicate something is targeting a release vs. blocking on inclusion for it. That seems to be a more "project JIRA hackish idiom", and one that's historically been confusing for people. At least with a label it would be clear with a name like "4.0-blocker", and we could then easily filter the JIRA board on it. On Sat, Mar 28, 2020 at 2:52 PM Benedict Elliott Smith <bened...@apache.org> wrote: > I would personally prefer we simply bump tickets from the milestone > periodically. The point of a milestone is to collect tickets we expect to > land there, and since we want to release ASAP we should have at most a > handful of optional items there sponsored by some community members, so the > burden should be low. > > Do we gain much by introducing yet another view on Jira that nobody will > properly maintain? It sounds like a classic situation of having one > problem, and simply ending up with two problems. > > > On 28/03/2020, 18:44, "Scott Andreas" <sc...@paradoxica.net> wrote: > > Yep that makes sense to me. > > There's still much work to be done to exercise 4.0 builds to identify > unknown issues that haven't yet been filed – but those items can be tagged > as release blockers as they're identified. 👍 > > ________________________________________ > From: Joshua McKenzie <jmcken...@apache.org> > Sent: Saturday, March 28, 2020 7:14 AM > To: dev@cassandra.apache.org > Subject: Idea: Marking required scope for 4.0 GA vs. optional > > As we're under a feature freeze but not code freeze, there are quite > reasonably tickets being opened for 4.0 (alpha, beta, or rc) that look > like > nice to haves for the release but wouldn't necessarily block cutting > GA. I > think there would be value in us flagging tickets that are required > for 4.0 > to get out the door as blockers - it looks like we don't have the > Priority > entry anymore (a good thing imo) but we could use the label field to > indicate which tickets are blockers and filter our JIRA board and > weekly > reporting on that. That would also help contributors know where to > focus > their efforts to help get 4.0 out the door while not stifling people > scratching their own itch on things leading up to the release. > > What do the rest of you on the project think? > > ~Josh > > B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB� > � [��X��ܚX�K K[XZ[ > � ]�][��X��ܚX�P �\��[� �K�\ X� K�ܙ�B��܈ Y ] [ۘ[ ��[X[� � K[XZ[ > � ]�Z [ �\��[� �K�\ X� K�ܙ�B�B > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
