Re: streamlining fedora-release

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 8, 2017 at 1:27 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> wrote:
> Hi fedora-release maintainers and fellow developers,
>
> The fedora-release package contains stuff that is tied to each Fedora
> version and changes slowly, and it also contains the preset files for
> systemd units, which change fairly often (a few requests per month).
>
> Currently fedora-release has a fairly complicated maintenance
> structure, with an "upstream" project at https://pagure.io/fedora-release
> and "downstream" at https://src.fedoraproject.org/rpms/fedora-release.
> "upstream" is only used for this single "downstream", and in fact changes
> made in packaging "downstream" are sometimes lost when the next version
> of "upstream" is imported.
>
> I propose simplifying this and opening fedora-release releases to more
> contributors:
>
> 1. Let's drop "upstream" at https://pagure.io/fedora-release and
>    make the "downstream" the canonical source of the package,
>
> 2. Allow pull requests in src.fp.o/fedora-release,

I agree with both of these

> 3. With 1 and 2. implemented, it'll be easier for any fedora maintainer
>    to suggest improvements to the package (through PRs) and it'll also
>    be possible for proven packagers to do changes without stepping on
>    the toes of the maintainers and interfering with the separate "upstream"
>    repo. Let's agree to allow pps to update fedora-release as necessary
>    when the main maintainers are busy.

I don't agree with this, there's often reasons for things and we often
get pull requests that are incorrect and need a couple of revisions.

> 4. Release fedora-release quickly, so that when a preset change request
>    comes in [1], it can be handled in a few days or a week. (Having such
>    requests hanging usually blocks changes to the package in question,
>    so it's important to have the resolution of the preset status without
>    undue delay.)

There's no reason for that not to happen, and generally most of the
holdups that people perceive here are not actually the maintainers but
issues with the PR or the review of the actual changes being made.

I believe for such a critical package that has the ability to break
the distribution there should be review of the proposed changes.

> To implement this, not much action is required, mostly acceptance of the
> maintainers to amend and open up the process. Concrete steps that do need
> to be taken:
>
> 1. tweak https://src.fedoraproject.org/rpms/fedora-release/settings
>    to allow PRs
> 2. push a commit to "upstream" that that repo is dead
> 3. make a README for "downstream" that PRs can be submitted and outline
>    the requirements.
>
> I'll be happy to submit the PRs for 2 and 3. I'll also be applying for
> co-maintainership in the fedora-release package, because I want to push
> those changes forward.
>
> What do you think?
>
> Zbyszek
>
> [1] https://fedoraproject.org/wiki/Packaging:DefaultServices#How_to_enable_a_service_by_default
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux