On Wed, Nov 08, 2017 at 02:05:12PM +0000, Stephen Gallagher wrote: > On Wed, Nov 8, 2017 at 8:43 AM Peter Robinson <pbrobin...@gmail.com> wrote: > > > On Wed, Nov 8, 2017 at 1:27 PM, Zbigniew Jędrzejewski-Szmek > > <zbys...@in.waw.pl> wrote: > > > 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
Cool! → https://pagure.io/fedora-release/pull-request/119 > > > 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. > > > > > I think I agree with Peter here. fedora-release is a package that probably > *shouldn't* be granted access to provenpackagers. But why? _Any_ package can completely screw up the system with a bad scriplet or a dependency. Let's take one step back and consider why a package would need special protections: only when there's something _tricky_ about the package. We have such special protections for the kernel (signing), firefox (trademarks), and for bootloaders (signing again), and some packages which don't consider the fedora repo the canonical location for sources. Doing those kinds of protections for a package like fedora-release which is _simple_ would be just adding red tape. There's nothing rel-eng-y about fedora-release. There's a general policy for what proven packagers can do (widely agreed-upon changes, cleanups, trivial fixups, etc), and I don't see any reason to exclude fedora-release from this. > That said, I think we should probably set a policy in place that releng > will quickly merge any changes limited to presets that are acked by a > trusted individual such as Zbigniew. We can write up some simple rules for > this which would probably boil down to "Must have followed the preset > request policy and include a comment pointing to the relevant BZ". Well, if we trust somebody to do the review, they should be trusted to do the merge. > > > 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. I'm all for review. In fact I reviewed many of the PRs that have been submitted recently. > I suppose the other thing we could try to do would be to separate the > presets into its own package, but that seems like unnecessary overhead > compared to coming up with a decent review-and-merge policy. Yeah, that seems like a worse option. Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
