I want to address a few comments in particular: > Kevin Fenzi: > I'm prefer to add a new milestone of 'day before release' and put it > there. The current schedule starts the "create the release announcement" on the day of the Go/No-Go meeting. I don't think that makes much sense: the announcement can be pre-written and edited to track changes in release dates or Changes status. I'll go ahead and move that to *end* on the Go/No-Go day. My concern remains what happens if the announcement isn't ready by the deadline? We either proceed like we've done in the past and risk a rush to publish at the end, or we declare the release No-Go, in which case there's no practical difference from what I propose. > Adam Williamson (out of order) > 1. I'm fine with the overall release process blocking, in some sense, > on things like release announcements not being done. > > 3. The Go/No-Go meeting is not necessarily the best place to decide on > this, but I'm open to it being chosen. The Go/No-Go meeting is the only real decision point we have, so IMO it makes sense to add this in there. The Release Readiness Meeting is more informative than decision-making (although it sounds like it may be time to revisit that meeting more broadly, so maybe we change this?) > More Adam Williamson > 2. I believe this should **NOT** be handled through the things actually > called the "Fedora Release Criteria" and the process for nominating and > reviewing "release blocker" bugs. Agreed. To be clear, that is not what I am proposing. I've probably been sloppy in my wording, but I'm thinking of this as a criterion exclusively for the Go/No-Go process. > Mohan Boddu > I guess we can just consider as a soft criteria and if its not ready, we will just ask people to help marketing team and get the article ready by Friday or Monday. Right. If it's "close" (for some value of close) then Marketing can say they are go and get it finished by Monday. Of course, the counter-argument to this is that a squishy criterion that we can just accept if we want to isn't much of a criterion. -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
