@@ -94,7 +94,19 @@ You can try this when you notice that a package has been updated. You
94can also periodically try to lift bounds (I think it's good to do this
94can also periodically try to lift bounds (I think it's good to do this
95at the start of your week /@bergmark)
95at the start of your week /@bergmark)
97+If not all packages have been updated check if any of them are missing
98+from the original issue and if so add a new comment mentioning them. A
99+new package may appear if its dependencies were part of this issue but
100+have been updated since the last time we checked. We want to give
101+these new packages ample time to be upgraded.
97−If stackage-curator is happy commit the change ("Remove upper bounds and close #X").
103+If stackage-curator is happy commit the change ("Remove upper bounds
104+and close #X"). After doing this the next nightly build may fail
105+because some packages didn't have an upper bound in place, but
106+compilation failed. In this case revert the previous commit so any
107+disabled packages are enabled again, re-open the issue, and add a new
108+comment with the failing packages. This is to give all maintainers
109+enough time to upgrade for this case as well.
99### Amending upper bounds
111### Amending upper bounds
@@ -154,9 +166,12 @@ Comment out the offending packages from the "packages" section and add
154a comment saying why it was disabled:
166a comment saying why it was disabled:
157− # - swagger # BLOCKED aeson 1.0
169+ # - swagger # bounds: aeson 1.0
172+If this causes reverse dependencies to be disabled we should notify
173+the maintainers of those packages.
161## Updating the content of the Docker image used for building
176## Updating the content of the Docker image used for building