Given the relatively static nature of the release blocking deliverables and the volume of information on the wiki page for each release, I propose that we maintain a static list of release-blocking deliverables instead of polling teams and submitting a FESCo ticket for each release.. This page would be updated when a Change proposal is approved that includes a modification to the list. The page would only include blocking deliverables for ease of readability.
This would not preclude teams from maintaining a list of non-blocking deliverables for their output if they desire.
Could you please explain the current process a little bit? I see this:
Fedora Program Manager is responsible to copy this page for each Fedora release and confirm it's correctness with each Working Group (or SIG/individual in such case).
How does it actually work for you?
The way it works now is that I:
It's not the biggest use of my time, but it's a process that does not seem to add value. Given that both teams and FESCo seem to generally react with some variation of "shrug, LGTM", I don't seem to be alone in that opinion.
File a Pagure issue or send an email to each responsible team
What do they do?
shrug, LGTM
Pretty much my feeling, that's why I ask.
May I suggest that we still have a defined day (1 week before Beta Freeze, or whatever) when we send an announcement that "list of deliverables is set, it is the same as before, see it here".
This way people would know that it exists, and they will have a trigger to think if they would like to reconsider it in the next release. They can go and start the conversation.
This will eliminate the need for poll each team, file bugs and etc, but will keep public awareness that this list exists and can be changed.
@bookwar that's a good suggestion. I have no problem with sending an announcement of what the blocking deliverables are. I think maybe the branch point is the natural place in the schedule for that. Modifications — particularly additions — should have been submitted as Change proposals by then, but it still gives us a little bit of space to make last-minute edits if it's an urgent issue.
I have no problem with sending an announcement of what the blocking deliverables are. I think maybe the branch point is the natural place in the schedule for that. Modifications — particularly additions — should have been submitted as Change proposals by then, but it still gives us a little bit of space to make last-minute edits if it's an urgent issue.
+1 for me to switch from polling to announcement
+1
+1 too
I think the orig idea was to make it easier to drop older stuff from release blocking when no one responded about it, but I agree it's not really working too well, so sure we can go to an announce model, but we should try and make sure we look it over and see if there's things we need to drop/add each cycle.
This was discussed during today's FESCo meeting: AGREED: Proposed change to the process is approved (+6, 0, 0)
Metadata Update from @zbyszek: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.