For a simple workflow: Wouldn't something like "automatic_package_list:
True" in tag's config would do the work? Given tags package lists would be
extended in the moment of tagging package there with the pkg/author of the
build. Nevertheless, it will not solve the 3rd usecase - changing package
ownership will still be needed.
On Mon, Jan 10, 2022 at 11:50 PM Michael McLean <mikem(a)redhat.com> wrote:
This is something I've wanted to do for a long time, but it is
tricky to
get right. This is actually a really deep change in the Koji data model
(unfortunately).
The problem is that the package lists aren't just an access check for what
is allowed to be tagged, they actually filter what content is in the tag.
Remove a package from a tag and you don't just prevent future builds of
that package from getting tagged there, those builds actually stop being
reported by listTagged/etc.
We want to be sure that Koji reports the correct content for a tag at a
past event, and the history of the tag_packages table is part of that. I
think that the only way to sanely do this is to make the change from old to
new pkglist modality itself a versioned parameter of the tag (e.g. a new
field in tag_config).
It's also important to note that having an allowed package list is
actually a desired feature for a lot of tags. So we don't want to do away
with this entirely, but certainly there are tags where we might want a
simpler workflow.
It's also important to support blocking packages from being inherited,
which is also part of the pkg_listing table. Whatever solution we come up
with should also factor this in.
On Mon, Jan 10, 2022 at 4:18 PM Ken Dreyer <ktdreyer(a)ktdreyer.com> wrote:
> What if we removed the concept of package lists for tags in Koji?
>
> In other words, we would remove these concepts:
>
> koji add-pkg ...
> koji remove-pkg ...
>
> It's a lot of manual work to keep package lists (especially owners!)
> up-to-date. It's a simpler workflow if users can just:
>
> Step 1) Create a dist-git repo for a package
> Step 2) Perform a build of the package
>
> This would eliminate the following steps:
>
> - "Discover who the human owner will be"
> - "Ensure that human owner has a user account in Koji's database
> (possibly asking them to pre-create their account)"
> - "Keep the ownership records up-to-date over time" (for example:
> so-and-so has left the Perl team, how should that developer update
> Koji to stop getting emails?)
>
> - Ken
> _______________________________________________
> koji-devel mailing list -- koji-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to koji-devel-leave(a)lists.fedorahosted.org
> 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.fedorahosted.org/archives/list/koji-devel@lists.fedorahoste...
> Do not reply to spam on the list, report it:
>
https://pagure.io/fedora-infrastructure
>
_______________________________________________
koji-devel mailing list -- koji-devel(a)lists.fedorahosted.org
To unsubscribe send an email to koji-devel-leave(a)lists.fedorahosted.org
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.fedorahosted.org/archives/list/koji-devel@lists.fedorahoste...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Tomas Kopecek <tkopecek(a)redhat.com>
RHEL Build Development, RedHat