[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: file bugs to bugzilla from anaconda



> So this is something that we've talked about off and on for, umm, way
> too long to think about at this point.  So it's probably something that
> we should think heavily about.  But some questions that would also need
> to be answered

Well now that we've got code, it's no longer a theoretical exercise.  It
helps that Will already wrote the hard part.

> * bugUrl doesn't have to be a bugzilla instance.  And are the XML-RPC
> methods being used even available at other bugzilla instances?  There
> probably needs to be a way to say that this bug instance "supports"
> things filed in this manner.

Unknown as to whether other bugzillas support the XML-RPC.

>   * Maybe this should be rolled in to the question of what to do about
> product.img

Agreed.  I'd kind of like to see all the product-related stuff disappear
out of some dot-file in the tree and into whatever we do about
product.img.

> * Keeping scp support seems to have some value, so I don't know that I'd
> replace it.  Not sure what the right UI then is for choosing what to do
> with your traceback.  Maybe something like the firefox download dialog
>     [-----------------------------------]
>     | Blah.  We crashed.  Some info.    |
>     |    v Traceback details            |
>     | o Save to local disk              |
>     | o Send to bugzilla                |
>     | o Save to remote server           |
>     [-----------------------------------]

Sure, something like this is easy enough to do.  Looks like there's
enough support on the list for keeping it, even though I don't really
care to.  I always viewed it as a stop-gap until we got something
better.

> * Should think hard about the right things to hash on.  Especially given
> different products using the same/similar anaconda

Right now I'm taking the raw Python stack trace information and
concatenating each stack frame's file, function, and code text together
and then doing a sha256 on it.  I skip the line number since those could
change from build-to-build, and I skip the actual exception message
("RuntimeError: blah blah blah") because that could have information
that changes from run-to-run, but is still the same traceback.

I want to make sure the hashing is right before committing any of this.
Once bugs start getting filed through it, it'll be too late to change
the hashing without missing dupes.

> * It's a little scary to do this without a triager on the primary place
> we expect to be getting the bugs... :)

Agreed.  If the hashing's good it should mitigate things somewhat
though.  Also keep in mind you have to have a bugzilla account in order
to file bugs so there's still that one hurdle between us and the masses.

- Chris


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]