= phenomenon = I noticed that the data that we return from https://admin.fedoraproject.org/pkgdb/lists/vcs will continue to grow at the rate of one line-per-package each release. This is due to keeping acls for EOL releases. This isn't yet causing a problem for the pkgdb server but I bet that clients who are getting this data would be happier if there was less of it.
= recommendation =
If we can assign a default acl to our old, EOL branches, I can modify pkgdb to only return vcs acl information for non-EOL releases. That way the file would grow at a much slower rate (as new packages are added. The number of releases in the file would stay fairly constant).
This needs to be coordinated with whoever is currently maintaining the gitolite scripts (us? rel-eng?). We may also want to pass it through fesco as it's a change of policy but I think they'll lean heavily on our recommendation for this.
Is the old acl data of any use? If so, would it make sense to move it to an archive table when a release goes end of life, and only have the main db note what branches existed?
Otherwise if the old EOL release acl data isn't needed, I'm fine with your proposal. ;)
Yeah -- it's only needed for the git repo. (Since branches are kept in the repo after EOL, something needs to determine whether people can write to those old branches or not.)
I don't really need to move this information to an archive table, (at least, not yet :-). I just want to stop adding it to the public data that gets downloaded via https://admin.fedoraproject.org/pkgdb/lists/vcs . The size of the data downloaded from that URL is about 5x what is downloaded for setting up bugzilla, for instance, and could be trimmed down quite a bit if we didn't need to keep EOL acl information there. It's not a big deal for our internal scripts. But it is a waste of time for people outside of our network that are trying to get package ownership information from that URL.
Fesco and infra both approve of this change. We think that the default gitolite acls will prevent anyone from modifying the old repos so that will be the default. The change to pkgdb will be entirely to one function so I'm marking this easyfix.
Function is here: http://bzr.fedorahosted.org/bzr/packagedb/0.5.x/annotate/head:/pkgdb/listqueries.py#L216
I could have a look on this, if i understand the exact issue :).
It seems that https://admin.fedoraproject.org/pkgdb/lists/vcs throughs 503 error that doesn't help.
Any more info?
Are you envisioning a script that is run at each release cycle and updates the database? What should the default ACL look like?
There's a script that takes the output of https://admin.fedoraproject.org/pkgdb/lists/vcs?tg_format=json and creates the acls for branches. That script should work with information on less branches (it'll only output acls for the branches that are mentioned. If the branch is not mentioned, whatever gitolite's default acl should take over... requires testing of course ;-)
So the change that I think needs to be done is removing the EOL branches from the information returned by https://admin.fedoraproject.org/pkgdb/lists/vcs?tg_format=json
Hey Guys - i'm new to the project and looking for some areas that I can contribute in. Has there been any movement on this? If not, i'd like to take it on.
It hasn't been worked on: https://github.com/fedora-infra/packagedb/blob/develop/pkgdb/listqueries.py#L215
What I'd like to see is an additional argument to that function to list end of life releases. By default it would not list end of life releases. So something like adding: eol=False as a parameter. Then in the code, selecting the subset of branches that exist at the non-eol branches by default.
Moving all currently open easyfix tickets to the HANDYWAVY-FUTURE milestone.
I'm clearing the assigned status on all easyfix tickets.
If you are an apprentice actively working on this ticket, feel free to reassign to yourself. Otherwise let a new apprentice have a look.
This was completed with the move to pkgdb2 I am pretty sure. Feel free to re-open if I was mistaken.
Login to comment on this ticket.