We want to track Aurora version downloads separately and have distinct bouncer entries for them for use on the website. An example (thanks Rail) would be http://download.mozilla.org/?product=firefox-aurora-13.0&os=win&lang=af

Hmm, I'm not sure what to do with l10n builds... They live in a different directory, so Bouncer's ":lang" replacement won't work here... http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora-l10n/ vs http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/

(In reply to Rail Aliiev [:rail] from comment #1) > Hmm, I'm not sure what to do with l10n builds... They live in a different > directory, so Bouncer's ":lang" replacement won't work here... > > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora- > l10n/ > vs > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/ symlink in latest-*-l10n to the en-US versions and use :lang for the magic-fun?

can we get help from metrics to get this data from ftp logs instead?

(In reply to Chris AtLee [:catlee] from comment #3) > can we get help from metrics to get this data from ftp logs instead? Here's the response from the metrics team on that subject: "The release process for Aurora has the product download link (on http://www.mozilla.org/en-US/firefox/aurora/ ) as a direct link to one of our FTP sites instead of going through "bouncer" (download.mozilla.org), our mirror distribution network. We are not set up to process download data from FTP sources, and if the download traffic does not go through bouncer, we cannot track it in a meaningful way."

Hi Alex, I wanted to follow up on this bug. What's the next steps here? Thanks!

Ok, just had a chat with Ben and Rail about this. A fast way forward is to create two bouncer products: one for en-US builds and one for localized builds. We need this distinction because the en-US builds for aurora are in a different directory structure than the l10n repacks, unlike for beta or release builds. This is easy to set up on our side, but requires that the download link on the web side be different depending on if you're downloading en-US or one of the repacks.

(In reply to Chris AtLee [:catlee] from comment #6) > This is easy to set up on our side, but requires that the download link on > the web side be different depending on if you're downloading en-US or one of > the repacks. I'm including James and Laura to see if this would be a problem.

Bouncer links would look something like this: for en-US only: http://download.mozilla.org/?product=firefox-13.0a2&os=osx&lang=en-US for other locales: http://download.mozilla.org/?product=firefox-13.0a2-l10n&os=osx&lang=af

Brandon can take care of any Bouncer changes needed (I'm unclear exactly what if anything needs to change other than data?), then it's over to jlongster for mozilla.org changes.

(In reply to Laura Thomson :laura from comment #9) > Brandon can take care of any Bouncer changes needed (I'm unclear exactly > what if anything needs to change other than data?), then it's over to > jlongster for mozilla.org changes. ping?

See dependency bug 750798. That blocks about five changes to bouncer.

Looking over the code I don't see code changes being necessary for this. Over to jlongster for his input.

(In reply to Alex Keybl [:akeybl] from comment #7) > (In reply to Chris AtLee [:catlee] from comment #6) > > This is easy to set up on our side, but requires that the download link on > > the web side be different depending on if you're downloading en-US or one of > > the repacks. > > I'm including James and Laura to see if this would be a problem. I think it's just a product-details issue. It probably needs a little bit of code, but not much. Once the URL is ready let us know and we can get Rik or someone on cmore's team to do it.

Note: this bug is *not* currently in active development, but may be needed for the stub installer.

I'm not sure why this is assigned to me... I've never worked on bouncer. Are you wanting the actual Aurora download links changed on mozilla.org? I haven't been working on mozilla.org, so assigning this to malexis to figure out who should do this.

I think there are two parts here: 1. put aurora downloads through bouncer 2. make the links on mozilla.org point to the correct place. Right now this bug is in releng. I propose using it as a tracker and filing bugs for 1. and 2. in the appropriate products (Webtools::Bouncer and www.mozilla.org::General).

(In reply to Laura Thomson :laura from comment #16) > I think there are two parts here: > 1. put aurora downloads through bouncer > 2. make the links on mozilla.org point to the correct place. > > Right now this bug is in releng. I propose using it as a tracker and filing > bugs for 1. and 2. in the appropriate products (Webtools::Bouncer and > www.mozilla.org::General). Laura, I filed for updating links on moz.org. Can you file the bouncer bug?

Looking at this bug again, I'm still unsure that any code changes are required. Bouncer supports the creation of multiple products and does not enforce specific restrictions on their name. Creating a firefox-aurora-<version> product shouldn't be a problem. Am I missing something about this bug that would otherwise require some code adjustments?

:brandon: Can you provide a few URLs to bouncer for aurora builds so that we can test?

(In reply to Chris More [:cmore] from comment #19) > :brandon: Can you provide a few URLs to bouncer for aurora builds so that we > can test? http://download.mozilla.org/?product=firefox-aurora-latest&os=win&lang=en-US is the link to the full installer. That's the only one we need AFAIK.

Laura/Ben: Are you ready for mozilla.org to be updated to point to d.m.o instead of FTP? Stub and full?

We already have http://download.mozilla.org/?product=firefox-aurora-latest&os=win&lang=en-US. That's subject to https://bugzilla.mozilla.org/show_bug.cgi?id=798486, though.

Can we have something in the form of http://www.mozilla.org/en-US/products/download.html?product=firefox-17.0a2&os=osx&lang=en-US? On www.mozilla.org, that would make things easier. We would send all Aurora downloads to Bouncer, not only those that match our initial stub installer platform/locales.

(In reply to Anthony Ricaud (:rik) from comment #23) > Can we have something in the form of > http://www.mozilla.org/en-US/products/download.html?product=firefox-17. > 0a2&os=osx&lang=en-US? On www.mozilla.org, that would make things easier. We > would send all Aurora downloads to Bouncer, not only those that match our > initial stub installer platform/locales. I'm not sure if that question was for me or not, but that's not a website I have any influence over.

Sorry, I meant something like https://download.mozilla.org/?product=firefox-17.0a2&os=osx&lang=en-US

Is it possible to do this same thing for nightly builds so that we can make mozilla.org nightly aware without any additional magic?

Bhearsum is going to create all product entries in bouncer for all platforms and languages so that we can adjust the website to point to d.m.o instead of ftp.

(In reply to Chris More [:cmore] from comment #27) > Bhearsum is going to create all product entries in bouncer for all platforms > and languages so that we can adjust the website to point to d.m.o instead of > ftp. cmore: This surprised catlee + myself in a lull with the stub-installer-on-beta fun. Once everyone has slept and can focus, can you+bhearsum clarify this, and decide what is next step here?

We've found a way to link to the stub installer inside mozilla.org. This is tracked in bug 794499. So no need to create Bouncer links for Aurora for the stub installer project. Removing [stub+]. Keeping the bug open though as it will be a nice to have in the future.

(In reply to John O'Duinn [:joduinn] from comment #28) > (In reply to Chris More [:cmore] from comment #27) > > Bhearsum is going to create all product entries in bouncer for all platforms > > and languages so that we can adjust the website to point to d.m.o instead of > > ftp. > > cmore: This surprised catlee + myself in a lull with the > stub-installer-on-beta fun. Once everyone has slept and can focus, can > you+bhearsum clarify this, and decide what is next step here? I don't see any comment in this bug as to why we've decided on bug 794499 instead of this one. That bug should do for stub installer, but was this deemed to difficult for some reason? This is a /long/standing request from marketing, so each time we kick the can down the road it hurts me.

(In reply to Alex Keybl [:akeybl] from comment #30) > (In reply to John O'Duinn [:joduinn] from comment #28) > > (In reply to Chris More [:cmore] from comment #27) > > > Bhearsum is going to create all product entries in bouncer for all platforms > > > and languages so that we can adjust the website to point to d.m.o instead of > > > ftp. > > > > cmore: This surprised catlee + myself in a lull with the > > stub-installer-on-beta fun. Once everyone has slept and can focus, can > > you+bhearsum clarify this, and decide what is next step here? > > I don't see any comment in this bug as to why we've decided on bug 794499 > instead of this one. Because RelEng had a hundred million other things to do last week. > That bug should do for stub installer, but was this > deemed to difficult for some reason? > This is a /long/standing request from marketing, so each time we kick the > can down the road it hurts me. We can still do this. It's not _that_ hard. I think all the work is on RelEng to create/update the bouncer entries. Does that sound right to you, Rik?

Did we decide how we're going to handle the different directory layouts for en-US and l10n repacks?

Is this resolved?

This is resolved.

Is the bouncer link available only for Windows builds? os=osx and os=linux lead 404.

(In reply to Kohei Yoshino [:kohei] from comment #37) > Is the bouncer link available only for Windows builds? os=osx and os=linux > lead 404. Yep. This was only added for stub installer purposes - we don't use it to serve Linux/Mac downloads.

As you know, the product versions on the www.m.o site are manually maintained by the RelEng team, so it sometimes causes dead link issues as reported as Bug 950119 and some other bugs. It would be nice to have the bouncer links also for the Mac and Linux builds.

(In reply to Kohei Yoshino [:kohei] from comment #39) > As you know, the product versions on the www.m.o site are manually > maintained by the RelEng team We never directly touch www.m.o. Links from there that go directly to FTP are maintained by someone else (I'm not sure who). Links from there that go to download.mozilla.org are indirectly maintained by us, because we maintain the absolute versions that links like http://download.mozilla.org/?product=firefox-latest&os=win&lang=en-US point to. > so it sometimes causes dead link issues as > reported as Bug 950119 and some other bugs. bug 950119 is actually unrelated to Bouncer. We link directly to FTP for Linux/Mac Nightly and Aurora builds. The problem there was that we removed the 27.0a2 builds before the 28.0a2 builds were available (a mistake on my part). > It would be nice to have the > bouncer links also for the Mac and Linux builds. I can see how this would avoid the need for someone to bump versions on www.m.o every 6 weeks, but I don't think this would help with the issue described in bug 950119. Automating that clean-up would make it more difficult (impossible?) to break those links. Bug 703559 has discussion on this. I hope this provides some better background, feel free to ping me on IRC if you want to talk about this more.