pagure

#4714 allow declaring bumpspec and %changelog entries in src.fedoraproject.org PRs
Opened by praiskup. Modified

Open
Close Issue

This is the most painful thing WRT pull-requests in src.fedoraproject.org:

Should I bump the Release, and fill %changelog? ... when I don't know
when the PR will be merged?

It would be nice to have fields for this in the UI:

    [x] bump the release          (checkbox)
    [   ] re-set release to       (line edit)
    [- changing X towards Y     ] (textarea)
    [- some other               ]
    [- some other               ]

Once such PR would be merged, the %changelog and Release would be adjusted
accordingly.

I don't think we want to be "special" here in the core of Pagure. Maybe an extension for people who use a workflow of manually managing changelogs and Release fields?

For example, $DAYJOB uses the Open Build Service, and the build system imposes what the Release value is set to in each package build, so we don't generally change it.

And with changelogs, nobody in the Mandriva family uses the %changelog section. They've been generated from version control since 2008 (if not earlier!). So this wouldn't apply in that case either.

(This matters because Pagure deployments can be in environments with either or both cases present!)
Edited by ngompa

adjusted how? new autocommit? secret rebase before merging?

adjusted how? new autocommit? secret rebase before merging?

Whatever works for others, I don't have opinion on this.

I just consider all solutions too magical. If anything, an implicit action that does it inside the PR before the merge and allows reviewing the changes before merging makes better sense to me.

Maybe an extension for people who use a workflow of manually managing changelogs and
Release fields?

Yes, I guess this should be per-instance opt-in. I don't think this feature is needed
in pagure.io, for example.
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.