----- "Toshio Kuratomi" <a.badger(a)gmail.com> wrote:
John Palmieri wrote:
> ----- "Toshio Kuratomi" <a.badger(a)gmail.com> wrote:
> A note on the code drop, by requiring the author to modify a spec
file if needed in order to deploy their changes into their environment
(revision numbers would be automated) patches would include spec file
changes instead of the maintainer having to sync by hand. This would
also make sure the build files are kept up to date as the author would
have to make their changes work in an RPM environment just to test
them as opposed to just installing from their source tree which often
leads to annoying bugs (like missing files in a distributed tarball).
Also by making it easy to generate a patch and submit it to trac we
will get more consistent formatted patches (such as using the VCS's
patch format) and most likely more people getting involved as the
overhead shrinks a bit (how many people want to go to individual trac
instances to file a patch?).
I'm not sure that this is a logical outcome of having an
infrastructure-apps image. It seems more like guidelines that would
need to be established per-project. For instance, there is
nothing stopping someone from installing the packagedb from the rpm,
checking out the development source to their home directory, and then
changing the config file to run that instead.
I'm more talking about newcomers who don't have a process of their own. If it is
all setup with scripts and tutorials right off the livecd (could be a locally running url)
submitting well formatted patches by new developers becomes trivial. The key is to make
it easy to find the documentation and make the process somewhat easier, or at least more
convenient then having to figure out the steps to get the code, change the configs and
then restart the servers. I don't want to put process ahead of getting code
contributions, it would just be a more integrated workflow where a developer wouldn't
have to learn each step separately (well except for the actual development and various vcs
workflows). Anyway just an idea. I plan on writing a script for pulling down each piece
of infrastructure code and another script for diffing, packaging and deploying the service
in the test instance. If others find it useful I will add other workflow scripts.
John (J5) Palmieri
Red Hat, Inc.