How Do You Manage a Product Based on Linux?

Ryan writes "Following my advice, my company has decided to base it's new appliance on Linux. So far, it's worked out great. Linux gave us a huge jumpstart on development because of it's open nature and the information we've garnered from public mailing lists. We've added software, modified startup files, and have built our own kernel. Now the question is: How do you manage it all? Do you put it all in CVS or Subversion? Do you use the distro's packaging system (we're using Debian)? What does your build system look like?"

Comments

If this is really the question

[Anonymous MadCoe]

You really should be stopping and look at what you are doing. How you want to manage it should be part of the strategy, and actually should have been part of deciding to use Linux (not in detail, but strategically).

So my advice, hold on, sit down and look at what you expect to produce and what you would need to get there. From there you can find out what you would need.

You will probably run into some issues, but that's just what happens, there is no ideal situation.

I don't understand the question

[Anonymous Coward]

You're building a whole new appliance, but your software engineers don't know how to manage a development process?

I mean... I'm not being nasty here, but you're in trouble, and I don't even know where anybody could start to give you advice. It would be one thing if you were looking for guidance on a regular small scale software project, but if you're jumping in feet first with a whole new large scale application and no idea how to guide the process...

Absolutely

[Anonymous Coward]

You should definitely put your code under some kind of revision control. We currently use cvs but are looking at switching to git or mercurial. One thing thats nice about cvs is the import feature that lets you bring in new copies of the open source programs you've modified and migrate your changes forward into the new copy. With regards to the packaging, its definitely worth the effort to put them into the distro's packaging system. We use debian as well and its nice to be able to have a repository that customers can just apt-get from to get the lastest for their appliance. We also have debian source packages to make it easy for the customers to get access to the source in a way thats easy for them to make changes and create new debian packages.

Version Control

[bigattichouse]

Your build should be in some sort of Versioning system (CVS, whatever). SOMETHING that allows you to cover your butt with you `rm` that folder and realize you just tanked the whole thing. Somehow you should be able to rebuild any version of your project back to day 1.

Re:Version Control

[RAMMS EIN]

And you should know who introduced a certain change, and how they motivated that.

Re:depends on the scope of the project

[LiENUS]

Actually even with 1 developer SVN or CVS are huge benefits, what if that developer introduces a bug? with subversion you can go through and look to see when that bug was introduced and roll it back. You'd be hard pressed to roll it back with just tarballs.

Development, or Distribution?

[KillerBob]

For distribution to the end-user, you will definitely want a package of some kind. I'm assuming that your end users won't be able to log in with a prompt, but may have some kind of web-based management, right? If you distribute your upgrades/patches as .deb packages (maybe renamed to .bin since that's what users have been conditionned to expect), then it makes things a whole lot easier... among other things, it would facilitate downloading the upgrade from a location other than where the product is: not all users have Internet connections at home, even in this day and age. You may also want to look into implementing something like Slackpackages, since they ignore dependancy. (They're basically just a tarball... you can install them manually by unzipping/tarring the file from / and then looking in the /install directory and manually executing any scripts there)

For actual development... you're gonna *need* to use SubVersion or CVS. Cover your ass. Also, not having it makes managing a project a royal pain in the ass.

Re:depends on the scope of the project

[krumms]

No no no no no. :)

Whether you're working in a team or working by yourself: Use Subversion Anyway. Or svk. Or Darcs. Any reputable revision control system will kick the pants out of any ad-hoc solution you come up with. Revision control should be automatic and easy. The value of being able to easily merge changesets alone is reason enough for any non-trivial project. Keeping track of branches for experimental/delicate changes, tagging releases, LOG MESSAGES for all your changes - all of these things, use them, learn to love them. It's a bitch to get in the habit, but when you do it's absolutely worth it.

It's taken me over seven years to truly learn the worth of version control. These days I'd dare not live without it. It really is that good. Honest!

Re:depends on the scope of the project

[idontgno]

What you're really saying, is "use version control discipline", hypothetically independent of the tool. That's the real point, one I've seen made elsewhere in this topic. The submitter is asking for tools, but really I think he's asking for process advice.

The tool won't make you do the smart things you talk about--tagging, change tracking, etc. Every tool can be circumvented, pencil-whipped, or otherwise reduced to "going through the motions".

The real advice here: come up with your project management goals and philosophy, then decide on methods and select tools to support those goals and philosophy.

That said, I've used and liked subversion myself. But the temptation to bypass the onerous parts of the process is always there. We developers are a lazy bunch, aren't we?

Re:Now that's Insightful

[torpor]

What part of "How do You Manage a Product Based on Linux?" do you not understand?

He's not asking for help .. he's interested in the ways /.'ers are maintaining their linux-based products, perhaps (naively) hoping that the peanut gallery might provide an interesting result. This does not necessarily mean he wants help with his lame system; read closely, and you might realize that Ryan seems quite happy with his approach so far .. but this is still an interesting topic worth objective attention. Its not a screaming/crying/spoiled-brat cry for help that some of the similarly inclined responses have implied, anyway ..

Me, I've been building linux-based systems for my own use since the days of the minix-list (and before that, RISCOS distimages). My current approach is quite simple, old-fashioned, but workable nevertheless. I simply apply the following general guide-lines for sysbuilding: complete source-control (using SVN/whatever-the-package-maintainer-uses), avoid cross-compiling, build everything on-board, one Makefile to tie together whatever components are required (linux-kernel/base-image/sysbins/libs/my_app), 'cscope -R' at the root tree when something needs to be worked out, and set it all up so that you can just type 'make' and watch the bootable .img form .. Fortunately the more you do this, the less you need to worry about package maintenance, but of course if the 'final deliverable' is a simple, plain sysimage containing all software onboard required for your embedded app, then package maintenance isn't such an issue. Its kind of fun to have a "single-image deliverable" too ..