On 2009-07-10 08:47:58 -0500, Jon Nelson wrote:
I was hoping to get some advice about how to arrange things in a local build service.
Let's say we have a series of developers. Sometimes they work on stuff that's really only interesting to them, othertimes (more often) they are working on projects which will eventually make it into production.
Let's also say that you want to allow a two- or three- tiered environment, where individual developers will have their own projects, where there will be a shared development environment (like staging), and then production.
What I'd like to know is how people set things up so that developers can say something like "OK, production manager, package FOO version BAR is ready to go" and have that person (the production manager) place package FOO (version BAR) into the production environment. Ditto for all appropriate dependencies, etc...
Basically, how do you set things up so that there can be several internally consistent environments (projects), such that a person that manages the production environment get acquire packages without lots of hoop jumping.
At first blush, it seems that linking or aggregating would work, but it seems as though if the source package changes then it gets rebuilt everywhere it is linked. That is not desirable in this case. Obviously, one could just do something like a "copy" but is there a better way? Can links work with a specific (build service) version?
How are others cracking this particular nut?
http://en.opensuse.org/Build_Service/Collaboration thats how we handle it at suse. when ever a developer thinks the package is ready for the next stage, they do a submitreq to that project. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org