On Friday, January 25, 2013 at 10:05, Loïc Antoine-Gombeaud wrote:
That's really interesting, thank you for your answer. I'm going to digress
here, but you've made me even more curious: is it common for open-source
projects to implement features that benefit one user / group of users'
requirements, but not necessarily all of them? How is that decision made:
is it a conscious, group-approved decision, or does it just "happen"?
That's a very general question. Open Source software can be anything whose
source anyone has opened to the world.
Sometimes it's Wordpress, sometimes it's a bash script to bootstrap my
Unix user. The former is built thinking about all the users, the latter is
built for myself. The reason why I might open my own scripts is that other
people might benefit from what I did in some way -- learning, applying
similar design decisions, etc. Many people think of FOSS (Free and Open
Source Software) as something that someone created to "scratch their own
itch", and many projects do start like that.
You have all sorts of shades in between those two extremes. 
I'm at the very beginning of my career and have never dabbled in
open-source before, I must say I'm quite impressed by what a community of
people scattered around the world can achieve, even knowing that there is
often a core of developers based in the same physical place.
It is certainly incredible, specially when those projects are not directly
(or even indirectly) backed by a company. I'd suggest you read more about
the history and current state of the Linux kernel and the Debian project.
While reading about Debian, do search for their Social Contract and other
guiding documentation.
What would be a good reference for getting to know those work mechanisms
better?
Mailing lists, blogs, IRC, user groups, github, DuckDuckGo
Look for local user groups on topics of interest and make contributions to
the communities. Github is your friend. That'll send you a long way.
And, of course, pub talks with fellow geeks!
On Thu, Jan 24, 2013 at 5:09 PM, Daniel DeLeo dan@kallistec.com wrote:
On Thursday, January 24, 2013 at 6:42 AM, Loïc Antoine-Gombeaud wrote:
Hi chefs,
can somebody explain the rationale behind deployment callbacks, also
called deployment hooks [1]? More precisely, I understand their purpose
quite well (and use them myself), however I don't understand why they
should be stored in the application code base instead of inside the
cookbooks.
According to Scalarium documentation [2], it is an inherited Capistrano
behaviour, but that doesn't answer the question of location AFAICT.
The reasons I'm asking are the following:
- it's a pain to maintain deployment code in two distinct repositories, and
- I'm just curious
The deploy resource is a port of an earlier project that provided
Capistrano-style deployment for Chef, developed and used at Engine Yard,
and the intention was to provide compatibility with that implementation.
You can imagine that in an Engine Yard type scenario, you may be able to
fill in all the parameters to the deploy resource from information you have
in a database or with sane defaults for your environment, while allowing
some custom functionality via hooks that live in the code repo.
If you don't want to keep the callback code separate, you can just give
blocks of Chef code to the callbacks instead of looking up the files.
Any pointers?
Cheers,
Loïc
[1]
http://wiki.opscode.com/display/chef/Deploy+Resource#DeployResource-InteractingwithYourInfrastructureDuringDeployment
[2]
http://support.scalarium.com/kb/deployment/how-can-i-use-deployment-callbacks
--
Daniel DeLeo
--
Loic ANTOINE-GOMBEAUD
IT contact & DevOps Engineer
Plinga GmbH | Saarbrücker Straße 20/21 | 10405 Berlin | Germany
E-Mail: loic.gombeaud@plinga.com | skype: loic.plinga
Cell: +49 (0) 160 922 86573
www.plinga.com
Geschäftsführer: Johannes Kreibohm, Florian Schmidt-Amelung
Eingetragen beim Amtsgericht Charlottenburg, HRB 119994
