539082 - Add the Bugzilla Tweaks jetpack to the top of b.m.o pages

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: General, defect)

Description

[(no longer active)]

The bugzilla tweaks jetpack which Johnath and I have been working on seems to be working well, and useful for the general audience.  Therefore, we think it's a good idea to advertize it in the "maintenance message area" of b.m.o so that we can both get feedback and get the message to other people.

The code for the Jetpack lives in <http://hg.mozilla.org/users/jnightingale_mozilla.com/jetpacks/>.  We would need a cron job set up to update it let's say every five minutes or so, and we also need an .htaccess which makes sure the |Cache-Control: private| header is sent with the js file so that Jetpack can actually update it to newer versions without users needing to mess with their browser cache.

Here is the wording that Johnath suggested for the prompt:

We are testing a few feature that integrates history into bugs. - [Learn More], [Try it], [Comment on the implementation that goes into Bugzilla core].

with these links:

[] http://ehsanakhgari.org/blog/2010-01-07/bugzilla-tweaks-enhanced
[] the page which hosts this jetpack on bugzilla
[] https://bugzilla.mozilla.org/show_bug.cgi?id=11368

Comment 1

[Johnathan Nightingale [:johnath]]

(In reply to comment #0)

> Here is the wording that Johnath suggested for the prompt:
> 
> We are testing a few feature that integrates history into bugs. - [Learn More],
> [Try it], [Comment on the implementation that goes into Bugzilla core].
> 
> with these links:
> 
> [] http://ehsanakhgari.org/blog/2010-01-07/bugzilla-tweaks-enhanced
> [] the page which hosts this jetpack on bugzilla
> [] https://bugzilla.mozilla.org/show_bug.cgi?id=11368

Slight rev:

We are using [jetpack] to test a new feature that integrates bug activity into the main page for each bug. [Learn More], [Try it yourself], [Comment in the implementation bug]

[] https://jetpack.mozillalabs.com/
[] http://ehsanakhgari.org/blog/2010-01-07/bugzilla-tweaks-enhanced
[] the page which hosts this jetpack on bugzilla
[] https://bugzilla.mozilla.org/show_bug.cgi?id=11368

Comment 2

[Max Kanat-Alexander]

I think this is a great idea. I think it would be better to advertise it just on the index page, though, so that it's not taking up space on every page and confusing novice reporters.

Comment 3

[(no longer active)]

Do you mean the homepage by the "index page"?  If that's the case, then I don't think that it's a good thing to do, because nobody besides first time users actually uses that page.  :-)

But I agree that it shouldn't probably appear on the bug reporting page, but I think it should appear in all listing and show_bug pages.

Comment 4

[Max Kanat-Alexander]

Well, I don't know that a beta product should really be appearing on every single page. Perhaps some other way of more-broadly advertising it would be more appropriate.

Comment 5

[Johnathan Nightingale [:johnath]]

I think I understand your concern, Max, and I certainly don't want to create a nuisance either - but I do think that show_bug.cgi is the best way of reaching our target users.

How about, to reduce nuisance and still get us some testers, we do two things:

1) Get set up to host the jetpack somewhere on bugzilla, with a cron job to keep it up to date

2) Add it to the "maintenance" blurb at the top of pages (or even just show_bug.cgi if we can constrain it that way) for 24 hours.

One day of prodding should get us more users, more interested fiddling, and more comments on the eventual implementation, but it shouldn't hurt the overall experience of bugzilla very much. We risk missing a lot of would-be contributors who were on vacation or just working on other things that day, but I think that's an okay price to pay for a beta feature, as you say.

Comment 6

[Max Kanat-Alexander]

Fair enough--24 hours is reasonable.

Anyhow, I'm not the person you'll have to convince; you'd have to convince Mozilla IT.

Comment 7

[Dave Miller [:justdave]]

I'm willing to do it, I was just leaving it sit for a few to get community opinions on the best way to do it first. :)

Comment 8

[Dave Miller [:justdave]]

Is there an official download site for it?  Seems like we ought to point at that rather than hosting it on Bugzilla...

Comment 9

[Johnathan Nightingale [:johnath]]

