Yeah, the statement "we want to release ASAP" was quite scary to read. Did I miss something? When do we cut GA? ASAP is like next week? What is going on? Help! :D
On Sat, 28 Mar 2020 at 22:00, Joshua McKenzie <jmcken...@apache.org> wrote: > > > > 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 > > > > >
