Bundling (was Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk))

[Peter MacKinnon]

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