Monday, March 18, 2013

Goodbye, Google Code; hello, Sourceforge

No one is particularly happy about Google Reader being given the great shiv in the gut, but it also looks like we've outgrown Google Code. I've asked them for over a week and a half about upping our quota with no response, and since there's no paid tier on Google Code, there's no leverage. Self-hosting is not an option given that each release is downloaded over 20,000 times with binaries over 20MB apiece. I can't be angry about a free service declining to offer more space (though I can be irked that they're not responding to my request for a firm answer), but nevertheless the Mozilla rapid release system means we can't live within our current constraints for much longer and it's time to move on. Starting now, we will begin an orderly transition to our new home at Sourceforge, where it's not as snappy and fast as Google Code, but where there's no quota and no need to beg for more capacity.

The orderly transition will happen like this:

  • The home page, blog and Tenderapp end-user support will remain at the same locations until there is a reason to change.
  • This Saturday, 23 March, all aurora or beta releases (i.e., with an "a" or "b" in their version number) will be deleted from Google Code, along with all retracted releases. Changesets will remain; only the binaries will be expunged. This should buy us enough space to get to 24, the expected next ESR and stable release. If you want these binaries, you must grab them by Friday. The only exception will be 4.0b7 and b8, simply for nostalgia.
  • All 17.x stable releases and unstable releases through 22 inclusive will still be uploaded to Google Code as usual, using the space freed up above. I'm pretty confident we'll make it to 24ESR, so I'm going to proceed with that assumption (if we turn out to drop parity sooner, substitute that version for "24" in what follows). Starting with 24 aurora and 24 beta, these releases will be uploaded to Sourceforge, and the expected 24ESR stable branch (and subsequent unstable releases) will be offered only from Sourceforge. The final release of 17 will also be on Sourceforge for posterity. Development on Google Code will cease completely at that time and all links to it will be removed.
  • During the migration to 24ESR, all open issues will be reviewed for relevancy and likelihood of repair. Open issues judged irrelevant and/or unlikely to be fixed will be closed. Other open issues will be reopened at Sourceforge and relevant context transplanted if possible, and then closed on Google Code.
  • Existing wiki release notes will remain at Google Code indefinitely until Google Code declines to maintain the project's files, whenever that is. At that time, they will become permanently unavailable as I don't see any reason to transfer these to the new project. However, currently maintained wiki entries such as the FAQ, build instructions, etc., will be rewritten on Sourceforge during the transition to 24ESR, and all release notes for 24+ will only be on Sourceforge.
  • Remaining archived stable and unstable releases will remain at Google Code indefinitely until Google Code declines to maintain the project's files, whenever that is. At that time, I'll have to decide whether it's worth putting them somewhere else, but until then the files will remain available from there.

Classilla is nowhere near its cap, and Google Code is much friendlier to its browser core, so it will remain where it is; this only affects TenFourFox.

In other news, the 20 port is very nice. You'll get to play with it in a little under two weeks. Besides further improvements to graphics performance, plus WebRTC and user media, you'll also enjoy the new downloads interface which is now finally default and judged ready for primetime. Mozilla continues to concentrate on improving throughput and it's definitely paying off.

Anyway, I think this little experience with Google Code goes to show that everything is only worth what you pay for it. Watch for more news here as we meet transition milestones.

at

6 comments:

  1. vasiMarch 19, 2013 at 12:44 PM

    SourceForge has stated in the past that they have no problem with hosting just files for distribution, even while a project continues to use another site for things like issues, wiki, etc. Are you moving everything at once just as a matter of principle?

    ReplyDelete
    Replies
    1. ClassicHasClassMarch 19, 2013 at 12:50 PM

      a) where?

      b) I'm kind of doubtful about such a policy lasting for too long even assuming it exists, since Sourceforge will need eyeballs for ad revenue and a downloads-only project would seem to tilt their cost-revenue ratio the wrong way.

      c) I don't think Google Code will be around forever and I'd rather just make the switch now since we have to move some things anyway, especially since we're migrating to a service which has a very long track record of stability.

      Delete
    2. vasiMarch 20, 2013 at 4:54 PM

      From here: http://sourceforge.net/blog/github-projects-downloads-are-welcome/

      "SourceForge…welcomes you to distribute your releases via SourceForge even if your code is developed elsewhere."

      I think the cost issue might be better for SF than for GitHub or Google Code, since SF has a network of volunteer mirrors.

      Delete
    3. ClassicHasClassMarch 20, 2013 at 10:00 PM

      Could be (and thanks for the URL). But it still doesn't really address point c), though. One wonders what Google Code's eventual future will be.

      Delete
  2. AnonymousMarch 20, 2013 at 11:37 AM

    http://forums.mozillazine.org/viewtopic.php?p=12744305#p12744305

    Seems that history repeats itself: Baseline Compiler is slated for 23, one cycle before ESR (like JM+TI).

    ReplyDelete
    Replies
    1. ClassicHasClassMarch 20, 2013 at 10:07 PM

      BaselineCompiler is a concern, but dvander said basically JM+TI will not survive generational GC and GGC will not be written with it in mind. GGC would probably be the real deathblow in this case.

      Like with the looming end of TM, losing JM+TI would be a port killer; too much of our advantage is tied up in our JIT. But JM+TI, as hard as it was to get off the ground, was much simpler to write for and understand than Ion. The Ion backend code is so much larger and complex, and just as poorly documented (I'm considering tossing out the ARM-based version I have and going with x86 because of all of ARM's freaky addressing modes and bit shift features that make it clever but hard to understand). There is still no other port for Ion other than the extant ARM and x86 ones internally written by Mozilla, and I'm beginning to understand why.

      I have to think about how feasible (and worthwhile) Ion is, especially since 10.9 is presumably around the corner and the usual suspects in Mozilla will start sharpening their knives to remove 10.6 support. That could be a port killer too. I just want to get to 24 any way we can, even if I have to transplant an older JS engine in and cross our fingers.

      Delete

Due to an increased frequency of spam, comments are now subject to moderation.