Until the RHEL problem is solved, I cannot in good conscious vote for this. -1

Isn't the RHEL problem already present even if we don't recommend %autochangelog by default?

It is, but making it opt-out massively amplifies the problem.

Which might accelerate the need to fix it on the RHEL side :)

I agree with you that this needs to be fixed on the RHEL side. I just don't think we should avoid nice things in Fedora because of that.

Tagging with meeting due to a negative vote.

I myself am not convinced this is a good idea because the CPE team developed this and then seemingly abandoned the maintenance. Seeing the CPE developer as the owner of this change gives me some hope, but "Nils will add some co-maintainers" does not spark confidence in me.

I myself am not convinced this is a good idea because the CPE team developed this and then seemingly abandoned the maintenance. Seeing the CPE developer as the owner of this change gives me some hope, but "Nils will add some co-maintainers" does not spark confidence in me.

If I volunteer to be one of those co-maintainers, would that help with your confidence? I'd really like to see this happen.

If I volunteer to be one of those co-maintainers, would that help with your confidence?

Yes.

Until the RHEL problem is solved, I cannot in good conscious vote for this. -1

I don't understand the problem here. Can't RHEL copy the changelog from rpmautospec generate-changelog?

Until the RHEL problem is solved, I cannot in good conscious vote for this. -1

I don't understand the problem here. Can't RHEL copy the changelog from rpmautospec generate-changelog?

Technically they can, but they don't.

Until the RHEL problem is solved, I cannot in good conscious vote for this. -1

I don't understand the problem here. Can't RHEL copy the changelog from rpmautospec generate-changelog?

Technically they can, but they don't.

That's a shame. It's pretty trivial to do so. I was playing around with the specfile Python library yesterday and wrote a script to remove rpmautospec from a specfile: https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/un_rpmautospec.py

I agree with @ngompa that maintaining attribution is important.

I don't understand the problem here. Can't RHEL copy the changelog from rpmautospec generate-changelog?

https://github.com/fedora-eln/distrobaker/issues/12

I was playing around with the specfile Python library yesterday and wrote a script to remove rpmautospec from a specfile

I think we should have this as part of rpmautospec itself: rpmautospec unconvert or something like that. Any chance you can turn your script into a PR?

+1 here. I agree RHEL should fix that import issue, but I don't think we should wait / conventionalize on it.

+1 from me (I realize I didn't make it explicit above)

+1

Switched to rpmautospec as soon as it was available and it's a big time saver (and reduces human errors, which I seem to make often).

+1 (as change owner)

I reached out to some people in RH internally about the issue with imports. I'll report here if there is any progress.

If I volunteer to be one of those co-maintainers, would that help with your confidence?

Yes.

Do you volunteer? There is e.g. this https://pagure.io/releng/issue/11218#comment-835751 which has an open pull request for 2 months.

If I volunteer to be one of those co-maintainers, would that help with your confidence?

Yes.

Do you volunteer? There is e.g. this https://pagure.io/releng/issue/11218#comment-835751 which has an open pull request for 2 months.

I do, and I'm looking at that patch. I'm not convinced it's enough to fix the shallow clone issue though.

I think we should have this as part of rpmautospec itself: rpmautospec unconvert or something like that. Any chance you can turn your script into a PR?

I submitted https://pagure.io/fedora-infra/rpmautospec/pull-request/287 last Wednesday.

Sorry again for not replying earlier, I was abroad when this was filed and the current project kept me busy afterwards.

In short, I don't think that supporting official builds from shallow clones is possible because the metadata of all commits (after the last time an overriding changelog file was modified in the repository) is used generating the changelog, as well as computing the current and previous release numbers. I've described the effects in a little more detail here.

Please, let's not discuss shallow clones support here. I've merely used as an example that this project needs more active maintainers.

This will be discussed during the meeting today.

@nphilipp ^

This was discussed during the meeting today:
AGREED: APPROVED (+6, 0, -1)