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

[Jeremy Katz]

On Thu, 2007-05-03 at 12:01 +0200, Florian Festi wrote:
> 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).

New APIs are fine.  Changing existing APIs is just going to burn our
users (both end-users and API users).  We made a pretty big deal about
yum 3.0 providing an API for people to build things on top of.  If we
then go and are making substantial changes, then we're not providing a
good base for them to build on.  And this is _especially_ true given
that everything is python; changed APIs just lead to tracebacks and not
anything which is more immediately obvious as "the underlying API
changed" like a soname would give you.

>   * 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).

There's nothing I've seen that makes me think we can't do this without
preserving API.  The internals of the depsolver can change all we want
as that's considered private.  And adding things is always okay.

>   * While working on the depsolver the po-pkgtup schism should be
>     further addressed - another source of possible API changes

While improving the consistency here would be nice, I think we can
actually do most of it by adding new args and preserving old behavior
when the args aren't set.  Or in other cases, with new methods. 

>   * Several APIs that no longer rely on rpmlib could be reworked to make
>     live for plugin (and yum) developers easier.

It doesn't make the developers' lives easier if they have to keep up
with a shifting API.  Give me a stable and evolving API with warts any
day over API of the week.

> 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.

But who says that you can't have improvements while retaining
compatibility?  Do you think that yum 3.2 is going to be an improvement
over 3.0?  I think so, and as it stands, the only unavoidable
incompatibilities seem to be[1]
* change of with kwarg -> withmd in a couple of populate() methods;
unavoidable to not have problems with python 2.5.  We've tried to be
proactive about getting the change reflected in callers even with 3.0
code (since it's the first kwarg and there aren't any non-kwargs, you
can just drop the keyword)
* direct sqlite queries need changes; again python 2.5 and nothing that
can really be done about it
* a few changes to be more consistent about exceptions being returned
from sacks, but given that people were checking for them anyway, this
doesn't seem to be problematic

Jeremy

[1] There is still one or two niggling things with the property changes
that need to be beaten into shape, but those are the exceptions not the
rules