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").
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.
_______________________________________________
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
