Re: [side tags] Undesired automatic side-tag removal happened - how to deal with it in the future?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



So, just to add some data... sidetags are cleaned up via a cron job that
calls: 

/usr/sbin/koji-sidetag-cleanup --empty-delay=14 --old-delay=30

So, it should have only deleted it if it was empty after 14 days, but it
looks like it deleted it with things tagged into it. ;( 
Would you be willing to file a koji bug on this? 
( https://pagure.io/koji ) or if you prefer I can. 

On Mon, Oct 10, 2022 at 02:08:26PM +0200, Adam Williamson wrote:
> On Mon, 2022-10-10 at 21:02 +0900, Mamoru TASAKA wrote:
> > Zdenek Dohnal wrote on 2022/10/10 17:17:
> > > Hi all,
> > > 
> > > I maintain qpdf in Fedora, which recently got a new major release version, which breaks compatibility with other packages, so I created a side tag for other maintainers to use for building, and then releasing it altogether in rawhide.
> > > 
> > > However the side tag:
> > > 
> > > f38-build-side-58658
> > > 
> > > 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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux