On 16 Sep 2015, at 01:37, Alan Pevec <apevec(a)gmail.com&gt; wrote: Subject: RDO Liberty and Fedora - details for openstack-* maintainers As a followup, here are few notes for the package maintainers, until rdo-packaging documentation is updated with this workflow. distgit will be rdo-liberty branch on gerrithub/openstack-packages, create it from Fedora master and squash merge rpm-master: git remote add -f gerrit ssh://review.gerrithub.io:29418/openstack-packages/$PROJECT # skip if already present git-review -s git remote add -f fedora git://pkgs.fedoraproject.org/openstack-$PROJECT.git # skip if already present git branch rdo-liberty fedora/master git checkout rdo-liberty git merge --squash gerrit/rpm-master git reset HEAD .gitignore sources .gitreview git checkout .gitignore sources Resolve conflicts in .spec file Set correct Liberty Version: for your project Release: field should be pre-release 0.N until GA e.g. openstack-keystone.spec %global release_name liberty %global pypi_name keystone %global milestone .0b3 %{!?upstream_version: %global upstream_version %{version}%{?milestone}} Name: openstack-keystone Epoch: 1 Version: 8.0.0 Release: 0.3%{?milestone}%{?dist} Get the source tarball for the current milestone e.g. milestone 3: Source0: http://launchpad.net/%{pypi_name}/%{release_name}/%{release_name}-3/+down... If Source0: is like above, rdopkg new-version --bump-only $UPSTREAM_VERSION should work. Preserve Kilo patches if any: ideally, RDO packages are pure upstream and don't need any patches in RPM -patches branches are as before in github/redhat-openstack/$PROJECT but since there isn't Fedora:OpenStack 1:1 anymore, branch name for RDO Liberty RPM patches will be liberty-patches. You might want to archive old changelog entries in ChangeLog.old like done for Kilo GA http://pkgs.fedoraproject.org/cgit/openstack-nova.git/commit/ChangeLog.ol... When done: git commit -m "Update to Liberty" git push -u gerrit rdo-liberty:rdo-liberty For packages already in Fedora, build Liberty versions in Rawhide and ping apevec or number80 on Freenode #rdo for CloudSIG EL7 build. If you get stuck, please ping us on IRC and/or reply to this thread!

On 16 Sep 2015, at 18:28, Alan Pevec <apevec(a)gmail.com&gt; wrote: >> For packages already in Fedora, build Liberty versions in Rawhide ... > I am stuck on building Fedora Rawhide package. When I do fedpkg build, I get: > > -bash-4.2$ fedpkg build > Could not execute build: Unknown build target: rdo-liberty-candidate > > I presume it expects I do it from Fedora distgit. Yeah, I forgot to mention, for packages already in Fedora you need to merge to Fedora master and push before building in Rawhide: git checkout master git merge rdo-liberty #should be clean fast-forward if following steps > Also, not clear what I should build in case of openstack-neutron-*aas repos that are not in Fedora, yet and probably won’t be there at all now that we move distgit out of Fedora infra. Create and push rdo-liberty branches for them on gerrithub, we'll do CBS builds from there.

On 16 Sep 2015, at 18:32, Alan Pevec <apevec(a)gmail.com&gt; wrote: >> Create and push rdo-liberty branches for them on gerrithub, we'll do >> CBS builds from there. > > How can I validate that it actually works before you trigger the build? As a quicktest fedpkg --dist el7 local should work. I'll look at preparing mockbuild against CBS repos for more realistic test build. Cheers, Alan

On 16 Sep 2015, at 01:37, Alan Pevec <apevec(a)gmail.com&gt; wrote: Subject: RDO Liberty and Fedora - details for openstack-* maintainers As a followup, here are few notes for the package maintainers, until rdo-packaging documentation is updated with this workflow. distgit will be rdo-liberty branch on gerrithub/openstack-packages, create it from Fedora master and squash merge rpm-master: git remote add -f gerrit ssh://review.gerrithub.io:29418/openstack-packages/$PROJECT # skip if already present git-review -s git remote add -f fedora git://pkgs.fedoraproject.org/openstack-$PROJECT.git # skip if already present git branch rdo-liberty fedora/master git checkout rdo-liberty git merge --squash gerrit/rpm-master git reset HEAD .gitignore sources .gitreview git checkout .gitignore sources Resolve conflicts in .spec file Set correct Liberty Version: for your project Release: field should be pre-release 0.N until GA e.g. openstack-keystone.spec %global release_name liberty %global pypi_name keystone %global milestone .0b3 %{!?upstream_version: %global upstream_version %{version}%{?milestone}} Name: openstack-keystone Epoch: 1 Version: 8.0.0 Release: 0.3%{?milestone}%{?dist} Get the source tarball for the current milestone e.g. milestone 3: Source0: http://launchpad.net/%{pypi_name}/%{release_name}/%{release_name}-3/+down... If Source0: is like above, rdopkg new-version --bump-only $UPSTREAM_VERSION should work. Preserve Kilo patches if any: ideally, RDO packages are pure upstream and don't need any patches in RPM -patches branches are as before in github/redhat-openstack/$PROJECT but since there isn't Fedora:OpenStack 1:1 anymore, branch name for RDO Liberty RPM patches will be liberty-patches. You might want to archive old changelog entries in ChangeLog.old like done for Kilo GA http://pkgs.fedoraproject.org/cgit/openstack-nova.git/commit/ChangeLog.ol... When done: git commit -m "Update to Liberty" git push -u gerrit rdo-liberty:rdo-liberty For packages already in Fedora, build Liberty versions in Rawhide and ping apevec or number80 on Freenode #rdo for CloudSIG EL7 build. If you get stuck, please ping us on IRC and/or reply to this thread! Cheers, Alan

On 16 Sep 2015, at 18:30, Alan Pevec <apevec(a)gmail.com&gt; wrote: > First, thanks for the detailed plan, I think I got thru it, mostly. Cool, thanks! > One thing I want to note is that with the high number of packages I maintain, and usual lack of time to go thru rebasing it for each milestone, I would be very glad to see maintainers offloaded of the duty to apply those manual steps, since they all can be automated, assuming that there are no differences in Fedora distgit comparing to delorean. Adding Jakub-the-automation-master: we could definitely script most of this, only manual step is resolving conflicts which I'm not sure how to automate.