Ungoogled-chromium: Better system for binary downloads

[Eloston]

I'm trying to find a way to improve the downloads page so:

• Downlods are a little more organized and easier to find for end-users, and
• I can add other GitHub users to upload and maintain binaries so I don't slow down the whole process.

Does anyone have any ideas? I was thinking about creating a new repository with a gh-pages branch with tags that correspond to ungoogled-chromium tags. That way collaborators can upload binaries to a GitHub release associated with that tag and link them from gh-pages. They can also link to binaries stored on other servers (like a buildbot) if they so choose.

[ryneeverett]

You might set up CI to do the build matrix for you when a commit is tagged. For example, you could add encrypted github credentials to a .travis.yml and authorize only that build account to push to the separate gh-pages repo. Not only would that mean your whole build process is automated and isolated, but you wouldn't have to give co-maintainers the authority to upload binaries

[Eloston]

I don't like having to give my credentials. I described the reason somewhere in #37. Plus I'm concerned about the resources they provide for building, as described in that same issue.

Further CI discussion should probably go to #17.

[ryneeverett]

I don't like having to give my credentials.

I could have been more explicit -- my idea was to create a separate github user for this purpose. But good point, probably no free CI runner is going to be able to build chromium within the timeout period.

[9Morello]

@Eloston what do you think about setting up a GitHub webpage for ungoogled-chromium?

[Eloston]

@9Morello Do you mean GitHub Pages? If so, then I can setup a new repository just for a downloads website on this account. It seems I can transfer ownership of repositories at any time, so I can setup another GitHub user in the future if some CI service or buildbot needs access to a GitHub account.

[9Morello]

@Eloston Yes, thats what I meant.

[lenormf]

That way collaborators can upload binaries to a GitHub release associated with that tag and link them from gh-pages.

I don't know the details of this part of the plan, but I don't think third-party builds are going to have much success if anybody can submit their binaries. Are you going to appoint the people allowed to submit builds personally, and take responsability for them? Or declare that anybody can upload their builds and the users are responsible for anything that might happen to them? Please give more details of what you have in mind.

[9Morello]

@lenormf

He said collaborators in his post, so not everybody will upload binaries to said page. About the 'responsibility' part, the user is free to not trust the devs at all and build everything from source if they want to (buildlib does that by default). We will always provide hashes so the users can verify their packages.

[Eloston]

@lenormf What @9Morello said is correct. I will probably add the additional requirement that binaries must be signed so users can be sure it actually came from those I designate.

[lenormf]

@Eloston do you take responsibility for the binaries uploaded by contributors? Does being a contributor automatically grant you the right to upload builds or do you select them (making the contributor concept moot)?

[Eloston]

@lenormf I don't want to be responsible for binaries I don't build myself. Therefore, those who build binaries will be credited on the downloads page for their respective binaries. But I will still select people to have the ability to upload binaries for organizational sake. In the future, I hope to automate building so this won't be such a big problem, but I will still have someone or some people maintain the build systems.

In general, I don't want to take the responsibility of maintaining builds for ungoogled-chromium. I believe it is in the best interest of everyone if I stay responsible for the development of ungoogled-chromium; i.e. the entire source code. For now, I will follow a development model that's more like what Linux has (where I approve all changes made to the source code). Over time, as more developers work on ungoogled-chromium, I will start shifting responsibilities to those I feel trustworthy.

[lenormf]

Thanks, it's all clear now.

[alexbakker]

I think setting up some sort of build bot would be a good idea. It would spin up a beafy server every time a new release is ready, build all of the binaries, and destroy itself again.

The builds will be pretty expensive, however. I'm currently running a test on Digital Ocean to see how long a build takes on their $160/month server to determine the exact price. The servers could be paid for by crowd funding or by trying to get Digital Ocean to sponsor the project somehow :)

Edit: Actually, the build instructions appear to be incomplete. I'm missing a bunch of dependencies. I'll try again later.

[Eloston]

@Impyy I was thinking about using some build service like openSUSE Build Service or some CI system. I don't think paying for a service will be worth it right now.

@9Morello We should start planning out the new downloads page. I'm thinking about using the Releases feature to have a location to upload binaries to, and then we can modify the webpage to link to them (the master branch is where the webpage will live). I'm not sure how to design the page; should we write one from scratch using Markdown, HTML/CSS, or modify a template that GitHub can generate for us?

[alexbakker]

@Eloston I'd be very surprised if openSUSE provides the infrastructure required to build chromium in a reasonable amount of time for free.

Also, my test showed that the compilation on Digital Ocean took a little over 3 hours. That would be pretty expensive, around $0,70 per build.

[9Morello]

@Eloston Yeah, I was thinking the same thing.
I guess we could use something similar to Chromium's homepage (the one you get after an install). I'm not familiar with Github Pages, but I think its fine to just modify a template.

[Eloston]

@9Morello Cool. I'll make something simple, and we can revise it later on.

[Eloston]

An implementation is already in place.