Koji devs forwarded me to releng pagure, so there is a new issue for
this https://pagure.io/releng/issue/11093 .
On 10/14/22 12:57, Zdenek Dohnal wrote:
Hi Kevin,
I've created the issue https://pagure.io/koji/issue/3554 for the problem.
I agree with docs update (maybe it would be nice as well mention the
side tag disappears once the packages are in stable, so users don't
have to try removing it :) ) and the script update (adding
--inactive-delay option, probably set to 21 days?)
Thank you for looking into it!
Zdenek
On 10/11/22 03:16, Kevin Fenzi wrote:
got automatically deleted, even when it had builds connected to it
already. Documentation [1] does not mention any automatic
side-tags cleanup and its deadlines.
We should update the docs. We did announce adding this.
Although packagers can create a new side tag easily, I found it
inconvenient for maintainers, because the synchronization among
the maintainers can take weeks to finish the rebuild and release
the update and automatic removal without notice (do excuse me if I
missed a notification email about this - I have many filters and
it could end up somewhere where I wasn't able to find it) prolongs
this process.
What I would like to propose are the following options:
A) don't do side-tag cleanups after a specific time frame, but
only when the specific event happens - branching, GA, EOL - it can
be consuming to our resources, but maintainer are still able to
remove the side tags manually in case it contains a big set of
packages and AFAIK the process itself is not such spread in usage...
Side tags are actually pretty costly on the server end. It means every
single time a build lands in the parent tag they have to have their
rpeodata regenerated. It's tons of newRepos. I'd prefer to clean them up
as quickly as we can, but no quicker. :)
or
B) do a side-tags cleanup and mention it in the documentation
together with specification what the removal's time frame is, so
maintainers can act accordingly
We should do this in any case.
or
C) (my preferred) Koji or releng (depends on whether the cleanup
happened automatically or manually) will send an email to a side
tag creator with 'Hi, your side tag is going to expire - do you
need it?' Or with automaton - 'use this command to prolong it.'
And if there is no response or if the creator approves, remove the
side tag.
Doable, but more notifications and things to deal with.
Note that sidetag cleanup has a newer option we aren't using yet too:
--inactive-delay=DAYS
delete tags inactive for DAYS (no build was
un/tagged
there)
We could perhaps use this.
IMO basically side-tag is not expected to exist for such a long
time, side-tag requester should
take effort to merge it into main buildroot within, say, one week
at most.
I'm not sure this is always going to be realistic. We are increasingly
encouraging folks to do big complicated rebases in side tags rather
than breaking Rawhide or Branched for days at a time; sometimes this
might take more than a week. I don't want folks to be discouraged from
using side tags and just go back to breaking Rawhide because of this
kind of cleanup.
I agree... I'm open to adjusting the cleanup script, but I do think we
should limit sidetags somewhat.
We should in any case document and fix the empty thing.
kevin
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
Zdenek Dohnal
Software Engineer
Red Hat, BRQ-TPBC
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
