[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: c99-port branches in dist-git
From:       Fabio Valentini <decathorpe () gmail ! com>
Date:       2022-10-31 14:16:47
Message-ID: CAB-QmhQikvgqck+Cbik0TsCD1z1p8ixyZen1cYGKihH_V4xvVg () mail ! gmail ! com
[Download RAW message or body]

On Thu, Oct 20, 2022 at 12:12 PM Florian Weimer <fweimer@redhat.com> 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@redhat.com> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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

[prev in list] [next in list] [prev in thread] [next in thread]