Closed Bug 449540 Opened 16 years ago Closed 16 years ago

Move Solaris contrib. builds onto Bouncer to count the download number

Categories

(Release Engineering :: General, defect, P3)

All
SunOS
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dave.lin, Assigned: joduinn)

References

Details

Would like to send the request to move Solaris contributed builds onto Bouncer, so that we can do the statistics such as download number on each Solaris version and etc.

Dave
Component: www.mozilla.com → Release Engineering
Product: Websites → mozilla.org
QA Contact: www-mozilla-com → release
Version: unspecified → other
How much information are you hoping to get from this ? Currently the bouncer interface only exposes an overall count for a "product", which is setup as the combination of the application and version (eg Firefox-3.0.1). It doesn't break it down by platform at all, although perhaps this is available by querying the database. 
The file name of the builds and the download number of them. The platform could be distinguished by the file name. And if it's possible, we also want to know the download user's informations, such as what kind of browser does user use and etc.

Thanks
Dave
Trevor, Daniel, do you have any suggestions on how to achieve this ? My guess is that bouncer isn't suitable.
Is there any access available for the contributors(like me) to the bouncer database? 
Once in bouncer, we can get all this information for Dave via http logs and the existing stats infrastructure.  Right now it's not possible as they are on releases, and we don't have logs for the releases mirror hosts.  Hence the bug to get solaris builds into bouncer.
Assignee: nobody → joduinn
Status: NEW → ASSIGNED
Priority: -- → P3
Summary of offline email/irc.

Alfred/Dave are providing Firefox builds for four different versions of Solaris:

Solaris10 for i386
Solaris10 for sparc
OpenSolaris for i386
OpenSolaris for sparc

Bouncer is already configured to support "solaris-i386", and "solaris-sparc" for Solaris10 builds of Sunbird, and can be used for the Solaris10 builds of Firefox. 

I've now added "opensolaris-i386" and "opensolaris-sparc" platforms to Bouncer, which can be used by any OpenSolaris contributor, including Alfred/Dave. :-)
Note that currently, for each of:

Solaris10 for i386
Solaris10 for sparc
OpenSolaris for i386
OpenSolaris for sparc

...there are *two* different Solaris contrib products created (source-tarball and pkgadd).

However, for a given release, of a given product, on a given o.s., Bouncer only allows referencing one file. This means we could have Bouncer track download stats for one or the other, but not both. Changing bouncer to do this seems too risky. Alfred/Dave are going to meet and discuss which file they wanted to have bouncer count downloads on.

Note: having multiple files in the contrib directory, and shared across mirrors, and made visible through ftp.m.o is file. This is only about bouncer count downloads.

(One workaround considered was to declare the source-tarball and pkgadd as two different products, but that means defining a "decoy product/release/version" and then manually adding *8* entries to bouncer, per release, just for Solaris. This seems unwieldy, especially as recurring manual work for just one product. We dont do this for any other products.)
I've now manually added the FF3.1b1 contrib builds for opensolaris to bouncer. For now, this is got the following URLs working through bouncer:

http://www.mozilla.com/en-US/products/download.html?product=firefox-3.1b1&os=opensolaris-i386&lang=en-US
...links to:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/3.1b1/contrib/solaris_tarball/firefox-3.1b1.en-US.opensolaris-i386.tar.bz2

http://www.mozilla.com/en-US/products/download.html?product=firefox-3.1b1&os=opensolaris-sparc&lang=en-US
...which links to:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/3.1b1/contrib/solaris_tarball/firefox-3.1b1.en-US.opensolaris-sparc.tar.bz2

