Currently milestone updates in blockerbugs are done entirely manually through the admin web UI (usually by me). This is dull and sucky work and we should automate it.
There was some discussion in #114 , this is a separate ticket to spin it out. The way I think I'd conceive of this is just defining what the set of active and current trackers should be at change points, assuming that any tracker which does not yet exist in the app is automatically added, and any tracker not listed which is currently active gets deactivated:
That's really it. Note the "N+1" trackers are also created at "N-1" release time, so that would need to be co-ordinated. That's currently scripted but not automated: all you have to do to create the tracker bugs and update the wiki page is run that script, but nothing currently automates it, I do it manually each cycle. Updating blockerbugs should obviously run after that script.
The only tricky parts here, I guess, are release detection and authentication. We do not currently have any great way to tell when Beta releases happen, that I know of. There are ugly hacky ways you could do it but I don't particularly like any of the ones I've thought of. There are kinda-OK ways to tell when official releases happen: this is a path I've been down extensively with fedfind and @frantisekz has been down with oraculum. Currently the way fedfind is doing it is just to refer to a bit of JSON I update manually. I can extend that to cover Beta releases, one way or another.
As for authentication, to automate blockerbugs work obviously the thing doing the work needs to be part of blockerbugs itself or have some kind of permanent auth capability. If we also want to automate the tracker creation, which we'd kinda have to do if we want to automate the blockerbugs work (as opposed to just scripting it), whatever does that needs permanent auth to Bugzilla and the wiki. I believe the openQA server has that at present, I don't know of anything else that does.
Metadata Update from @adamwill: - Issue priority set to: Normal - Issue tagged with: task
Obviously for release detection the best thing would be if we had something publishing fedora-messaging messages at release cycle change points. This is something I've talked about with @mohanboddu and @kevin many times and we should really get around to making it happen. The trickiest part of that is designing it to be sufficiently flexible to allow for release process changes while still being usable, and making sure it's accurate by making sure the data gets updated/bot gets poked/whatever when each 'release event' happens.
Filed https://pagure.io/releng/issue/9867 for that.
So, perhaps an unimportant detail, but why do you want to create the N+1 milestone in BBA at N-1 release time? At that time, N == N+1 == Rawhide. Doesn't it make more sense to separate them at Branch time, i.e. when N == Branched and N+1 == Rawhide?
And back to the main topic, how important do you think it is that this update needs to happen automatically? Because it's an event that happens a few times per year. If you can run your script to create the new trackers in bugzilla and update the wiki page, and then poke us, we can then run a command on the BBA server which will download some json and update the milestones. It shouldn't be difficult to implement and could be "good enough", compared to the difficulty of implementing a fully automatic process.
There are kinda-OK ways to tell when official releases happen: this is a path I've been down extensively with fedfind and @frantisekz has been down with oraculum. Currently the way fedfind is doing it is just to refer to a bit of JSON I update manually. I can extend that to cover Beta releases, one way or another.
Huh... oraculum has it automated via fedfind ( fedfind.helpers.get_current_stables() to be exact ), didn't know you were updating source for that manually :)
The related code is here: https://pagure.io/fedora-qa/oraculum/blob/master/f/oraculum/utils/dashboard_helpers.py#_101 and the exposed api: https://packager.fedorainfracloud.org:5000/api/v1/releases
(I'll reply in releng ticket after I read through it).
Doesn't it make more sense to separate them at Branch time, i.e. when N == Branched and N+1 == Rawhide?
+1 IMO
And back to the main topic, how important do you think it is that this update needs to happen automatically?
I'd say we should automate as much as possible. These are the sorts of things you need to think about and that distract you. There are multiple places/people/teams in Fedora which could make use of having single point of truth for "What are current Fedora releases and their attributes (including branched/pre-beta/freezed?)" . Having automation done in blockerbugs once there is such single point of truth should be piece of cake... based of what I've done with bugzilla api in oraculum.
So, the reason I do it that way currently is that I have to update the trackers to some extent at stable release time anyway - we have to move the 'current' aliases to the N release, and move the N-1 trackers to the "past trackers" section of the Housekeeping/Trackers page. (There might be something else that has to happen, I forget, since I scripted it so I don't have to remember any more! But at least that :>) Since that has to be done anyway, we may as well create the N+1 trackers and add them to the wiki page at the same time - it doesn't hurt anything and it means I only have to remember to "Do Tracker Stuff" one time per release cycle rather than two times. The only drawback to creating trackers a long way ahead of time is if things about the release process change in the meantime such that the tracker is wrong or obsolete somehow; this isn't terribly likely to happen between "N release" and "N+1 branch point", so the downside is pretty minimal.
There's no particular reason the trackers need to be added to BBA at the same time they're created, but again I just do it that way because then I don't have to remember to do it later :)
If this was automated rather than scripted we could do it that way, I guess. It'd be a micro-optimization.
Right, which is why I phrased this issue as "Script/automate" rather than "Automate". Of course, scripting it helps automate it: we can certainly script it before we can automate it, and then when we can automate it, all the automation has to do is run the script.
The advantages of automating it over scripting it, to me, are to deal with puny human frailties. If it's not automated, we need there to be one or more humans who know that the scripts need running and when, and who remember to run them. When those humans move on to other jobs, they have to remember to pass those responsibilities off to other humans. If any of that goes wrong, it doesn't happen.
Of course, even if we automate it, ultimately a human has to fix things if the automation breaks or we change the release cycle such that the automation/scripting needs changing. But that should happen more rarely.
Just scripting it without ever getting to the automation would still be a big win, though. It'd be like 80% of the total benefit, I guess. Automating it would be a cherry on top.
There are kinda-OK ways to tell when official releases happen: this is a path I've been down extensively with fedfind and @frantisekz has been down with oraculum. Currently the way fedfind is doing it is just to refer to a bit of JSON I update manually. I can extend that to cover Beta releases, one way or another. Huh... oraculum has it automated via fedfind ( fedfind.helpers.get_current_stables() to be exact ), didn't know you were updating source for that manually :)
I didn't used to. It started out using https://admin.fedoraproject.org/pkgdb/api/collections/ , which was a real endpoint of the pkgdb app and happened to work fine for the purposes we used the fedfind function for. Then that stopped being an actual app API endpoint and instead starting being a bit of JSON someone updates manually, and of course that meant sometimes someone forgot to update it or updated it wrong, and stuff broke. That was supposed to be a short-term thing and PDC was supposed to take over the job, but it never did, so the short-term thing lasted years during which I'd have to ping releng every so often to update the JSON when I realized it was outdated or broken. Then there was a short interregnum where I tried using Bodhi instead, but that turns out not to work very well because we set releases to "stable" in Bodhi a couple of days before they're actually available in the expected location in the public repos, and that breaks several things that trust fedfind about what releases are "stable". So I figured if we didn't have any good system to use and were just going to use hand-curated JSON, I'd at least use hand-curated JSON that I hand-curated myself and didn't have to ask someone else to fix every time it turned out to be broken (I can push a fix for the collections JSON to the ansible repo, but I can't run the playbook that actually updates it on the live webserver). Hence the current state of affairs.
BTW, after writing up the whole "let's have a thing that tracks releases" problem in the releng ticket, I decided to just go ahead and build it. So if I manage to get that completed and deployed and get Beta releases hooked up to it, that would make this automate-able.
OK, IIUIC we're now blocked here on having the JSON including tracker numbers as a minimum. Once we have it, we can work on implementation in BBA.
I'm not intending releasestream (or my manually-edited json, which releasestream is intended to replace) to provide that sort of info. The blocker bug numbers are reliably discoverable via the aliases, so I would just have the scripting use those (or even just query on the aliases and not need to be told the bug numbers at all, if it's an equally efficient query).
Issue tagged with: next
Log in to comment on this ticket.