Re: rpmautospec by default
On Sun, Aug 7, 2022 at 3:23 PM Leigh Scott wrote: > > > On Sat, Aug 6, 2022 at 10:11 AM Zbigniew Jędrzejewski-Szmek > > > > > As the maintainer of rpmdevtools, I will probably not accept changes > > upstream to change to rpmautospec in the templates, since rpmautospec > > doesn't work outside of Fedora and there's been no advocacy to make > > rpmautospec a cross-distro tool. If someone wants to champion > > rpmautospec as a cross-distro tool, then I will reconsider. > > > I'm -1 if it means I can't use rpmdevtools with the old behaviour. I'm not sure what you mean here? Which program that is provided by rpmdevtools do you think will be broken? At least spectool and rpmdev-bumpspec support spec files that use rpmautospec. And I'm pretty sure the rest will just continue working (because the only one that reads / writes to "Release" and "%changelog" is rpmdev-bumpspec, which supports both "normal" packages and packages that use rpmautospec). Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.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.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rpmautospec by default
> On Sat, Aug 6, 2022 at 10:11 AM Zbigniew Jędrzejewski-Szmek > > As the maintainer of rpmdevtools, I will probably not accept changes > upstream to change to rpmautospec in the templates, since rpmautospec > doesn't work outside of Fedora and there's been no advocacy to make > rpmautospec a cross-distro tool. If someone wants to champion > rpmautospec as a cross-distro tool, then I will reconsider. > > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! I'm -1 if it means I can't use rpmdevtools with the old behaviour. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.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.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rpmautospec by default
On 07/08/2022 12:21, Fabio Valentini wrote: I think you're confusing the %forge macros with rpmautospec here. rpmautospec is actively (though, at times, slowly) maintained by nphilipp and other CPE members: https://pagure.io/fedora-infra/rpmautospec Oops, my bad. +1 from me then. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.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.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rpmautospec by default
On Sun, Aug 7, 2022 at 11:37 AM Vitaly Zaitsev via devel wrote: > > On 06/08/2022 16:10, Zbigniew Jędrzejewski-Szmek wrote: > > During the FESCo panel during Nest one of the conclusions was that FESCo > > should > > take a more proactive role in pushing changes in Fedora. We talked about > > enabling > > koschei by default and other similar things. Here's my attempt to start with > > something I hope will be somewhat easier: > > As far as I know, the author of rpmautospec left Fedora and no one is > going to fix dozens of bugs (the most important ones have already been > posted by Neil). > > I don't think it's a good idea to stick with an unmaintained stack, so > -1 from me until someone volunteer to take care of it. Then I'll change > my vote to +1. I think you're confusing the %forge macros with rpmautospec here. rpmautospec is actively (though, at times, slowly) maintained by nphilipp and other CPE members: https://pagure.io/fedora-infra/rpmautospec Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.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.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rpmautospec by default
On 06/08/2022 16:10, Zbigniew Jędrzejewski-Szmek wrote: During the FESCo panel during Nest one of the conclusions was that FESCo should take a more proactive role in pushing changes in Fedora. We talked about enabling koschei by default and other similar things. Here's my attempt to start with something I hope will be somewhat easier: As far as I know, the author of rpmautospec left Fedora and no one is going to fix dozens of bugs (the most important ones have already been posted by Neil). I don't think it's a good idea to stick with an unmaintained stack, so -1 from me until someone volunteer to take care of it. Then I'll change my vote to +1. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.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.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rpmautospec by default
Zbigniew Jędrzejewski-Szmek kirjoitti 6.8.2022 klo 20.19: On Sat, Aug 06, 2022 at 06:29:25PM +0200, Miro Hrončok wrote: On 06. 08. 22 16:10, Zbigniew Jędrzejewski-Szmek wrote: Let's make %autorelease + %autochangelog the default approach in Fedora packaging I still haven't got around to start using it, because I recall that initially there were problems I've reported or followed and nobody was looking into them. This got a bit better, but is still quite bad :( My experience was similar. Initially, I was excited about not having to tinker with the specfile changelog any more, so converted some packages to rpmautospec. Then I ran into issues, so I converted everything back to manual changelog. Also I got the feeling that issues were fixed slowly. The two issue ssI was tracking at the time [1,2] have since been marked fixed, though. [1]: https://pagure.io/fedora-infra/rpmautospec/issue/104 [2]: https://pagure.io/fedora-infra/rpmautospec/issue/189 I believe removing menial work from packaging workflow is really valuable, probably even necessary to keep things running in the future. But if some automation is recommended for all packagers, please make sure that people who follow that recommendation do have to regret. The following issues all bother me and nobody seem to have the resources to fix them or even look at them: https://pagure.io/fedora-infra/rpmautospec/issue/238 -- 9 months ago I mention this one in my wall'o'text above. It's something for fedora-review to fix. I don't think it's a blocking issue though: fedora-review is always slow with following new things and reviewers must always be prepared to ignore most of its output. The complaint about missing dist tag has been already fixed [1]. Is there something else that does not work in fedora-review yet? [1]: https://pagure.io/FedoraReview/pull-request/417# ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.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.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rpmautospec by default
On Sat, 2022-08-06 at 17:19 +, Zbigniew Jędrzejewski-Szmek wrote: > > But I don't think it makes sense to try to delay this. rpmautospec > is already widely used: > $ rg -l '%autochangelog|%autorelease' *.spec | wc -l > 2973 > So any shortcomings are already being felt by packagers. I use it in some packages, but I've also specifically *stopped* using it in other packages because of several issues (which I think were among those Miro listed). I share Miro's concern that it may not be robust enough to be the Recommended Way yet, and its maintenance does not seem strong enough. If there's significant progress on fixing the issues I'll try switching more packages over to it again, though. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.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.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rpmautospec by default
On Sat, Aug 06, 2022 at 06:29:25PM +0200, Miro Hrončok wrote: > On 06. 08. 22 16:10, Zbigniew Jędrzejewski-Szmek wrote: > > Let's make %autorelease + %autochangelog the default approach in Fedora > > packaging > > I still haven't got around to start using it, because I recall that > initially there were problems I've reported or followed and nobody was > looking into them. This got a bit better, but is still quite bad :( > > The following issues all bother me and nobody seem to have the resources to > fix them or even look at them: > > https://pagure.io/fedora-infra/rpmautospec/issue/105 -- 2 years ago I think this is fixed. See my comment in the bug. > https://pagure.io/fedora-infra/rpmautospec/issue/193 -- 1 year ago In the bug: > The Zuulpart is fixed. The Jenkins thing is not. Dunno, can you maybe test again? > https://pagure.io/fedora-infra/rpmautospec/issue/206 -- 1 year ago There's a pull request open. > https://pagure.io/fedora-infra/rpmautospec/issue/209 -- 1 year ago This should be fixable. I'll try to take a look later on. > https://pagure.io/fedora-infra/rpmautospec/issue/227 -- 1 year ago Same here. > https://pagure.io/fedora-infra/rpmautospec/issue/238 -- 9 months ago I mention this one in my wall'o'text above. It's something for fedora-review to fix. I don't think it's a blocking issue though: fedora-review is always slow with following new things and reviewers must always be prepared to ignore most of its output. > How can we ensure a permanent maintainer has dedicated time to keep the tool > evolving, before we start recommending it? Yeah, this is an important issue. Nils has been unreponsive at times ;( I hope we can find some way to improve this, maybe be opening up the maintanance to more people. Nils, comments? But I don't think it makes sense to try to delay this. rpmautospec is already widely used: $ rg -l '%autochangelog|%autorelease' *.spec | wc -l 2973 So any shortcomings are already being felt by packagers. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.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.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rpmautospec by default
On Sat, Aug 06, 2022 at 11:41:07AM -0400, Neal Gompa wrote: > On Sat, Aug 6, 2022 at 10:33 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Sat, Aug 06, 2022 at 10:19:19AM -0400, Neal Gompa wrote: > > > On Sat, Aug 6, 2022 at 10:11 AM Zbigniew Jędrzejewski-Szmek > > > wrote: > > > > > > > > Hi everyone, > > > > > > > > During the FESCo panel during Nest one of the conclusions was that > > > > FESCo should > > > > take a more proactive role in pushing changes in Fedora. We talked > > > > about enabling > > > > koschei by default and other similar things. Here's my attempt to start > > > > with > > > > something I hope will be somewhat easier: > > > > > > > > ** Let's make %autorelease + %autochangelog the default approach in > > > > Fedora packaging ** > > > > > > > > I think we should follow the Change process for this, to raise > > > > visibility and > > > > reach all interested parties. I'll file such a Change later [*], based > > > > on the > > > > initial feedback here. Jump to the end to see the proposed Scope. > > > > > > > > ** Why? ** > > > > > > > > The original motivation for %autorelease + %autochangelog was to save > > > > some > > > > typing for packagers. In Fedora all packaging work happens in dist-git, > > > > so every > > > > change would need to be described twice: once in the %changelog entry > > > > and > > > > a second time in the git commit message. > > > > > > > > A second motivation is to ease cherry-picking commits between branches. > > > > The > > > > Release field and the %changelog sections would often be the only > > > > source of a > > > > trivial conflict when merging branches or when backporting a commit > > > > from rawhide > > > > to a release branch. > > > > > > > > A third motivation to improve the workflow for pull requests. (This is > > > > a variant > > > > of the previous item, but worth mentioning on its own.) If a pull > > > > request is not > > > > merged right away, the Release value used may in the meantime be taken > > > > by a > > > > different update, and the %changelog text may conflict. > > > > > > > > A fourth motivation that has become more relevant is rust2rpm and other > > > > automatic packaging workflows. As described e.g. in Fabio's Rust > > > > Packaging > > > > Tutorial [2], one may want to regenerate the spec file for new rust2rpm > > > > version > > > > or when the package is updated. With the traditional %changelog > > > > section, old > > > > entries need to be copied over, but with %autochangelog we get > > > > continuity > > > > without any additional work. > > > > > > > > ** Why now? ** > > > > > > > > rpmautospec has been slowly improving over time. With the 0.2.6 > > > > release, it > > > > is ready for general use with all packages. > > > > > > > > ** What exactly is being proposed? ** > > > > > > > > rpmautospec [1], i.e. 'Release:%autorelease' and > > > > '%changelog\n%autochangelog' > > > > becomes the recommended workflow for new packages. > > > > > > > > All documentation is updated to describe this workflow. > > > > > > > > Converting existing packages is recommended. > > > > > > > > The legacy workflow is still supported and there is no plan to disallow > > > > or > > > > discourage it. > > > > > > > > No mass-conversion of existing packages is planned. > > > > (I think it'd be reasonable to do this at some point in the future, but > > > > this is > > > > explicitly out-of-scope for now.) > > > > > > > > ** Scope ** > > > > > > > > 1. implement changelog skipping [3, 4] > > > > 2. any other rpmautospec issues? > > > >(I don't see other big issues, but if people consider something > > > > important, > > > > we could treat them as blockers.) > > > > 2. release and deploy new rpmautospec version > > > > 3. adjust packaging guidelines [5] > > > > 4. adjust tutorials [6, any other?] > > > > 6. adjust fedora-review ([7], but that's the wrong place) > > > > 7. adjust rust2rpm default [DONE in v19, 8] > > > > 8. other packaging tools? > > > >(do we use an automatic converter for pypi?) > > > > 9. adjust rpmdevtools templates > > > > 9b. adjust emacs-mode > > > > > > As the maintainer of rpmdevtools, I will probably not accept changes > > > upstream to change to rpmautospec in the templates, since rpmautospec > > > doesn't work outside of Fedora and there's been no advocacy to make > > > rpmautospec a cross-distro tool. If someone wants to champion > > > rpmautospec as a cross-distro tool, then I will reconsider. > > > > What about adjusting the templates in Fedora to be right for Fedora? > > It doesn't have to an upstream default, a local patch would be enough. > > > > Do we want to assume that people use these less opinionated tools to > make packages for Fedora infrastructure? I know plenty of people > *don't* do that and use tools like rpmdevtools. That said, maybe it > makes sense to make a package of fedora templates and make it possible > for rpmdev-newspec to use them? I think that'd make a
Re: rpmautospec by default
On 06. 08. 22 16:10, Zbigniew Jędrzejewski-Szmek wrote: Let's make %autorelease + %autochangelog the default approach in Fedora packaging I still haven't got around to start using it, because I recall that initially there were problems I've reported or followed and nobody was looking into them. This got a bit better, but is still quite bad :( How can we ensure a permanent maintainer has dedicated time to keep the tool evolving, before we start recommending it? The following issues all bother me and nobody seem to have the resources to fix them or even look at them: https://pagure.io/fedora-infra/rpmautospec/issue/105 -- 2 years ago https://pagure.io/fedora-infra/rpmautospec/issue/193 -- 1 year ago https://pagure.io/fedora-infra/rpmautospec/issue/206 -- 1 year ago https://pagure.io/fedora-infra/rpmautospec/issue/209 -- 1 year ago https://pagure.io/fedora-infra/rpmautospec/issue/227 -- 1 year ago https://pagure.io/fedora-infra/rpmautospec/issue/238 -- 9 months ago -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.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.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rpmautospec by default
On Sat, Aug 6, 2022 at 10:33 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Sat, Aug 06, 2022 at 10:19:19AM -0400, Neal Gompa wrote: > > On Sat, Aug 6, 2022 at 10:11 AM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > Hi everyone, > > > > > > During the FESCo panel during Nest one of the conclusions was that FESCo > > > should > > > take a more proactive role in pushing changes in Fedora. We talked about > > > enabling > > > koschei by default and other similar things. Here's my attempt to start > > > with > > > something I hope will be somewhat easier: > > > > > > ** Let's make %autorelease + %autochangelog the default approach in > > > Fedora packaging ** > > > > > > I think we should follow the Change process for this, to raise visibility > > > and > > > reach all interested parties. I'll file such a Change later [*], based on > > > the > > > initial feedback here. Jump to the end to see the proposed Scope. > > > > > > ** Why? ** > > > > > > The original motivation for %autorelease + %autochangelog was to save some > > > typing for packagers. In Fedora all packaging work happens in dist-git, > > > so every > > > change would need to be described twice: once in the %changelog entry and > > > a second time in the git commit message. > > > > > > A second motivation is to ease cherry-picking commits between branches. > > > The > > > Release field and the %changelog sections would often be the only source > > > of a > > > trivial conflict when merging branches or when backporting a commit from > > > rawhide > > > to a release branch. > > > > > > A third motivation to improve the workflow for pull requests. (This is a > > > variant > > > of the previous item, but worth mentioning on its own.) If a pull request > > > is not > > > merged right away, the Release value used may in the meantime be taken by > > > a > > > different update, and the %changelog text may conflict. > > > > > > A fourth motivation that has become more relevant is rust2rpm and other > > > automatic packaging workflows. As described e.g. in Fabio's Rust Packaging > > > Tutorial [2], one may want to regenerate the spec file for new rust2rpm > > > version > > > or when the package is updated. With the traditional %changelog section, > > > old > > > entries need to be copied over, but with %autochangelog we get continuity > > > without any additional work. > > > > > > ** Why now? ** > > > > > > rpmautospec has been slowly improving over time. With the 0.2.6 release, > > > it > > > is ready for general use with all packages. > > > > > > ** What exactly is being proposed? ** > > > > > > rpmautospec [1], i.e. 'Release:%autorelease' and > > > '%changelog\n%autochangelog' > > > becomes the recommended workflow for new packages. > > > > > > All documentation is updated to describe this workflow. > > > > > > Converting existing packages is recommended. > > > > > > The legacy workflow is still supported and there is no plan to disallow or > > > discourage it. > > > > > > No mass-conversion of existing packages is planned. > > > (I think it'd be reasonable to do this at some point in the future, but > > > this is > > > explicitly out-of-scope for now.) > > > > > > ** Scope ** > > > > > > 1. implement changelog skipping [3, 4] > > > 2. any other rpmautospec issues? > > >(I don't see other big issues, but if people consider something > > > important, > > > we could treat them as blockers.) > > > 2. release and deploy new rpmautospec version > > > 3. adjust packaging guidelines [5] > > > 4. adjust tutorials [6, any other?] > > > 6. adjust fedora-review ([7], but that's the wrong place) > > > 7. adjust rust2rpm default [DONE in v19, 8] > > > 8. other packaging tools? > > >(do we use an automatic converter for pypi?) > > > 9. adjust rpmdevtools templates > > > 9b. adjust emacs-mode > > > > As the maintainer of rpmdevtools, I will probably not accept changes > > upstream to change to rpmautospec in the templates, since rpmautospec > > doesn't work outside of Fedora and there's been no advocacy to make > > rpmautospec a cross-distro tool. If someone wants to champion > > rpmautospec as a cross-distro tool, then I will reconsider. > > What about adjusting the templates in Fedora to be right for Fedora? > It doesn't have to an upstream default, a local patch would be enough. > Do we want to assume that people use these less opinionated tools to make packages for Fedora infrastructure? I know plenty of people *don't* do that and use tools like rpmdevtools. That said, maybe it makes sense to make a package of fedora templates and make it possible for rpmdev-newspec to use them? -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:
Re: rpmautospec by default
On Sat, Aug 06, 2022 at 10:19:19AM -0400, Neal Gompa wrote: > On Sat, Aug 6, 2022 at 10:11 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > Hi everyone, > > > > During the FESCo panel during Nest one of the conclusions was that FESCo > > should > > take a more proactive role in pushing changes in Fedora. We talked about > > enabling > > koschei by default and other similar things. Here's my attempt to start with > > something I hope will be somewhat easier: > > > > ** Let's make %autorelease + %autochangelog the default approach in Fedora > > packaging ** > > > > I think we should follow the Change process for this, to raise visibility > > and > > reach all interested parties. I'll file such a Change later [*], based on > > the > > initial feedback here. Jump to the end to see the proposed Scope. > > > > ** Why? ** > > > > The original motivation for %autorelease + %autochangelog was to save some > > typing for packagers. In Fedora all packaging work happens in dist-git, so > > every > > change would need to be described twice: once in the %changelog entry and > > a second time in the git commit message. > > > > A second motivation is to ease cherry-picking commits between branches. The > > Release field and the %changelog sections would often be the only source of > > a > > trivial conflict when merging branches or when backporting a commit from > > rawhide > > to a release branch. > > > > A third motivation to improve the workflow for pull requests. (This is a > > variant > > of the previous item, but worth mentioning on its own.) If a pull request > > is not > > merged right away, the Release value used may in the meantime be taken by a > > different update, and the %changelog text may conflict. > > > > A fourth motivation that has become more relevant is rust2rpm and other > > automatic packaging workflows. As described e.g. in Fabio's Rust Packaging > > Tutorial [2], one may want to regenerate the spec file for new rust2rpm > > version > > or when the package is updated. With the traditional %changelog section, old > > entries need to be copied over, but with %autochangelog we get continuity > > without any additional work. > > > > ** Why now? ** > > > > rpmautospec has been slowly improving over time. With the 0.2.6 release, it > > is ready for general use with all packages. > > > > ** What exactly is being proposed? ** > > > > rpmautospec [1], i.e. 'Release:%autorelease' and > > '%changelog\n%autochangelog' > > becomes the recommended workflow for new packages. > > > > All documentation is updated to describe this workflow. > > > > Converting existing packages is recommended. > > > > The legacy workflow is still supported and there is no plan to disallow or > > discourage it. > > > > No mass-conversion of existing packages is planned. > > (I think it'd be reasonable to do this at some point in the future, but > > this is > > explicitly out-of-scope for now.) > > > > ** Scope ** > > > > 1. implement changelog skipping [3, 4] > > 2. any other rpmautospec issues? > >(I don't see other big issues, but if people consider something > > important, > > we could treat them as blockers.) > > 2. release and deploy new rpmautospec version > > 3. adjust packaging guidelines [5] > > 4. adjust tutorials [6, any other?] > > 6. adjust fedora-review ([7], but that's the wrong place) > > 7. adjust rust2rpm default [DONE in v19, 8] > > 8. other packaging tools? > >(do we use an automatic converter for pypi?) > > 9. adjust rpmdevtools templates > > 9b. adjust emacs-mode > > As the maintainer of rpmdevtools, I will probably not accept changes > upstream to change to rpmautospec in the templates, since rpmautospec > doesn't work outside of Fedora and there's been no advocacy to make > rpmautospec a cross-distro tool. If someone wants to champion > rpmautospec as a cross-distro tool, then I will reconsider. What about adjusting the templates in Fedora to be right for Fedora? It doesn't have to an upstream default, a local patch would be enough. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.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.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rpmautospec by default
On Sat, Aug 6, 2022 at 10:11 AM Zbigniew Jędrzejewski-Szmek wrote: > > Hi everyone, > > During the FESCo panel during Nest one of the conclusions was that FESCo > should > take a more proactive role in pushing changes in Fedora. We talked about > enabling > koschei by default and other similar things. Here's my attempt to start with > something I hope will be somewhat easier: > > ** Let's make %autorelease + %autochangelog the default approach in Fedora > packaging ** > > I think we should follow the Change process for this, to raise visibility and > reach all interested parties. I'll file such a Change later [*], based on the > initial feedback here. Jump to the end to see the proposed Scope. > > ** Why? ** > > The original motivation for %autorelease + %autochangelog was to save some > typing for packagers. In Fedora all packaging work happens in dist-git, so > every > change would need to be described twice: once in the %changelog entry and > a second time in the git commit message. > > A second motivation is to ease cherry-picking commits between branches. The > Release field and the %changelog sections would often be the only source of a > trivial conflict when merging branches or when backporting a commit from > rawhide > to a release branch. > > A third motivation to improve the workflow for pull requests. (This is a > variant > of the previous item, but worth mentioning on its own.) If a pull request is > not > merged right away, the Release value used may in the meantime be taken by a > different update, and the %changelog text may conflict. > > A fourth motivation that has become more relevant is rust2rpm and other > automatic packaging workflows. As described e.g. in Fabio's Rust Packaging > Tutorial [2], one may want to regenerate the spec file for new rust2rpm > version > or when the package is updated. With the traditional %changelog section, old > entries need to be copied over, but with %autochangelog we get continuity > without any additional work. > > ** Why now? ** > > rpmautospec has been slowly improving over time. With the 0.2.6 release, it > is ready for general use with all packages. > > ** What exactly is being proposed? ** > > rpmautospec [1], i.e. 'Release:%autorelease' and '%changelog\n%autochangelog' > becomes the recommended workflow for new packages. > > All documentation is updated to describe this workflow. > > Converting existing packages is recommended. > > The legacy workflow is still supported and there is no plan to disallow or > discourage it. > > No mass-conversion of existing packages is planned. > (I think it'd be reasonable to do this at some point in the future, but this > is > explicitly out-of-scope for now.) > > ** Scope ** > > 1. implement changelog skipping [3, 4] > 2. any other rpmautospec issues? >(I don't see other big issues, but if people consider something important, > we could treat them as blockers.) > 2. release and deploy new rpmautospec version > 3. adjust packaging guidelines [5] > 4. adjust tutorials [6, any other?] > 6. adjust fedora-review ([7], but that's the wrong place) > 7. adjust rust2rpm default [DONE in v19, 8] > 8. other packaging tools? >(do we use an automatic converter for pypi?) > 9. adjust rpmdevtools templates > 9b. adjust emacs-mode As the maintainer of rpmdevtools, I will probably not accept changes upstream to change to rpmautospec in the templates, since rpmautospec doesn't work outside of Fedora and there's been no advocacy to make rpmautospec a cross-distro tool. If someone wants to champion rpmautospec as a cross-distro tool, then I will reconsider. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.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.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