(In reply to comment #8)
> Is there an official download site for it?  Seems like we ought to point at
> that rather than hosting it on Bugzilla...

I think we'd like Bugzilla to be that place.  :)

The code in development lives my in hg repo ( http://hg.mozilla.org/users/jnightingale_mozilla.com/jetpacks/ ) but pointing directly to the hgweb interface might be a problem because we can't control the headers that are sent with those requests, and jetpack seems to have a bug where it occasionally uses a cached copy of the jetpack instead of going back to the source.

When I originally blogged about it, I hosted a copy in my people account ( http://people.mozilla.org/~johnath/jetpacks/bugzilla-tweaks.html ), which does set a "Cache-Control: no-cache" header. Ehsan similarly hosted a copy when he updated it. We both have cron jobs which update our copies of the code on a regular basis.

We could use my people account one for our purposes here, if we believe that getting it into the bugzilla upstream is a plausible reality in reasonable time. But throwing it in a directory somewhere in b.m.o-space with the same cron job I have feels like it might stand up a little better to the vagaries of time. Having a resident jetpack on our bugzilla instance is also nice because it gives us a place to put future changes and enhancements (e.g. instance-specific context menu actions or browser UI). We could do those from my people account too, depends how fleeting we think this experiment is.

SO:

 - If you think it will be relatively painless to throw this somewhere on bugzilla, I can paste in my .htaccess and cron job contents, and we can link to that one as the official source

 - If you think it will be painful, or otherwise not worth the effort to do that, we can use the version in my people account in the name of expediency.

Comment 10

[(no longer active)]

(In reply to comment #9)
> (In reply to comment #8)
> > Is there an official download site for it?  Seems like we ought to point at
> > that rather than hosting it on Bugzilla...
> 
> I think we'd like Bugzilla to be that place.  :)

I agree, mostly because of what Johnath mentioned below, but I'm also adding a few points here.

> The code in development lives my in hg repo (
> http://hg.mozilla.org/users/jnightingale_mozilla.com/jetpacks/ ) but pointing
> directly to the hgweb interface might be a problem because we can't control the
> headers that are sent with those requests, and jetpack seems to have a bug
> where it occasionally uses a cached copy of the jetpack instead of going back
> to the source.

Actually, as it turns out, that bug only happens when you manually go to about:jetpack and hit Refresh for a Jetpack.  Specifically, I have _not_ set the Cache-Control header on my server, and Jetpack is happily updating things in the background for me (I've installed the jetpack from my own server).

> When I originally blogged about it, I hosted a copy in my people account (
> http://people.mozilla.org/~johnath/jetpacks/bugzilla-tweaks.html ), which does
> set a "Cache-Control: no-cache" header. Ehsan similarly hosted a copy when he
> updated it. We both have cron jobs which update our copies of the code on a
> regular basis.

Actually, I am not using a cron job on my server, I update manually when I'm sure everything is fine.  Here is my rough release workflow:

1. I commit things locally.
2. I give it some amount of testing.
3. I push it to hg.m.o.
4. I give it some more testing.
5. I update my server's version to tip manually when I'm sure everything is safe.

So, my server's version is always updated to a fully tested version, and Johnath's is always updated to a most-likely fully tested version.

That said, I consider the Jetpack mostly stable from now on.  There are no more new features that I can think of for now, and it will possibly get bug fixes more than anything else from now on (unless someone comes up with another really cool idea!)

> We could use my people account one for our purposes here, if we believe that
> getting it into the bugzilla upstream is a plausible reality in reasonable
> time. But throwing it in a directory somewhere in b.m.o-space with the same
> cron job I have feels like it might stand up a little better to the vagaries of
> time. Having a resident jetpack on our bugzilla instance is also nice because
> it gives us a place to put future changes and enhancements (e.g.
> instance-specific context menu actions or browser UI). We could do those from
> my people account too, depends how fleeting we think this experiment is.

One thing to note here is that the current Jetpack is mostly instance-specific.  Specifically, I haven't tested it against any other instance.  And since it's been quite a while since I have worked with a pristine Bugzilla installation, I might have been assuming instance specific details in my implementation...

But IMHO hosting it on Bugzilla is a good choice if only for the prestige of it.  :-)

> SO:
> 
>  - If you think it will be relatively painless to throw this somewhere on
> bugzilla, I can paste in my .htaccess and cron job contents, and we can link to
> that one as the official source
> 
>  - If you think it will be painful, or otherwise not worth the effort to do
> that, we can use the version in my people account in the name of expediency.

I agree with both of these.  In short, I think if hosting it on Bugzilla is too much of a hassle and delays things, it's not worth it.

Comment 11

[Dave Miller [:justdave]]

The Bugzilla site itself is a bzr checkout of the Bugzilla application.  I think it'd probably work better if we put it on ftp.mozilla.org or somesuch.

Comment 12

[Daniel Veditz [:dveditz]]

Jetpack updates just re-check the original source URL, right? If you host that on http: (as it currently has been in both Johnath's and Ehsan's copies) then you're updating injected code over an insecure channel. Code that explicitly has to all your bugs at least (including private bugs), and whatever enhanced privileges are possible with the current Jetpack implementation.

Hosting it on Bugzilla at least gives it an SSL url. Please don't advertise this Jetpack to large numbers of people on BMO unless you're able to give it an SSL link.

As it happens people does support SSL, so changing Johnath's original link to https://people.mozilla.com/~johnath/jetpacks/bugzilla-tweaks.html would be much better than what he's currently advertising (note .com rather than .org to avoid cert mismatch).

Comment 13

[Johnathan Nightingale [:johnath]]

Dan's right - when we filed this bug, my expectation was that putting it on bugzilla would eliminate the http risk, so I didn't even mention it. Then, when that came up as being a problem and I offered my people space, I just forgot that the current link is http instead of https, since I had already checked off the "safe" checkbox in my head.

Mea culpa - this needs to be https.

Comment 14

[Dave Miller [:justdave]]

ftp.mozilla.org supports https also, fwiw.  It had to for NSS to get some federal certification.

Comment 15

[David Lawrence [:dkl]]

Closing. This has been out long enough that most people know about it. Also some of the features of Bugzilla Tweaks are on the roadmap to be integrated into Bugzilla itself. I am not for placing links to it on all Bugzilla pages anyway.