Re: streamlining fedora-release

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

 



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




[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