On Tue, 2012-08-21 at 05:28 -0400, Zdenek Pavlas wrote:
> >  Can we call this multi_progress_obj instead?
> 
> ok
> 
> > > -def parallel_wait(meter = 'text'):
> > > +def parallel_wait():
> > 
> >  Any caller that does parallel_wait('text') or
> > parallel_wait(meter='text') gets a traceback after this change.
> 
> No user (AFAIK) has ever used that arg, and since now we have 
> per-request multi_progress_obj option, it does not make sense.

 But this is live in at least F17, right? So we have no control over it
anymore.

> Use it as default multi_progress_obj value, perhaps?  But we can't
> default to 'text', as that would break the case where users
> have custom progress_obj and expect that to be called (the main
> reason for this patch)
>
> So that arg must default to None, that's the default value 
> of multi_progress_obj already.  And having two ways to specify
> the same default value seems confusing.
 
 We don't necessarily need to honor it, as I think it'll mostly DTRT
anyway ... but having a call traceback because we removed the API is
bad. So just set it to default to None and ignore it.

 Yes, it's unlikely to have been used ... but being able to say "we
didn't break the API" is much easier to explain to everyone than "well,
it's very likely we didn't break the API for you" (and will generally
make people much happier).

> commit 7b171a049ea931ee1da023423f3cbcca2312b60e
> Author: Zdeněk Pavlas <zpav...@redhat.com>
> Date:   Mon Aug 20 15:29:23 2012 +0200
> 
>     No implicit use of TextMultiFileMeter
>     
>     - Dropped the 'meter' argument of parallel_wait(), added
>       the multi_progress_obj option instead, defaulting to None.
>     
>     - progress_obj and not multi_progress_obj case: progress_obj
>       is used, legacy users should not break.
>     
>     - dropped po.failure() call.  #1 progress_obj does not implement
>       this, #2 the error message is shown in failure_callback too,
>       and we don't want to display it twice.

 Apart from the API break, ACK.

_______________________________________________
Yum-devel mailing list
Yum-devel@lists.baseurl.org
http://lists.baseurl.org/mailman/listinfo/yum-devel

Reply via email to