On 08/04/2015 09:05 AM, Peter MacKinnon wrote:
The Fedora upstream feedback virtues you describe are laudable but
the
game has changed. That model works well for packages that have both
limited scope and dependency sets. But these projects are massive, under
rapid development, and IMHO the upstreams aren't interested in a
continuous and steady stream of PR or JIRA to upgrade versions,
unbundle, etc. for the sake of Fedora. We already went down that road
with Hadoop for example and JIRAs just languished as we continually
rebased them for a time.
I'll chime in with my support for this view, and I think the hadoop
packaging effort has a prime example of this situation. When we
packaged hadoop we had to port the version of jetty used from 6->8 and
then eventually to 9. Changing minor jetty versions is non-trivial at
times, and changing major versions takes quite a bit of work many times
requiring diving into the implementations of api changes to make sure
the new api did what the old one used to. We carried this changes
through multiple hadoop version updates as well. Jetty is core to
hadoop and the upstream project would add more jetty related code in
each release which meant we had to do the same inspection process each
time we wanted to update versions in Fedora.
We provided these patches to the upstream project, but they never went
anywhere. I even started a discussion on the hadoop mailing list about
the situation, and the end result was that there was no way they were
going to take the patch. There were multiple valid reasons why, but at
the core was that they had different priorities than Fedora. The
situation was made worse by an upstream branching/support/development
strategy that really couldn't handle these kinds of changes easily. In
the case of jetty, any change/bugfix in a release version of hadoop on
an older jetty would require the same kind of machinations we did in
Fedora in order to port into any development stream with a newer jetty.
That is a lot of non-trivial work. Newer jetty versions also needed a
version of java hadoop didn't officially support, which is a non-starter.
I haven't been following the hadoop development mailing list as close as
I used to, but last I saw they still didn't have a process to handle
this kind of situation. They recognized the problem and were trying to
improve things (like moving to a newer version of java), but the core
problem remained.
Rob