Yeah, I was thinking we'd add a new attribute "package_list" on each
tag, and it would default to "true" for existing tags.
And then over time, we'd transition more and more tags to "package_list:
false".
- Ken
On Tue, Jan 11, 2022 at 3:12 AM Tomas Kopecek <tkopecek(a)redhat.com> wrote:
>
> 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
> _______________________________________________
> 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