[Rpm-ecosystem] libhif, and grand plans

[Richard Hughes]

On 30 June 2015 at 09:49, Radek Holy <rholy at redhat.com> wrote:
> we are really careful not to repeat these mistakes again.

I really do apologise if I was angry, but I was the one fielding the
frustrated bugs from end users. I appreciate the care, but without
automated testing and a large amount of QA we're really playing
whack-a-mole when we change API behaviour in the future.

> This can be solved by backwards compatibility commitment. I guess you are not going to merge the rest of the dependencies because of the same reason.

I feel the "cost" of managing a larger project is less than the "cost"
of managing the QA and fallout from three small libraries being
updated at different times.

> After the merge, it becomes even more complicated...

I respectfully disagree, when we can drop the API of the "internal"
libraries we can all just use one enum field and not have to have
functions to convert LrChecksm<->HyChecksum<->GChecksum for example.
There is a lot of low hanging fruit, e.g. allocation functions,
cleanup macros, linked list implementations, progress callbacks and
the biggest: reference counting.

Richard