On Thu, Oct 20, 2022 at 12:12 PM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > * Miro Hrončok: > > > On 19. 10. 22 17:24, Zbigniew Jędrzejewski-Szmek wrote: > >> On Wed, Oct 19, 2022 at 01:49:33PM +0200, Fabio Valentini wrote: > >>> On Wed, Oct 19, 2022 at 11:31 AM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > >>>> > >>>> I'm going to push a branch to dist-git for very few packages (so far gcc > >>>> and redhat-rpm-config) which will be used by COPR builds to port Fedora > >>>> to C99 and later language standards. > >>> > >>> So you only plan to trigger COPR builds from these branches, but not > >>> any koji builds? If that is the case, you might want to create and > >>> push these branches only in forks, not in the "official" dist-git > >>> repos (COPR can build from both). Otherwise the branches might need to > >>> stick around "forever". > >> I think we changed the policy to allow removal of branches which > >> don't have > >> any commits not reachable from other branches from which no koji builds have > >> been made (https://pagure.io/releng/blob/main/f/scripts/distgit-branch-unused.py). > > > > The policy was created to allow undoing accidental pushes, not to > > encourage branching like this. > > > > I'm with Fabio. If it's for Copr only, please use a fork. > > It wasn't intended to use COPR originally, it's just that Fedora releng > ignored my request for close to a year. > > I filed <https://pagure.io/releng/issue/11102> for the branch removals. > > I must say this is quite confusing. Why offer self-service branch > creation at all if we aren't supposed to use it in general? > > What's the recommended way to collaborate with packages/provenpackagers? > Someone's personal fork on src.fedoraproject.org with a branch with a > wide-open ACL? Either that (provenpackagers can already push to forks on src.fp.o), or just push fixes to the rawhide branch directly? Also, the benefit of using COPR would be that you can set up continuous integration, as COPR will automatically launch builds for new commits in dist-git, and for any PRs that are filed. You might want to ask the Python maintainers how they handle this for Python rebases - as far as I know, they have scripts that automate large parts of this process, which you could benefit from for this change, as well (they build rawhide against newer Python, you're going to build rawhide against different GCC, so the use case is pretty similar). I think the only difference might be that you'll want to enable more architectures than just x86_64? Fabio _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
