Rpmautospec (%autorelease and %autochangelog) is recommended as the default approach. Packaging Guidelines and other documentation are adjusted to describe this approach first. Various tools that provide spec file templates are adjusted.
Owners, do not implement this work until the FESCo vote has explicitly ended. The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed. See the FESCo ticket policy and the Changes policy for more information.
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.
Metadata Update from @churchyard: - Issue tagged with: meeting
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.
I don't understand the problem here. Can't RHEL copy the changelog from rpmautospec generate-changelog?
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.
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?
rpmautospec
rpmautospec unconvert
+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 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.
changelog
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)
Metadata Update from @zbyszek: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.