As a fedora-infra member, I want to have datagrepper's packaging automated.

[StephenCoady]

Acceptance Criteria

• packit.yml is added to the project
• once added, we can successfully create released rpms for datagrepper
• https://src.fedoraproject.org/rpms/datagrepper is updated by packit

[TomasTomecek]

I hope this is a good place to follow up on your question @LenkaSeg from #packit IRC. I'm on a train right now with flaky internet connection, so wanted a more persistent communication channel 👼

Your question (for context for others) was about the fact that datagrepper has a downstream patch which causes you build problems here in the upstream repo. Unfortunately, we don't have an out-of-the box solution for downstream patches in Packit. Although we have source-git that works with downstream patches quite nicely.

I can see a few possible solutions:

1. Drop the downstream patch, merge it upstream (or fix the test case so that it works both upstream and downstream: I can see the patch is still not merged in the develop branch)
2. Have a maintenance branch here in the upstream repo that will track your downstream counterpart and have the patch applied in there

Nevertheless, both solutions revolve around dropping the patch from the spec file here in the upstream as it will cause neverending problems. I'd say that downstream patches are solid short-term solution but if you are in control of both channels: upstream and downstream, they cause more problems than they solve - you can always create a new patch release in upstream if something breaks downstream.

I hope this makes sense. Please let me know if this is clear.

[StephenCoady]

Thanks for that detailed answer @TomasTomecek. It's really helpful to have all options laid out.

I had been thinking about this recently myself, and I think we are probably in a better situation than most who face this. For this initiative, we are only considering applications that we own and maintain. While we might not directly own the downstream package I believe for the most part we are close to the people that do, or at least they are also involved in the maintenance of upstream. In this way, I think it's probably in everyone's best interest to have a single source of truth - upstream.

I'll bring this to the team's attention soon and we can gauge how on board everyone is. I've already mentioned bring the specfile upstream to make versioning etc easier and nobody seemed to have any issue.

Out of interest, is this the recommended way to work with packit - single source of truth upstream? I've seen some of the linked projects in your docs doing it differently.

[TomasTomecek]

Out of interest, is this the recommended way to work with packit - single source of truth upstream? I've seen some of the linked projects in your docs doing it differently.

I cannot answer this easily 😁

You are right that projects do things differently usually due to their nature. Nevertheless, dist-git is the canonical source of truth for our distributions. Though that doesn't stop folks automating working with dist-git and having upstream being "their source of truth" (while dist-git is just a "database" referenced from the build system and the real development & maintenance happens upstream).

We, and some other teams, found that automating the downstream release process as much as possible and only doing work upstream saves you most of your time and makes the release process straightforward. Sadly not everyone can do this.

We're happy to work with you and advise, let us know how can we help.