On Thu, Mar 26, 2020 at 3:55 PM Petr Viktorin <pviktori@xxxxxxxxxx> wrote:
>
> On 2020-03-25 17:33, Aleksandra Fedorova wrote:
> > [Branching] removes community maintainer from the conversation about what
> > downstream is doing. While we want to give community member a voice in
> > that conversation.
>
> I fear that this proposal *forces* the community member to participate
> in the discussion. That is a very different thing than giving them a voice.
>
>
> On 2020-03-25 17:10, Miro Hrončok wrote:
> > On 25. 03. 20 16:47, Stephen Gallagher wrote:
> >> I think we managed to miss a few key points in the Change Proposal
> >> which is directly resulting in a bit of the confusion here.
> >
> > Reading the rest of you e-mail I must agree that this is what happened.
> > Would you mind putting the change back to incomplete state and resend it
> > once more for feedback once this is addressed?
> >
> >> The first and most important of these is that ELN will*not* be
> >> building the complete Fedora package set. We're going to be building a
> >> selected subset of packages (derived from packages in RHEL 8 and
> >> EPEL). Our current expectation is that we are going to be looking at
> >> fewer than 2500 source packages. We are still working up the initial
> >> list of these and we will update the Change Proposal with it (as well
> >> as providing a fedora-devel post breaking down the known owners).
> >
> > Glad to hear that.
> >
> >> Second, from this reduced subset, we expect that the overwhelming
> >> majority of the maintainers are Red Hat employees that already work on
> >> RHEL. With this in mind, we think that the level of concern about how
> >> this will affect non-Red Hat contributors is premature. We will reach
> >> out directly to those non-Red Hat contributors we identify.
>
> This actually worries me very much.
>
> The subset of packages will need to form a working system; it will
> include the most important packages. I hope this doesn't end up limiting
> maintainers of Fedora's most central packages to only Red Hatters or
> those that agree to play by RHEL rules that they have no say in.
>
> I am pretty sure that most packages/packagers will be OK with the ELN
> change. But "most" is not enough. We do need to take the "worst cases"
> into account. Consider a package that:
> - is needed in RHEL, but only as a dependency of something vital; the
> RHEL maintainer doesn't care too much about it outside their work duties
> - has an enthusiastic packager in Fedora, who prefers to leave RHEL work
> to paid developers
>
> (As member of a team that, some time ago, used to be catch-all RHEL
> maintainer for anything that happened to be written in Python, I can
> definitely imagine situations similar to this.)
>
> For such a package, we need to avoid pushing ELN macros into the
> package, otherwise we lose an enthusiastic contributor who does amazing
> work in Fedora.
>
> Such a package might even be hypothetical right now, but the case still
> needs to be adressed. A package can fall into this category at any time
> in the future. It's not enough to identifying packagers that are
> affected now, and work with them. There needs to be a process for cases
> like these, and it can't be "merge these ELN macros now, there's a
> deadline coming; maybe we'll come up with a better process in the
> future". (Especially if Red Hat is unlikely to drive setting up a better
> process.)
>
> IMO, any changes needed in EL need to be opt-in, with the understanding
> that opting in will be (almost always) beneficial for everyone involved.
> They need to feel like a gift ("Hello fedora packager, please accept
> this PR with EL macros; it'll make it easier to work on this together!")
> rather than forced ("Red Hat needs this; merge it or else").
I wonder how we ended up with people feeling like we are proposing
latter rather than the former.
I guess I took couple of wrong turns in this discussion, and I'd like
to step back and try again.
Me, Stephen and Troy are going to update the proposal, and come up
with a better description of how opt-in will look like.
> To borrow Neal Gompa's words, ELN needs to not feel "like it's written
> for Red Hat people to move their sandbox outside of Red Hat into Fedora
> without anyone else to be able to play in the sandbox."
>
>
> For ELN changes to be to be opt-in, there essentially needs to be a
> place to diverge -- a place for ELN hotfixes to live while polishing
> them and debating their usefulness in Fedora and further upstreams.
> Here by "hotfix" I need something required in RHEL that is not yet ready
> for upstream. It is healthy to have a place for such things: it removes
> time pressure from discussions (people from the community very often
> have good ideas but less time), but allows the fix to be used now (so
> the rest of ELN isn't blocked).
> Forks are good if they're not permanent (but, making them not permanent
> needs effort).
>
>
> As Miro Hrončok continues:
> > As a Red employee if I need to diverge a RHEL package from Fedora, I
> > prefer to use branches as well. And I know for a fact I am not alone in
> > this. Please don't forget to identify and reach out to Red Hat
> > contributors as well, not just the non-Red Hat contributors.
> >
> > [Stephen Gallagher]:
> >> Finally, of the set of packages that we're going to be including, we
> >> anticipate around 200-300 of them will have distro conditionals that
> >> need investigation (with fewer needing actual modification). The ELN
> >> SIG will be doing this initial investigation and will provide guidance
> >> (and/or PRs) to affected packagers.
>
> What would IMO help would be tracking all such divergences from Fedora
> as bugs/issues on the Red Hat side, and spending effort to triage them,
> polish them and discuss them with the community. Not as initial
> investigation, but ongoing effort.
Yes, this is what ELN SIG supposed to be doing. It is not something we
can just turn on once.
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
--
Aleksandra Fedorova
bookwar
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
