Object v. bugzilla-type confusion ... any thoughts on it?

[Matej Cepl]

Hi,

so I am now in the stage, that I use default (aka trunk) for my daily 
work, so I have some time to think about some higher level stuff. 
Remaining exact tasks are all posted to the Tracker, so that whoever 
wants to look at them and send me a patch is more than welcome.

First of all I have this confusion between type of bugzilla (i.e., URL 
we are currently on in Firefox) and type of bugzilla model we use (i.e., 
in lib/main.js around line 145).

The idea is that types of objects used (i.e., MozillaBugzilla v. 
RHBugzillaPage v. whatever-else-somebody-writes; could we call them 
"models"?) should differentiate between the style of UI we want to have 
(more complicated my style v. much lighter Philipp's style) on whatever 
bugzilla we are. On the other hand scripts must distinguish between 
different bugzilla instances, because of differences between them (e.g., 
does b.m.o has XML-RPC method bugzilla.updateAttachMimeType for getting 
rid of all those application/octet-stream attachments?). Everything 
which could be at least theoretically useful for both models should go 
to their shared parent BZPage.

This is the idea, but the problem is that I work almost exclusively on 
bugzilla.redhat.com (and bit of b.m.o but I cannot do much there) so I 
am afraid those two concepts got incredibly mixed together. I would 
really need somebody else to start using my code on b.m.o (or elsewhere) 
and hitting all those RH-centric warts.

Possible option is announce the project on some lists where other bug 
triagers socialize to find more users.

Andre, BTW, do you think that there is nothing here which could be 
useful on b.gnome.org?

Comments?

Best,

Matěj

[Andre Klapper]

Hi Matěj,

finally this evening I found an hour to look a bit into this.
(Better late than never.) Sorry, was/am busy with work, university
exams, and my own guadec presentation...

Am Donnerstag, den 24.06.2010, 14:12 +0200 schrieb Matěj Cepl:
> The idea is that types of objects used (i.e., MozillaBugzilla v. 
> RHBugzillaPage v. whatever-else-somebody-writes; could we call them 
> "models"?) should differentiate between the style of UI we want to have 
> (more complicated my style v. much lighter Philipp's style) on whatever 
> bugzilla we are. On the other hand scripts must distinguish between 
> different bugzilla instances, because of differences between them (e.g., 
> does b.m.o has XML-RPC method bugzilla.updateAttachMimeType for getting 
> rid of all those application/octet-stream attachments?). Everything 
> which could be at least theoretically useful for both models should go 
> to their shared parent BZPage.

I expected RHBugzillaPage to be a derived class of a generic Bugzillas
extension class, but maybe I don't get the concept yet.

Looking at the available functions it looks quite powerful and probably
has the potential to supersede all those homegrown Greasemonkey scripts
that are currently around, if you/we manage to get the "critical mass"
together (advanced bugtriagers from several projects)

The GreaseMonkey script that I currently use for bugs.maemo.org is at
http://home.arcor.de/ak-47/pub/bugsmaemoorg_triage_help.user.js and
basically is just a copy of the "Stock Answers" functionality from GNOME
Bugzilla, nothing else.
In GNOME Bugzilla stuff like the clickable "Stock answers" when you go
on any open bug report is patched into the code on the GNOME Bugzilla
server, see
http://git.gnome.org/browse/bugzilla-newer/tree/template/en/default/bug/edit... and search for "addStockLink".
I'm not aware of much other stuff that is used in GNOME Bugzilla, have
to dive deeper into your docs to say more.

Stuff like sendBugUpstream() in RHBugzillaPage definitely looks useful
for my work in bugs.maemo.org but so far I miss a basic introduction to
the concept of all this (I suck in reading API docs because I'm a quite
bad developer).
> Andre, BTW, do you think that there is nothing here which could be 
> useful on b.gnome.org?

I think I need more documentation to answer this (already starts at the
very beginning: What to do exactly after checking out the hg repository
and installing JetPack in Firefox by going to
https://jetpack.mozillalabs.com/install.html to get this loaded and
visible in a browser page, probably bugzilla.redhat.com?).
Many bugtriagers are no developers (I don't consider myself to be one
either) and hence need an idiotproof how-to...
Make the barrier lower to join and play around with it. :-)

Also, some documentation seems vague (RHBugzillaPage/closeSomeRelease:
"Auxiliary function to computer more complicated resolution" - what does
that mean?)

Hope this initial feedback is helpful & see you at GUADEC!,

andre

[Matej Cepl]

Dne 25.7.2010 21:55, Andre Klapper napsal(a):
> I expected RHBugzillaPage to be a derived class of a generic Bugzillas
> extension class, but maybe I don't get the concept yet.

OK, couple of changes (I was more thorough on my blog 
http://mcepl.blogspot.com/ ... given the level of response I've got here):

- the official git repo (yes, git, I am not good enough for mercurial) 
is git://git.fedorahosted.org/bugzilla-triage-scripts.git
- you need only Jetpack SDK (from 
http://hg.mozilla.org/labs/jetpack-sdk/ or from my Git mirror at 
git://repo.or.cz/jetpack-sdk.git)

git clone git://repo.or.cz/jetpack-sdk.git
. bin/activate
cd packages
git clone git://git.fedorahosted.org/bugzilla-triage-scripts.git

and then you can run

cfx run

(on temporarily generated completely clean profile)

cfx xpi

makes you .xpi file which can be installed in your firefox as any other 
.xpi extension

This gives you the very bleeding edge whatever I have in repo. This is 
meant for developers. For users see below.
> In GNOME Bugzilla stuff like the clickable "Stock answers" when you go
> on any open bug report is patched into the code on the GNOME Bugzilla
> server, see
> http://git.gnome.org/browse/bugzilla-newer/tree/template/en/default/bug/edit... and search for "addStockLink".
> I'm not aware of much other stuff that is used in GNOME Bugzilla, have
> to dive deeper into your docs to say more.

Of course, given my presentation is on GUADEC stock buttons on b.g.o are 
my biggest problem. Later if I found some other bugzillas I will look 
for some solution to this.
> Stuff like sendBugUpstream() in RHBugzillaPage definitely looks useful
> for my work in bugs.maemo.org but so far I miss a basic introduction to
> the concept of all this (I suck in reading API docs because I'm a quite
> bad developer).

it collects all comments from the current bug and then fills in the 
upstream bugzilla with appropriate values (of course the description is 
just a concatenation of all comments, so it needs heavy editing)
> I think I need more documentation to answer this (already starts at the
> very beginning: What to do exactly after checking out the hg repository
> and installing JetPack in Firefox by going to
> https://jetpack.mozillalabs.com/install.html to get this loaded and
> visible in a browser page, probably bugzilla.redhat.com?).

See above. We are in the later version of Jetpack development (we are in 
so called Jetpack-SDK, whereas you are talking about previous now 
abandonded Jetpack-prototype) which doesn't require special Jetpack 
extension to Firefox, but just to the contrary it generates Firefox 
extensions.
> Many bugtriagers are no developers (I don't consider myself to be one
> either) and hence need an idiotproof how-to...

The above HOWTO is for developers of my extensions. As for users, I hope 
in future the HOWTO will be ... go to 
https://addons.mozilla.org/cs/firefox/addon/192496/ and install the 
extension. However, currently the one on AMO is not updated and not 
reviewed. Current latest .xpi (sometimes raw experimental) is at 
https://fedorahosted.org/released/bugzilla-triage-scripts/bugzilla-triage.xp... 
(semi stable releases are in the same directory and I hope to be able to 
make updates working before I get to AMO).
> Also, some documentation seems vague (RHBugzillaPage/closeSomeRelease:
> "Auxiliary function to computer more complicated resolution" - what does
> that mean?)

RHBugzillaPage object is not meant for you. You can of course take 
whatever you want from it, but it is mostly intended as a superset for 
RH Bugzilla. I think you should be better with MozillaPage (set in the 
Configuration URL 
https://fedorahosted.org/released/bugzilla-triage-scripts/Config_mozilla.jso... 
to get Mozilla version which should be pretty plain one for you; and of 
course feel free to copy .json to your server and customize it to your 
heart's content).
> Hope this initial feedback is helpful&  see you at GUADEC!,

Yeah. Looking forward to see you!

Matěj