On Wed, 12 Dec 2007, Michal Marek wrote:

> The "OS- and Linux- distros" slide doesn't put the distros in a good light,
> I see :-/ What could we (curl maintainers at various distros) do to improve
> this..?

Well, as you'll see and hear if that video ever appears, I say that overall
the Linux distros are good at this... :-) At least then the major distros,
which are the ones I'm "tracking" closest myself.

And then of course all this (the talk and the slides from the talk) should be
seen from the curl project angle. The talk is about the curl project and how
things around it and in it work, from the project's (well, my) perspective.

I'm sure all distros and OSes have their reasons for acting and working like
they do, but in several ways that end up awkward in our end.

In my talk I generalize of course. Many distros are awesome.

> "lagging behind terribly at times" -> The problem is that people are always
> conservative about updating libraries that are used by several applications
> in the system, because it might cause this and that, and don't fix it if
> it's not broken.

Yeah, that's a typical example. I realize that makes perfect sense for the
distro managers, but from our perspective it gives us lots of users that
report problems and have questions on oldish versions and the users are
unwilling and unlikely to upgrade...

I'm not saying this is even possible to solve, it's more of a fact that this
is how things are (from my view).

> For openSUSE, people can download newer curl packages built for older dists
> from the buildservice (and I guess other distros have a similar option)

I'm not so sure. At least we quite often get to see users who say "I use
distro X version Z so curl version Y is the newest I can get".

> Which leads to another point, that bugreports against the distro packages
> are often of no use for you, because it involves code that is months or
> years old.

Yeah. The "absorbs bug reports" have both positive and negative sides. If the
bug is old and already dealt with in curl, we don't want it anyway. Or if the
bug is because of a particular bug or setup in the distro. But that haven't
always been the case, and I have found unreported (upstream) bugs in distros
several times in the past that weren't forwarded to us. And I've even found
such bugs to have been cured by patches done by the distro guys and those
partches weren't forwarded to us either.

When I've found such occurances, I've tried to point this out to the admins to
make sure it won't happen in the future. I do believe this is rather rare
these days, but I can still today name distros that apply patches to their
packages that were never sent to us nor did they explain why they think those
are needed etc.

> I try to forward valid bugreports to curl-library, but it always takes some
> time to verify whether the bugreport applies to the current code or not. I
> don't know what's better, forward more bugs faster (inc. false reports), or
> weed out false reports (at some time cost)?

I know and acknowledge that you are among the "good guys" when it comes to
passing on bug reports and fixes to us. As to the question what's better,
fully "acknowledged" bug reports or more reports but possibly not verified
yet, I can't tell for sure. I think the latter actually, at least given the
extra info at what level of confidence you are that the bug is repeatable on a
recent version as well or that you have no idea etc, since many times people
here can confirm or elaborate on the bug by the given description. Especially
if it is an already fixed bug.

But that said, getting a flood of reports on older versions wouldn't be a
dream situation either...

> "don't contribute in any particular extent" -> well, yes. I (try to) fix
> some of the bugs that go through the SUSE bugzilla, not much time for more
> interesting stuff, because there are other duties :(. I gues others are in a
> similar position. (actually, I recently started working on a hack in
> libcurl, I'll post details when it's somehow usable, in January probably.)

The point I made with that particular part of the slide is that even if your
project gets adopted widely on numerous distros, such as curl has, it doesn't
really change a lot contribution-wise. It makes it easier for users to get
your application/tool/library installed, but it doesn't offer much extra
contributions or patches. At least not in any extent that is obvious to me.

Of course that varies and it has its explanations and everything, but the fact
remains.

> "not always good at telling where things come from (= they didn't create
> this thing)" -> ?? What did you mean by this point? I'm not sure I
> understand it and the video is not yet available...

I'm not sure I gave it a good explanation in the talk either, 45 minutes was a
bit too short for my talk. Perhaps a bit because I got a handful of (really
good) questions that I also dealt with.

Distros in general tend to make people unaware of where particular components
of their system come from. But what I've seen several times over the years
when distros claim to be the producer of (the _package_ with?) curl/libcurl
and put themselves in the meta data for the package (be it RPM or deb or
whatever). (Not to mention that a lot of them claim curl is GPL and similar,
but that's not the same problem just a sympthom of an ignorance that pops up
occasionally.)

Let me also just stress that I don't mean to whine or complain at all. I was
just trying to explain how being present in distros affects the project. I do
appreciate that curl is included "everywhere".

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html