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
