On Wed, Nov 08, 2017 at 03:23:37PM +0000, Peter Robinson wrote: > 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. Hmm, Fedora as such certainly. But fedora-release itself I don't think so. It has a /usr/share/licenses/fedora-release/{Fedora-Legal-README.txt,LICENSE} which shouldn't be touched, as in any other package, but apart from that it's just a bunch of text files. > > 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. OK. The whole thing about proven packagers is much more contentious then I expected. Let's leave it be ;) As long as there's a general agreement that additional maintainers can be added (following normal procedure), that's the important part. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
