Re: fedora-release workflow issues
On Thu, Aug 23, 2018 at 02:18:59PM -0400, Mohan Boddu wrote:
Hi,
I am okay with changes 2-4 as I am 50-50 about the 1st one as
some want it and some dont.
Any arguments against (except "it's always been this way")?
Zbyszek
> On Sun, Aug 19, 2018 at 3:41 AM Zbigniew Jędrzejewski-Szmek <
> zbyszek(a)in.waw.pl> wrote:
>
> > Hi,
> >
> > fedora-release recently moved to accept PRs under
> > https://src.fedoraproject.org/rpms/fedora-release.
> > This is a big improvement. Nevertheless, the workflow still seems somewhat
> > rough.
> >
> > Some ways in which could make the process simpler:
> > 1. Drop Sign-off-by requirements. For fedora packages it is completely
> > pointless, since all contributors have signed the Fedora CLA. S-o-b is
> > used in some specific communities like kernel, and the requirement is
> > surprising for many people from other areas. It is not required for
> > other packages, and should not be required here.
> >
> > 2. Stop dropping the %changelog after branching. This made sense when
> > fedora-release was about fedora releases. But since the more important
> > function now is holding systemd presets, history *is* important.
> > It also makes rebasing patches between branches confusing.
> >
> We can do this and we wont remove the changelog when we branch again.
>
> >
> > 3. Between the time that a PR is filed and it is merged, it is
> > possible for branching to occur. Fedora-release maintainers should
> > either go through all outstanding PRs *before* branching, or manually
> > cherry-pick the commit to the other branch. It's very easy for PR
> > submitter to miss that the change was not applied to both branches.
> >
> > In general, I'd expect f-r maintainers to apply common sense and
> > cherry-pick all changes to other branches if appropriate.
> >
> It would be better if we can just merge them before branching, and I agree
> with your point here.
>
> >
> > 4. Introduce a workflow for PRs where there's less chance of patch
> > conflict.
> >
> > Right now, essentially for any two PRs that touch the changelog and
> > are open at the same time this must occur. Rebasing is annoying
> > because rpm required entries to be in time order. Rebasing is also
> > complicated by 2. above.
> >
> > In principle, the same problem is true for any package, but f-r is
> > special in the regard that we expect much more PRs for it.
> >
> > The solution I like is to ask contributors to stop updating the
> > %changelog or bumping Release in patches that update presets, but
> > instead just make the commit title a good changelog entry. Then the
> > git log entries would be automatically inserted into the %changelog
> > right before the fedora-release release occurs, using a simple
> > script. (It's likely that this output would require some editing, but
> > it should be much less work overall for all the parties involved).
> >
> This could be achieved by PR template and I will look into adding it.
>
> >
> > Zbyszek
> > _______________________________________________
> > rel-eng mailing list -- rel-eng(a)lists.fedoraproject.org
> > To unsubscribe send an email to rel-eng-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> >
https://lists.fedoraproject.org/archives/list/rel-eng@lists.fedoraproject...
> >