Starting an OSS project
-
tl;dr: I want to start an OSS project and not suck at it, what's the best approach?
Long story:
The home router I use has been long abandoned by the manufacturer - oddly the firmware it runs is open source under BSD/MIT license.I've successfully updated all of the packages on it (it runs linux) and set it up to pull and install its own auto-updates on schedule by default. I'd like to find the least expensive way possible (hopefully free as in beer) to publish it on GitHub with CI running against it so that it does daily builds.
This is my first foray into being the point man on this kind of thing and I'd like to do it "right"
-
@rad131304 said in Starting an OSS project:
I'd like to find the least expensive way possible (hopefully free as in beer) to publish it on GitHub with CI running against it so that it does daily builds.
You want Travis CI. It's quick and easy to set up and it'll build on every push.
-
@Yamikuronue do you know of free hosting for it? I'm transitioning my VM farm at home, and I'd like to keep this off of that if there's a reasonable way to do it.
-
@rad131304 Travis is cloud-hosted
Basically you:
- Set up a github repo
- Connect your github account to Travis (you just log in using Github's SSO)
- Turn on the repo you're interested in
- Commit a config file for Travis telling it how to build
Voila, continuous integration.
-
@Yamikuronue OH! That's great. I didn't know that! :dances:
-
Well, being open source Github repo hosting + Travis CI is free.
Look at https://docs.travis-ci.com/user/getting-started/ for some details.
I think daily builds are not directly supported, normal is to build at each (branch) commit. Seems to be some third parties helping with that, some examples at SO link
-
@cabrito I'm fine with build on every push; I just wanted CI.
-
@cabrito said in Starting an OSS project:
I think daily builds are not directly supported
You don't need daily builds if you're able to use build-on-commit, which is usually true unless you're building C++ (which has insane build times even on modern hardware). Well, least not unless you're dealing with particularly nasty integration testing and stuff like that. Not things I'd wish on anyone's first project. :)
Also try to avoid doing full release packaging in the build-on-commit. That can add a lot of time and you don't normally need it unless the code that's going to be deployed by ordinary end users and you're testing the release packaging itself. Most bugs will be elsewhere.
-
@dkf said in Starting an OSS project:
try to avoid doing full release packaging in the build-on-commit.
You can get nice and complex if you want in your build scripts so it only does a full release build on the (protected using Github settings) master branch, and then do your development in another branch and merge it all in when you're ready to release.
-
@Yamikuronue said in Starting an OSS project:
You can get nice and complex if you want in your build scripts so it only does a full release build on the (protected using Github settings) master branch, and then do your development in another branch and merge it all in when you're ready to release.
Yeah, but I'd tend to keep trunk as “main shared area for development” and cut releases from a specific branch for that purpose. The other way only really works well if the number of new features and bug fixes in a release is fairly small. It might be in some cases (such as when the product is really a service with a short release cycle) but it's not usually so with the things I working. When downstream consumers have a lot of bureaucracy (e.g., defence industry) fewer releases is something that the users actually prefer.
-
@dkf said in Starting an OSS project:
I'd tend to keep trunk as “main shared area for development”
That's fair. Sock Drawer tends to have an integration branch for development and cut releases from master, instead.
-
@Yamikuronue said in Starting an OSS project:
That's fair. Sock Drawer tends to have an integration branch for development and cut releases from master, instead.
that was the model from sockbot2.0
we've swapped the model to one much like @dkf describes for sockbot3.0 as that model is more in line with other OSS projects and so using it lowers the barrier to entry for Pull Requests from non sock drawer developers
-
@accalia huh. Okay. You'll have to show me, sockmafia's not made the switch at all
-
@Yamikuronue said in Starting an OSS project:
You'll have to show me
10-4 i'll do a writeup later today for you.
i'm working on the mafia setup document right now.... :-D
-
So... the only thing you need to do to start an OSS project is set up a CI server?
Or is the title of this thread way-off from what the actual question asked was?
-
@blakeyrat said in Starting an OSS project:
the only thing you need to do to start an OSS project is set up a CI server?
Well, I think the conversation was more about setting one up, and the title was less than perfect.
-
@rad131304 said in Starting an OSS project:
I want to start an OSS project and not suck at it, what's the best approach?
Since you're not starting entirely de novo, the main thing you've not really mentioned is getting an issue management service (bug database) going. Yes, there's a system in Github, but it's really quite sucky for anything more complicated than handling PRs. If you manage to make the jump to having several developers working on it, you'll want to look into getting something better going. IIRC, Jira is free for open source projects, and while it is quite fussy, it's actually quite competent (and with a hosted version, you don't need to worry about actually running it). Also, you'll need to spend time thinking about how you distribute builds: I've used both Launchpad and Sourceforge for that in the past and they were OK I guess, but neither really thrilled me to bits.
Longer term, there's the general issues of relying on services where you don't have a contract in place over them; others' goodwill is nice, but definitely exhaustable. But if you keep backups (which is trivial for git, but more complex for other services) then if something goes south then you're not hosed.
-