Distributing Builds

B2G OS Tablet Contributor Program
#1

For those who have received a tablet, you may have noticed that it shipped with a prerelease version of 1.4 from January.  I’ve spoken with Asa and it sounds like we should be testing 2.0 rather than 1.4.
For those unfamiliar, as I understand, 1.4 will be aimed more at stability while 2.0 will be more featureful and a greater change in user experience - implementing all of the Haida project .

Our partner (the tablet manufacturer) will apparently be providing regular builds at some point in the future, but in the mean time we are ok to privately share builds to flash the devices.  We have build instructions, but not everyone desires to build the code.

I’m told that because the builds contain some proprietary blobs, licensing prevents us from distributing them publically, like simply posting a link. (The partner can post a link, but we can’t.)  So I’m starting this thread to talk about how we might go about private distribution.

I will add my idea below this first post.

It would be nice (I think) to have some solution going in a day or two.  Remember, we can try one or more solutions to see what works if we need to.

I will also look into getting some straight-forward instructions for just flashing the device with the build (ROM).

P.S. If you are having issues with flashing, please start a new thread for such a discussion.  Don’t want to get off track.

4 Likes
#2

My idea is to use Bittorrent Sync.  
With it, you create a folder and Bittorrent Sync gives you a code (they call it a “secret”) for that folder.  Anyone who has that code will then download the files in that folder.  There are read-only codes and read/write codes, so we can hand out the read-only code via private messages on IRC (and email perhaps) and only those who are submitting builds will use the read/write codes.
The builds look to be ~100MB so perhaps we should only keep the last 2 or 3 builds in it.  I don’t know a whole lot about flashing and such, but perhaps have a policy that all builds should be verified on a device before being posted?

One nice thing about this is it’s peer-to-peer which means that we don’t have to find a central repository and the bittorrent part of it handles large files nicely.  It does mean at least one person needs to be online for another to download them, but I imagine this wouldn’t be a problem.

It’s a free solution, but it’s also been pointed out that Bittorrent Sync is propreitary. Granted, so are some of the bits that the tablet is running.  If someone is fully opposed to using it we can find a workaround for them.

If data bandwidth is an issue for someone, they can shut down the program when they don’t need a build and it will not upload/download. If bandwidth is not an issue, folks can keep it open to allow others to download the files.
We might also consider having two folders available, one that has just most recent build and one that has a few more.  People can choose to only sync one of them if they like.

This is an entirely new and unfamiliar topic to me, so I don’t know if I’ve covered all the bases, but what do you guys think?

#3

If this is going to be a regular thing, perhaps we need a more formal mechanism for it? Can we build a Persona-login-powered download server, and allow people to get builds based on the mozillians.org groups they are in?

#4

My impression is that the propritary binary stuff is in boot.img which doesn’t change that often. If that is the case would it be possible to get the manufacturer to build and publish a 2.0 version which we can reference?

This makes the flashing process more complex though as need to collect several components from different sources. As 2.0 is trunk it also seems more likely that boot.img will be high churn.

#5

IMHO, the focus should be on having a prebuilt binary and a certain mechanism so as to update the firmware as soon as its ready. Having an easy installation process, like a browser update, is what will help having most people running the same piece of code.

Also, I too would prefer testing v2, because this is where the primary target is, at least for when the tablets will be publicly available.

#6

For the Flame phone, Mozilla is setting up a system to update just Gecko and Gaia and leave the base system alone. If that works well (release engineering is using some new processes there), it might be something we could adopt for the tablet program as well - but we need to wait for them getting experience with the Flame stuff first.

With all those self-built builds (and even the preinstalled ones), we also have the problem that crash reporting doesn’t give us really helpful information because we do not have “symbols”, i.e. the bits that tell us which addresses in compiled libraries correspond to what source code - with Gecko builds done on the Mozilla side, we could have those and get meaningful crash reports.

That said, those of us who actually do Gecko development for the tablet, those need to compile themselves anyhow. :wink:

#7

Unfortunately right now unvouched mozillians cannot join groups and we have many of them participating in TCP. Check bug 999112.

#8

Is it possible to write down how many different builds we need? (engineering builds, for testers, for localizers etc)

Maybe we can check how many builds mozilla needs for phones. This will help us to understand how many resources we will need.

Right now I have in my mind two different builds, one for engineers and one for production.

#9

Well, unless any build that gets distributed to a larger amount of people has its symbols submitted to our servers as well, the build is useless for crash reporting stuff, unfortunately. That’s why I personally would prefer if we’d get Mozilla RelEng to build and update Gecko/Gaia in the mid-term, just as is planned for the Flame.

#10

One thing I didn’t fully appreciated until after posting this (but rather dovetails) is that the entry barrier is currently too high for many users wanting to flash their (flatfish) devices.  
We have a set of instructions for building and flashing, but many users - translators for example - are not expecting (or desiring) that amount of effort & time, plus the more technical nature of it.

Perhaps it’s a given and doesn’t need said, but this should be taken into consideration when crafting distribution solutions.

I realized after looking over the build instructions some, that flashing the device was not going to be as straight forward as downloading a tool and typing a few commands.  In the future it would be great if it were very easy, but even in the short term it would be good if this could be somewhat remedied.

#11

I couldn’t try with a tablet yet, but I have multiple FxOS devices, and even a self-compiled build on one of them. We definitely should try to get a simple way for the non-developers among us to get a new build up and get updates of some sort. And I personally hope we’ll be able to get Mozilla Release Engineering to help there, but as mentioned, that will need patience as it would need to build upon their work for the Flame.

#12

I seem to recally a build option to turn on OTA updates. Could we not make
them available for easy updates? Perhasp with/without symbols?

Steve Lee
OpenDirective http://opendirective.com

#13

We probably could make them available easily enough, Mozilla Release Engineering is trying that with the Flame first right now and when it works out, we might be able to for flatfish as well, it all depends on if RelEng is able/willing to do work for that.

The symbols side is completely between build machines and servers, they just need to exactly match the builds created and therefore come from the build machines and go to our servers. The symbols aren’t present on the device itself. :slight_smile:

1 Like
#14

Is there a bug for that?

#15

I received a reply from Joe Cheng which in part said:

We did talk to our partner last week and it is likely that they are able to host a full flashable image on their github so it will include gonk/gecko/gaia for everyone to download 
I am pinging our partner again to see where things are

Before we have anything from our partner, It seems like we should do a one off thing to host a latest gecko/gaia somewhere publicly so we can get most “not too technical” contributors to get the latest build. We should be able to do this quicker so let me follow up internally

So that sounds positive. :slight_smile:

2 Likes
#16

I’m pretty sure there is no bug for that yet, feel free to file one.

#17

As a localizer my first attempt was to change the language, but Dutch (or Frisian) isn’t available on the tablet, so I’d like to flash my tablet to 2.0 asap. Although I can read myself through the manuals for flashing and probably make it work, I’d rather have the simple system being used for the Geekphone which also has solutions to be used on Windows-systems; the manuals are mainly Linux-only. If we can work with the partner towards this solution that would be very nice.