I had a handful of packages that I'd retired during the F25 cycle; their last branch that didn't have a dead.package was Fedora 24. (They don't have F26 branches at all).
Today, during the F27 branching, I got fedmsg notifications that F27 branches had been created for these packages. Sure enough, I checked the repository and there's a f27 branch containing nothing but a dead.package file. To the best of my knowledge, the packages had been properly retired (like I said, they had no F26 branches), so this seems like something that shouldn't happen.
Packages in question are:
Apparently this is not already a known issue so I was told to file a ticket.
Same with Django14
That wasn't foreseen but seeing the script we hacked up for the mass-branching it isn't surprising.
The script basically created a new branch for all the repos in dist-git regardless of their status.
We'll need to address this correctly for the next mass-branching (most likely integrating this with the script updating PDC for the new branch).
It would be nice to be able to delete these branches, for the sake of tidiness...
Also happened to my retired packages:
I second @pghmcfc's comment, it would be nice to be able to delete these branches.
Metadata Update from @pingou: - Issue tagged with: src.fp.o
@ralph @mprahl Can we perhaps at least retire them all again so they don't keep having branches longer?
@kevin the entries aren't in PDC, so I can determine which f27 branches exist in dist-git but not PDC.
@pingou, if I give you that list, would you be able to delete the branches in git?
Sure thing :)
Okay, it's in my backlog now to write a script to get @pingou the list. I have some other tasks that I need to complete before getting to this but it shouldn't be too long.
I uploaded an output file with all the packages that had the master branch retired in PDC before the mass branching date for f27 but had an f27 branch in dist-git. I've verified a handful of them and it looks correct but @pingou please verify. I've also uploaded the script that I wrote to get these results.
<img alt="output.txt" src="/fedora-infrastructure/issue/raw/files/1d6cfadf1f3951d98e6c0395ced16038b74935ed35feea0f32d315db0b1c07e0-output.txt" /> <img alt="get-f27-branches-retired.py" src="/fedora-infrastructure/issue/raw/files/331fecfab7e9d2455b8283dc3c197e0b05f607c021f35b8d6d1eb7a5ec0b9025-get-f27-branches-retired.py" />
I processed all the ones that had orphan as main admins.
I want to do some more checking on the others (947).
Any news here? Are we done now, or still some checking to happen?
The remaining 947 still need to be processed indeed :)
Metadata Update from @kevin: - Issue assigned to pingou - Issue priority set to: Waiting on Asignee
We've just branched f29 and this is still pending.
Is there a point fixing this now or should we just leave it as is and close this ticket?
Primarily these stray branches just make determining whether a package is actually dead and gone a bit difficult. Once F27 is EOL, even that won't matter.
So at this point I don't see what it's hurting. If we could get pagure to by default hide the EOL branches then this would be little more than a historical footnote once F27 goes away.
Pagure grays out retired branches at the moment
Yes, but of course the branches which are the topic of discussion aren't greyed out. I assume the decision of which branches get the "disabled_branch" class is global and not per-repository, so these errant branches will show as live until F27 is EOL.
(Personally I'd prefer to completely hide the EOL branches behind an interface toggle to keep the lists of reasonable length, as packages dating back to the days of Extras have a lot of branches. But that's completely off topic.)
ok then, I am gonna close this out... if there's a pagure change needed, please file it upstream.
:crocodile:
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.