hi,
There still seems to be some level of ambiguity as to how we are doing the change requests, rebuild requests and change requests so I wanted to get a short summary on the list and we can pickup details where needed.
For anything that anyone sees that needs a change : file an issue report at bugs.centos.org; this is most important. Then see if you can also propose a patch.
In order to propose a patch you need to run through a few steps( in this example assuming we want to patch httpd ):
$ git clone https://git.centos.org/git/centos-git-common.git $ git clone https://git.centos.org/git/rpms/httpd.git $ cd httpd $ git branch -a $ git checkout c7 $ bash ../centos-git-common/get_sources.sh $ git rev-parse HEAD > `whoami`.start-point $ bash ../centos-git-common/rpm-tree-prep.sh
At this point you should be good to make changes to SPECS/ SOURCES/ and BUILD/package-name ( note that the rpm-tree-prep.sh script will setup a __orig dir for you to build patches against.
once you have the content ready, git commit the changes, in multiple commits, to have a complete, but as small as possible, change in one commit. Eg. if you are fixing 5 things, ideally end up with 5 commits. Also, if you are adding content, to replace something else that is going away, make sure you have the delete and addition in the same commit. Eg. replacing xulrunner-redhat-prefs.js with xulrunner-centos-prefs.js - add the git rm and git add into the same commit.
Once you are happy with the state of play, go back to the root of the git repo, and :
$ git format-patch $(cat `whoami`.start-point)
this will leave behind files, one per commit that you made, in the format : NNNN-<commit summary>.patch : these are the files you need to attach to bugs.centos.org; these files contain your user metadata as well, and can then be applied as is. So you get credit for the changes, and we are able to replay exactly the change you had in mind.
NOTES:
CentOS patches added to the SPEC file should be named : <packagename>-CentOS-<change being made>.patch
When added to the spec file, its a good practise to skip a few hundred spots on the patch list. Eg. if the spec has no patches, then start the CentOS patches at Patch1000 onward. If the spec already has patches, then skip a large number. This is just so we dont have ( or are less likely to have ) Patch number conflict with upstream changes in the life of CentOS-7
lets get patching, todays build is definitely on.