On Wed, Nov 8, 2017 at 2:56 PM, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > On Wed, Nov 08, 2017 at 02:05:12PM +0000, Stephen Gallagher wrote: >> On Wed, Nov 8, 2017 at 8:43 AM Peter Robinson <pbrobinson@xxxxxxxxx> wrote: >> >> > On Wed, Nov 8, 2017 at 1:27 PM, Zbigniew Jędrzejewski-Szmek >> > <zbyszek@xxxxxxxxx> 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), Well the fedora-release package could be arguably open to trademark. > 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. I didn't say that we shouldn't open it up to a wider set of maintainers, but I don't think it should be wide open for all proven packagers to commit, to submit PRs sure, but not just to push. There's a few people that consistently push bad bits and have to be requested to resubmit. >> > > 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
