[Yum-devel] 3.2.X and stuff to do

Florian Festi ffesti at redhat.com
Thu May 3 10:01:05 UTC 2007


Jeremy Katz wrote:
> On Wed, 2007-05-02 at 12:53 -0400, seth vidal wrote:
>> Hey folks,
>>   I was thinking some about 3.2.x and after. So a couple of options:
> [snip]
>> 2. don't branch, release 3.2.0 off of HEAD and continue working on HEAD
>> but w/o breaking the API while we stabilize and work on new items.
> 
> So I've alluded to this some, but I really lean towards this option.
> 
> The big reasons why I think it makes sense...
> 1) I don't think we have any really huge world breaking things that we
> want to do.  Lots of incremental improvements, lots of bug fixing and
> lots of speed ups

I disagree with this.

  * The depsolver still needs a lot of work. We already got most of the
    easy optimizations in place. The next step will be using faster/smarter
    algorithms that are likely to be distributed over several classes
    (needing new/changed APIs).
  * Additionally there are several correctness issues that need further
    examination. It is possible that some code parts have to move elsewhere
    to solve these problems (depsolver <-> Sacks, depsolver <->
    TransactionData).
  * While working on the depsolver the po-pkgtup schism should be
    further addressed - another source of possible API changes
  * Several APIs that no longer rely on rpmlib could be reworked to make
    live for plugin (and yum) developers easier.

Of course it is debatable if all those points need to be addressed right now 
but I see no reason to defer them to the future. After all, we're all 
interested in further improving yum from a development standpoint, and that 
should of course happen in the current head branch.

> 2) If we go this route, we can regularly push these changes back for
> users of F7.  This means end users will get the improvements we're
> making faster.
> 
> The second is really the big win in my mind.  

Slowing down development to make it easier for distributions to keep up
doesn't sound like a good idea to me. Especially as we know that larger 
parts of yum still need improvement. Where else should that happen than in 
the head branch?


Florian



More information about the Yum-devel mailing list