Slightly Updated: Steps for updating p5subset.xml in Stylesheets repo
This is an outline of the process we designed for updating the local copy of p5subset.xml in the Stylesheets. The rationale for this process is that changes to P5 inevitably require changes to the Stylesheets, but it makes more sense to deal with those required changes in batches, periodically, rather than making every change to P5 trigger frantic work on the Stylesheets (which the P5 ticket implementer may not be able to undertake at the time). The Stylesheets Group should probably undertake this work, and it must happen in a timely manner before any release. This is how it goes: 1. Retrieve a fresh copy of p5subset.xml, built using the current dev branch of P5. 2. In the Stylesheets, switch to the dev branch and git pull. Switch to the subsetSetup branch, which is intended for this work, and git pull. 3. Merge any changes from the Stylesheets dev branch into the subsetSetup branch. 4. Replace the source/p5subset.xml in the subsetSetup branch with the fresh one. 5. Run the Stylesheets tests (Test and Test2) in the subsetSetup branch. 6. Fix any problems. At this point, if there are problems too difficult to fix in the time you have available, abandon the process and put in a ticket for the Stylesheets repo. If the error is serious, make it a release-blocking bug. 7. Commit changes to subsetSetup branch. git push. 8. Switch back to the dev branch, git pull, and merge changes from the subsetSetup branch. git push. 9. Watch Mr Jenkins to make sure all is well. -- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes@uvic.ca
One final note: Peter suggests (and I think I agree with him) that rather than using the same subsetSetup branch every time, we actually create a brand-new branch, which then gets deleted at the end. The advantage there would be that you wouldn't end up with multiple variant versions of the same branch scattered across people's computers from attempts which failed at step 6 (as today's did). If there's a consensus for that, I'll update these instructions accordingly. It was also pointed out that if you make a copy of the expected-results, then run the tests with REGENERATE=1, you can do all the resulting diff checks in one operation, rather than doing them one by one and having to re-run the entire build process each time. Is that what we should recommend? Cheers, Martin On 2020-08-11 7:39 a.m., Martin Holmes wrote:
This is an outline of the process we designed for updating the local copy of p5subset.xml in the Stylesheets.
The rationale for this process is that changes to P5 inevitably require changes to the Stylesheets, but it makes more sense to deal with those required changes in batches, periodically, rather than making every change to P5 trigger frantic work on the Stylesheets (which the P5 ticket implementer may not be able to undertake at the time). The Stylesheets Group should probably undertake this work, and it must happen in a timely manner before any release.
This is how it goes:
1. Retrieve a fresh copy of p5subset.xml, built using the current dev branch of P5.
2. In the Stylesheets, switch to the dev branch and git pull. Switch to the subsetSetup branch, which is intended for this work, and git pull.
3. Merge any changes from the Stylesheets dev branch into the subsetSetup branch.
4. Replace the source/p5subset.xml in the subsetSetup branch with the fresh one.
5. Run the Stylesheets tests (Test and Test2) in the subsetSetup branch.
6. Fix any problems.
At this point, if there are problems too difficult to fix in the time you have available, abandon the process and put in a ticket for the Stylesheets repo. If the error is serious, make it a release-blocking bug.
7. Commit changes to subsetSetup branch. git push.
8. Switch back to the dev branch, git pull, and merge changes from the subsetSetup branch. git push.
9. Watch Mr Jenkins to make sure all is well.
-- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes@uvic.ca
Maybe, but it gets complicated. Per my previous post, the new results are not actually put into expected_results/. So my suggestion would be to hold off on that change to the instructions for now, and we’ll figure it out later. ________________________________ It was also pointed out that if you make a copy of the expected-results, then run the tests with REGENERATE=1, you can do all the resulting diff checks in one operation, rather than doing them one by one and having to re-run the entire build process each time. Is that what we should recommend?
participants (2)
-
Bauman, Syd -
Martin Holmes