pybugz call for testers
 

All,

I have updated pybugz-9999 to work with the xmlrpc interface of
bugzilla.

I can name a couple of issues that are api limitations that we can't do
anything about:

- you can't add keywords to a bug with the post command, but you can
with the modify command.

- you can't search on cc: or keywords fields.

I haven't done a release yet, since there may be other issues.But, if
you are up to it, feel free to emerge pybugz-9999 and test and report
any issues you find.

Thanks,

William

pybugz call for testers
 

On 4/10/12 7:54 PM, William Hubbs wrote:
> I have updated pybugz-9999 to work with the xmlrpc interface of
> bugzilla.

Cool, thank you for working on that.

> I can name a couple of issues that are api limitations that we can't do
> anything about:
>
> - you can't search on cc: or keywords fields.

That's going to be a problem for arch testing needs (e.g. STABLEREQ
keyword and x86@ cc-ed). How about doing the searches "the old way" that
allowed the above.

pybugz call for testers
 

On Tue, Apr 10, 2012 at 10:45:14PM +0200, "Paweł Hajdan, Jr." wrote:
> On 4/10/12 7:54 PM, William Hubbs wrote:
> > I have updated pybugz-9999 to work with the xmlrpc interface of
> > bugzilla.
>
> Cool, thank you for working on that.
>
> > I can name a couple of issues that are api limitations that we can't do
> > anything about:
> >
> > - you can't search on cc: or keywords fields.
>
> That's going to be a problem for arch testing needs (e.g. STABLEREQ
> keyword and x86@ cc-ed). How about doing the searches "the old way" that
> allowed the above.

That is not so easy to do since we have completely gotten rid of the old
method of communicating with bugzilla. That method was not reliable and
had broken several times with bugzilla upgrades, but using the web
services will be more stable.

Here is the documentation for their search command [1]. It would
probably be better for us to open a bug against bugzilla itself and
request those changes be put in the api.

What are your thoughts?

William

[1] http://www.bugzilla.org/docs/4.2/en/html/api/Bugzilla/WebService/Bug.html#search

pybugz call for testers
 

On Tue, Apr 10, 2012 at 5:17 PM, William Hubbs <williamh@gentoo.org> wrote:
> Here is the documentation for their search command [1]. It would
> probably be better for us to open a bug against bugzilla itself and
> request those changes be put in the api.
>

I did some digging on Bugzilla's Bugzilla. There is already a bug open
with patches to expose additional search functionality via the web
service api. This bug has open since 2009, but it has seen some recent
activity (within the last few months).

https://bugzilla.mozilla.org/show_bug.cgi?id=475754

pybugz call for testers
 

On 4/10/12 11:17 PM, William Hubbs wrote:
> On Tue, Apr 10, 2012 at 10:45:14PM +0200, "Paweł Hajdan, Jr." wrote:
>> On 4/10/12 7:54 PM, William Hubbs wrote:
>>> I can name a couple of issues that are api limitations that we can't do
>>> anything about:
>>> - you can't search on cc: or keywords fields.
>> That's going to be a problem for arch testing needs (e.g. STABLEREQ
>> keyword and x86@ cc-ed). How about doing the searches "the old way" that
>> allowed the above.
>
> That is not so easy to do since we have completely gotten rid of the old
> method of communicating with bugzilla. That method was not reliable and
> had broken several times with bugzilla upgrades, but using the web
> services will be more stable.

Right, scraping HTML that way was obviously brittle, but at least it
worked (in the pragmatic sense). Without that functionality, the
batch-stabilization tools I and other devs use would be broken.

If possible, please restore the old code, possibly marked as deprecated
and not officially supported (best effort, patches welcome is fine), and
named maybe search_brittle or something similar.

pybugz call for testers
 

On Wed, Apr 11, 2012 at 7:55 AM, "Paweł Hajdan, Jr."
<phajdan.jr@gentoo.org> wrote:
> On 4/10/12 11:17 PM, William Hubbs wrote:
>> On Tue, Apr 10, 2012 at 10:45:14PM +0200, "Paweł Hajdan, Jr." wrote:
>>> On 4/10/12 7:54 PM, William Hubbs wrote:
>>>> I can name a couple of issues that are api limitations that we can't do
>>>> anything about:
>>>> - you can't search on cc: or keywords fields.
>>> That's going to be a problem for arch testing needs (e.g. STABLEREQ
>>> keyword and x86@ cc-ed). How about doing the searches "the old way" that
>>> allowed the above.
>>
>> That is not so easy to do since we have completely gotten rid of the old
>> method of communicating with bugzilla. That method was not reliable and
>> had broken several times with bugzilla upgrades, but using the web
>> services will be more stable.
>
> Right, scraping HTML that way was obviously brittle, but at least it
> worked (in the pragmatic sense). Without that functionality, the
> batch-stabilization tools I and other devs use would be broken.
>
> If possible, please restore the old code, possibly marked as deprecated
> and not officially supported (best effort, patches welcome is fine), and
> named maybe search_brittle or something similar.
>

Do you need the command line front end for your arch testing
utilities, or are you using the bugzilla.py module directly? If the
latter, I think it would be possible to restore the old bugzilla.py
module, possibly with a different name.

If you actually need the front end (bugz and cli.py), it would
probably be easier for you to just have two copies of pybugz: an old
version for searching and a new version for making changes.

pybugz call for testers
 

On 4/13/12 5:19 AM, Mike Gilbert wrote:
> Do you need the command line front end for your arch testing
> utilities, or are you using the bugzilla.py module directly? If the
> latter, I think it would be possible to restore the old bugzilla.py
> module, possibly with a different name.

Just the module, bugzilla.py.

For reference, the project is here:
<http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=summary>