Request for test data based off of obfuscated live data

[John Palmieri]

----- "Toshio Kuratomi" <a.badger at gmail.com> wrote:

> John Palmieri wrote:
> > ----- "Toshio Kuratomi" <a.badger at 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
> absolutely
> 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.
> 
> -Toshio

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
Software Engineer
Red Hat, Inc.