These URLs are the same format as used for other Firefox releases on other o.s., so once the website download button is fixed (bug#433622), this should work just fine for Solaris users. I've already verified that those bouncer URLs work fine for Mac and Win32 users.


Alfred/Dave, before we announce these URLs or link to them in rel-notes, can you manually verify these URLs work on your Solaris machines? Also, I can easily change to use the pkgadd bz2 files instead, if thats your preference.
My downloads log file processing was not previously accepting solaris in the OS field and if any solaris files were downloaded, it would have lumped them into the "Unknown" category.

I've added them to the list which now consists of:
win
linux
osx
osxppc
solaris-sparc
solaris-i386
opensolaris-sparc
opensolaris-i386


Are there any other valid values for the &os= parameter of bouncer links?
(In reply to comment #9)
We also have a "none" defined, which is used for a small number of one-off things.
oops, I left that one out because it is checked in a different place, but that is handled in my processing as is "all" which I saw some small number of entries for.

Anything other than the list above, "all" or "none" will get changed to Invalid in the dashboard.
John, thanks a lot and IRC is better than email with timezone problem :) The links above works for me nicely. The tarball format binary is fine and it's good to keep consistent with what Mozilla does for Linux builds.

I think then the problem remained is how to distinguish Solaris 10 and OpenSolaris. There is one single Linux build for different Linux distros and I think it might not work for old system for GNOME dependency. That's why we do separately for Solaris 10 and OpenSolaris.

However, the useragent string can only tell whether it's a Linux or Windows or Solaris. To change such a thing with long history is a bad idea I think.

Could we have two green download buttons on mozilla.com for Solaris 10 and OpenSolaris and let the users decide which one they want? Something like below:
 _____________   _____________
|   Download  | |  Download   |
| OpenSolaris | | Solaris 10  |
|_____________| |_____________|
 Release Notes   Other System and Languages

Or add another link like below?
 _____________ 
|   Download  |
| OpenSolaris |
|_____________|
 Release notes   Other System and Languages  Contributed builds
(In reply to comment #12)
> John, thanks a lot and IRC is better than email with timezone problem :) The
> links above works for me nicely. The tarball format binary is fine and it's
> good to keep consistent with what Mozilla does for Linux builds.
Cool.

So, for future releases, you'll just provide bz2 format, skip pkgadd, and create a bug with mozilla.org:RelEng to add the entries to bouncer.

Did you sort out the rel-notes, or will that need a new bug per release also?


> I think then the problem remained is how to distinguish Solaris 10 and
> OpenSolaris. There is one single Linux build for different Linux distros and I
> think it might not work for old system for GNOME dependency. That's why we do
> separately for Solaris 10 and OpenSolaris.
> 
> However, the useragent string can only tell whether it's a Linux or Windows or
> Solaris. To change such a thing with long history is a bad idea I think.
> 
> Could we have two green download buttons on mozilla.com for Solaris 10 and
> OpenSolaris and let the users decide which one they want? Something like below:
>  _____________   _____________
> |   Download  | |  Download   |
> | OpenSolaris | | Solaris 10  |
> |_____________| |_____________|
>  Release Notes   Other System and Languages
> 
> Or add another link like below?
>  _____________ 
> |   Download  |
> | OpenSolaris |
> |_____________|
>  Release notes   Other System and Languages  Contributed builds

Pity about the duplicate useragent strings. I think the new issue about changing the Mozilla website download buttons should be handled by a separate bug in websites::www.mozilla.com or maybe mozilla.org:AUS (or both?). Your description here is a great summary. (Also, I wonder if there may even be a way to handle this with some more fine grain user agent string detection?)

Meanwhile, there's nothing left for RelEng to do here, so closing this bug.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
(In reply to comment #13)
> So, for future releases, you'll just provide bz2 format, skip pkgadd, and
> create a bug with mozilla.org:RelEng to add the entries to bouncer.
We'd still like to upload two formats of Firefox release to Mozilla server, and put the tarball one for bouncer. Is this fine?

> Did you sort out the rel-notes, or will that need a new bug per release also?
If we can go with the two green buttons solution, then it's not necessary to add links to the release notes, thus no need to create bug for each contributed build. Otherwise, the links to point to the contributed builds are still necessary and still need to file bug for that.

> Pity about the duplicate useragent strings. I think the new issue about
> changing the Mozilla website download buttons should be handled by a separate
> bug in websites::www.mozilla.com or maybe mozilla.org:AUS (or both?). Your
> description here is a great summary. (Also, I wonder if there may even be a way
> to handle this with some more fine grain user agent string detection?)
I notice that the latest Firefox 3.0.3 on Ubuntu adds a postfix "Ubuntu/8.04 (handy)" for the useragent string. Maybe the bouncer could have some fine grain detection based on this?

> Meanwhile, there's nothing left for RelEng to do here, so closing this bug.
Well, I'll create bugs to track down the issues remained. Thanks for the work, John.
(In reply to comment #14)
> I notice that the latest Firefox 3.0.3 on Ubuntu adds a postfix "Ubuntu/8.04
> (handy)" for the useragent string. Maybe the bouncer could have some fine grain
> detection based on this?

Bouncer just looks at the request url, eg 
 http://download.mozilla.org/?product=firefox-3.0.3&os=win&lang=en-US
and doesn't look at the UA, so that'd be another thing for mozilla.com to do.
Blocks: 461116
Blocks: 461118
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.