Re: ancient openssl bundled

Hi Enrico,

On Tue, 2012-03-27 at 18:28 +0200, Enrico Weigelt wrote:
> Instead of everyone bundling hundreds of (often outdated) libraries,
> the generic solution is quite simple: create a generic package
> management system for that platform and then let it handle all.

        Sounds good to me; as/when you have a nice, working package management
system for Windows & Mac, that is invisible to the user, and handles
one-click application downloads, creates no extra unwanted UI
interfaces, and deals with version requirement skew across unrelated
applications [ unwinding the Windows DLL hell ], then we'll want to use
it I'm sure. You could try poking at what the CoApp guys do, they have
some similar ideas, but it's not such an easy problem to solve I think.

> > If your intention is to update the internal opensssl, then the best
> > is to do that in a bug in our bugzilla
>
> No, I absolutely don't intend that.

        Shame :-) someone needs to update that thing and re-validate it.

> I've already seen that reaction coming. Seen the same in dozens over
> dozens of other projects in the last 15 years. None of these projects
> ever agreed do solve that problem once and for all by a generic solution

        So - perhaps sitting down and understanding why developers don't go
routinely updating their external libraries and solving the problems
they see there might work - why do we have an ancient openssl
internally ? is it the pain of re-basing our patches ? is it that we are
conservative & scared of touching things that appear to work ? :-) is it
that it is hard to test changes on mutiple platforms, and external deps
tend to be the most fragile pieces ? would a gerrit flow help that ?
etc.

        Ultimately, the overhead of shipping duplicates seems somewhat small
size-wise in a world where people virtualise & duplicate whole operating
systems on their devices in virtual machines, at least compared to the
convenience of pseudo-application-virtualisation ;-)

> If you choose option b, I won't take part in it, but do my own fork.

        Free Software advances by forking and merging back improvements, so I'd
call it make a branch - if you create something cool - we'll use it of
course (when it's ready), if it meets our requirements.

        All the best,

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot