On 09/27/2012 11:22 AM, Rob Stryker wrote:
I'm trying to solve the following bug [1] and it requires changes to a 
file in download.jboss.org folder. For my future knowledge, what are the 
policies for this process?
1. Ensure your change is backward compatible (no removal, no move...). If it's not, explain your need on the mailing-list.
2. Commit your change (Don't add binaries, but add scripts to get binaries instead)
3. Run job to get your change published https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevStudio_All/job/jbosstools-download.jboss.org-rsync-from-svn/
4. If you want to push binaries to this folder, ask the mailing-list for the most appropriate process.

Basically, I just want to make sure that I never do an rsynch when 
someone else has only half-complete or not-synchable stuff in there.
"Someone else" is only download.jboss.org. It should never be not-synchable. If it becomes not-synchable, then it's a bug, describe the issue in a Jira.
You don't do the rsync by yourself. You must use this Jenkins job to sync: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevStudio_All/job/jbosstools-download.jboss.org-rsync-from-svn/
So there is only a single user (jenkins) doing rsync on a single folder (download.jboss.org/jbosstools) and there should not be conflict.

Can it be assumed that any code in that folder and committed to trunk is free to be rsynch'd at any time?
Yes. But ensure your change won't break older stuff! Prefer adding files than modifying them.

HTH
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets