#64 RFE: track next release starting at branch
Closed: Fixed 4 years ago Opened 4 years ago by jskladan.

Originally created here, by @mattdm moving to the right place.

From this list discussion...

As we move into the No More Alphas world, and in trying to think about issues/bugs in a bigger picture than a single release (like, the "if we waive a blocker for some reason, it automatically applies to the next release" thing), it would be really helpful if we had a tracker for the next development release as soon as Rawhide branches (so, an F28 blockerbugs tracker when F27 branches).

This would be very valuable for my (and, I think, for Fedora Program Management)'s tracking of the planning/development/release cycle.


I'm not sure I understand what's required. The bugzilla tracker bugs already exist for future releases (@adamwill maintains those):
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers
and the blockerbugs app already lists Fedora 27:
https://qa.fedoraproject.org/blockerbugs/

What's missing?

As I understand it, at least, Matt wants to be able to look at the blockers for the next next release - so right now, he wants to be able to see F28 as well as F27. I told him that we tried doing a kinda rolling 'next three milestones' thing for a bit (so we'd have e.g. F26 Beta / F26 Final / F27 Alpha) but it caused various bugs so we stopped doing that, and he suggested having another instance of blockerbugs, so we'd always have two: one for the next release, and one for the next next release.

That's why I told him to file against fedora-qa, as well - it's not actually a request for blockerbugs the codebase, it's a request for us to set up a second deployment of blockerbugs.

Of course, @mattdm , please correct me if I'm misunderstanding.

Yeah, that sounds right. If we can do it in the codebase that would be just fine too.

well, as I mentioned, in theory we can have as many milestones as we like active at once, but in practice we found various bugs happening when we had milestones from more than one release. So I guess it's a question of either finding and fixing all those bugs, or just having two instances.

OK, so Rawhide and Branched should be always visible, correct? I know about just a single bug preventing that - #62 . Adam, do you know about other ones? I find it easier to fix that bug rather than to maintain another instance. Thoughts?

Oh sorry guys, bad number in commit message (#64 instead of #62), but still related.

Reopening. #62 got fixed (not completely, but should be enough), we need to get it packaged and deployed. Then we can enable Rawhide milestones as well. Kudos @lbrabec for fixing this.

Metadata Update from @kparal:
- Issue status updated to: Open (was: Closed)

4 years ago

Well, one thing I can remember is that having milestones from more than one release at once broke the display of updates (you know, the right hand column where any update related to the bug should show up with its status). I can't recall if we fixed that one yet. I feel like there was at least one other problem, but I don't remember what it was. Sorry to be vague :/ I mean, we can just do it, and see what happens, I guess.

Metadata Update from @kparal:
- Issue assigned to kparal

4 years ago

I'll try to deploy a new version soon and we'll see.

We've deployed new blockerbugs version and I've enabled F28 milestones. Please try to use it and file bugs if something doesn't work. Thanks. I assume this is resolved, closing.

Metadata Update from @kparal:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

4 years ago

Login to comment on this ticket.

Metadata