[Rpm-ecosystem] libhif, and grand plans

[Radek Holy]

----- Original Message -----
> From: "Richard Hughes" <hughsient at gmail.com>
> To: rpm-ecosystem at lists.rpm.org
> Sent: Tuesday, June 30, 2015 11:07:13 AM
> Subject: Re: [Rpm-ecosystem] libhif, and grand plans
> 
> 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

And don't forget the other abstractions down to the machine code.

Anyway, my opinion is that the smaller the project, the better. I, as a developer, always prefer the most compact libraries. It's much easier to become familiar with these and also it's much easier to find bugs, understand the consequences of every little change and to attract and train new contributors.

TBH, I have no idea what's the added value of libhif. But if I was the one who has to make the decision, I'd just merge libhif and hawkey (if at all). I think that librepo should remain standalone since it can perfectly exist without a depsolver and if someone in the future would like to implement another depsolver, they could reuse librepo as well.

Anyway, I just wanted to express my opinion. I don't need to change your mind and you don't need to change mine. I'm going to help with the depsolver regardless of what you all come up with.
-- 
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech