[EVO 4G Android Development] dj_L:
Actually, he stated (after your post) that there are build time requirements that need to be satisfied.

Ouch. I apologize for my tone. And yes, I should, and would contribute if I had the time required. In fact, I have tried to get involved, but my time is severely limited (two nights per week to devote to Android, BLFS, and OpenJDK/IcedTea). I have been unable to get in touch with toast on IRC during my few available hours (all before Shinzul came into the mix, whereby any contributions I'd have been able to make (if any) would be rendered virtually useless as Shinzul has proven to be very good at this). Anyway, I didn't see my comments as insulting when I wrote above, and I now see that they could be taken as such. Although I lacked tact, the intention of my comment is not withdrawn. I'll try a little harder to explain in more useful terms. Please do take the time to try and see it from a developer's POV.

Example 1: The necessary work is believed to be completed, a ROM is produced and put up for download. Now I'm using the SWAG method here, but lets say that 700 people download the ROM on day 1 (there may be a much larger or smaller demand, I honestly have no idea). Again, choosing arbitrary numbers here, lets say that 10% of users are affected by a bug with some combination of add-on software. Developers receive 70 messages stating that the connection was working and then it dropped when I opened an email message. The developers (currently only Toastchf and Shinzul) have to pick through the 70 messages, and dig to get the information that they need. Information that, taking the 5% I mentioned earlier, they already have in 3 of the 70 messages received. The needed information is there already, it is just more difficult to access it, and then they have the problem of confirming that the other 67 cases are, in fact, the same bug. Bug is fixed and you have 700 more downloads at ~90MB each.

Situation 2: Taking my guestimated 5%, 35 people build the new ROM, and there are 3 or 4 bug reports to deal with. Those 3 or 4 reports contain very useful information such as "The connection dropped when I opened an email message in K9 mail. I reviewed the logs and found that sequansd had segfaulted. I verified that sequansd is not running. I then removed K9, restated the device and opened my mail with the stock mail client. All is well as long a K9 isn't running. Attached are the relevant portions of the logcat output." Bug is identified and fixed. Cycle starts over.

Compare the overhead of the hypothetical bug in Example 1 vs 2. In example 1, 14GB of data is transferred, the developers (currently 2 strong) have to sort through 67 nearly useless bug reports to find the 3 good ones (which takes time that could be used for development). In example 2, 3 bug reports came in, all confirming that the problem was isolated to K9 doing something in a different way, but still acceptable for the platform, that caused an urealized bug to be found very quickly, and squashed. To top it off, the data over head was around 70MB, absorbed by github, as compared to 14GB absorbed by privately held or rented data services.

BTW, I should mention that a bug that affects 10% of users is very unlikely, especially with an email app. I only used that as a very simple example, and I believe that K9 is a very good product and is unlikely to cause any issues.

As far as this goes, why not distribute to a few individuals who will seed via P2P. Put up only the torrent on the website. This totally decentralizes the bandwidth constriction. Let it ride there for 3 or 4 days to absorb the initial shock, and then put up a working build on the website? We have done that successfully in the past with the LiveCD where I normally focus my development time.