On Thu, Jan 11, 2018 at 8:32 PM, Jason L Tibbitts III <tibbs(a)math.uh.edu> wrote:
>>>>> "JB" == Josh Boyer
JB> Hm. On the one hand, that's a fair assumption to make. On the
JB> other hand, it seems unnecessarily adversarial.
I certainly didn't intend it that way; hell, none of that even entered
my mind. To flip it around, to be completely honest your response comes
off just this side of overly defensive (which I would wager you also
didn't intend). But you brought it up, so here's my thought process.
Indeed. I didn't mean to sound defensive. I also didn't think you
had any malice behind your reply for what it's worth. I was surprised
by the tone of indifference. It caught me off-guard.
I intended to invoke discussion about the "scope" comment. I
succeeded there at least, even if I failed in other ways :).
As a person not privy to Red Hat internals, I really have no idea
state things are in there, but I have to assume that Red Hat is well
along with RHEL8 packaging and so I would be surprised if any changes
made to a rawhide branch in Fedora now would make any difference to how
Assumptions are bad. Not being able to talk about future looking
events is awkward. Red Hat is trying to get better at both.
So think of it from my perspective, not having any knowledge of Red
release dates and policy. My interpretation of what Florian wrote was
that doing this (I assumed in rawhide) could potentially help the RHEL8
developers. Which is great; everyone needs all the help they can get.
But if that's the case, then either RHEL8 hasn't even been branched yet
or it has been branched and someone has already had to make those
changes and they didn't flow back out to Fedora. I certainly thought
RHEL8 was further along than that, so....
Small caveat, nobody said RHEL 8. Troy said the next major version of
RHEL will have python3, that's all. This is where the awkwardness
comes in. I think people can appreciate not being able to talk
publicly about any current or future development activities for
As for the assumption on when/if/how RHEL development occurs, those
are easy to make and I don't fault anyone for thinking along the lines
you laid out. I would offer that Troy would not have made a request
if it was pointless to do so. That benefits nobody. I would also
suggest that by making the request, he isn't assuming he can just
script and fix without coordination.
JB> So when a community member reaches out and asks people to help
JB> with a small change to packages that *already* conditionalize
JB> something, I don't see why that isn't a reasonable request.
I never intended to imply that it wasn't. Only that it wouldn't really
matter, and that I didn't think it was worth making any big effort to
convert these things, since things have to be manually branched into
EPEL8 anyway so the maintainer who wants to have them branched there can
simply fix them then.
Right, that's what I mean though. It's a small change that a
community member asked for help with. If we approach that with
positive intent in mind, he's asking because it *does* matter in some
And if you'll allow me a little latitude, I'd also point out that
while there are many package maintainers that maintain across the
Fedora and RHEL divide, Red Hat is an open source company. Fedora in
an upstream for RHEL, and whenever possible it tries to contribute
back to the upstream source to lessen burden for those maintainers.
The more the specs are shared, the further that benefit goes. To do
otherwise would be weird.
And of course I offered another solution to this kind of thing,
would fix a whole class of this kind of thing for all time, but that
idea never seems to get any traction. (Probably because I never find
the time to push it forward.)
That would be interesting to see.
JB> At the very least, I did not expect a discussion about the
JB> Fedora with such a small request.
I didn't either, but then I was quite surprised to see a suggestion that
a community member changing an %if clause in a Fedora package now would
somehow make any difference to what RHEL8 is certainly already doing.
We were both surprised then!
JB> It would have been pretty trivial to script this and use a
JB> provenpackager to make the changes across the board.
Well, we do have a procedure for doing that and which even encourages
such things. I don't think it's an entirely trivial problem, though,
but certainly if someone wants to take it up I'm not going to object.
I think, in this case, we'd like to avoid that. I get that people
don't always read devel list so the request and this discussion might
not even register to the majority of maintainers. At least we have it
in the archives for reference though.
Thanks for your willingness to discuss. I love it when something
starts trending toward understanding instead of escalating into a