New thread to get clear of some of the flames and wreckage...
On 07/23/2013 05:25 PM, Toshio Kuratomi wrote:
On Tue, Jul 23, 2013 at 03:34:15PM -0400, Peter MacKinnon wrote:
Well, compat libraries are certainly an option but I view that as a tactical
solution to an institutional, um, challenge.
And I believe that is what Matt is driving at: sustainable solutions that
satisfy the user/admin need for stability and
"cleanliness" while also providing an OS that developers from all manner of
technology and language profiles would
gravitate toward.
So actually... I think that I would describe the two strategies the other
way. Bundling libraries into stacks is an expedient solution, not
a sustainable one. As time goes on, you get more and more programs bundling
more and more.
A generalization which I would disagree with in the Java space. I think
many projects
eventually reach "steady-state" where they have acquired the set of dep
bundles
they need to satisfy their runtime and test requirements. For example,
Hadoop
would not bundle multiple versions of Jetty. However, it's bundled deps
may differ
slightly (perhaps even by just API-compatible versions) say from Tomcat's
(another Hadoop dependency). And that's where you see the proliferation
of bundled
jar libraries as you walk down (up?) the dep tree.
Which means that there's more maintainance burden and less
sharing of that burden between interested stakeholders.
The maintenance model in the Maven space is more static and is really
owned by each
upstream. Each project using those must decide when it makes sense to
move to a
particular version, say driven by the discovery of a particular CVE. But
CVE
notwithstanding, a project shouldn't just move it's deps for the sake of
something
newer. Newer is not always better, sometimes newer is just different.
However, into Fedora there are the extra layers of maintenance overhead
associated
with the package (spec, patches, etc.). Perhaps it's a question of
granularity of the
maintenance burden, and if a SIG owns that burden for a set of bundled
libs for its
project then so be it.
I'm not opposed to
trying to find a way to host the expedient solution but in the end, the
sustainable solution is to make changes to what is shipped.
Force external projects to conform to FPG? Normalization of
dependencies? Sounds like
you and I agree that there needs to be common ground for expedient
solutions. But
Fedora really has to recognize that in order to be agile it needs to
re-think how it sees
the external development world and how they see us.
At some point,
the software that gets bundled is only being maintained by a handful of
pople in the bundling project. At that point, it gets real lonely when
a security issue or two pop up.
Another generalization? :-)
This thread has had a lot of FUD around future maintenance burden: fewer
resources,
absentee maintainers, etc. These are costs that are experienced today
anyway and in
our SIG's case we are writing the check up front. :-)
-Toshio
--
Peter MacKinnon
MRG Grid/Big Data
Red Hat Inc.
Raleigh, NC
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
