Index: trunk/doc/release.2015/ps1.datasystem/response.v1.txt
===================================================================
--- trunk/doc/release.2015/ps1.datasystem/response.v1.txt	(revision 41208)
+++ trunk/doc/release.2015/ps1.datasystem/response.v1.txt	(revision 41234)
@@ -1,3 +1,49 @@
 
+** We are resubmitting our article "The Pan-STARRS Data Processing
+   System" after addressing suggestions raised by the referee.  We
+   thank the referee for detailed comments and suggestions.  Below are
+   our responses to the referee's suggestions.  (Our responses are
+   preceeded by "**")
+
+# General Notes
+
+This is a well-written and important technical paper that succeeds
+admirably at what I consider the most important goal of any pipeline
+paper: providing a decription of the processing steps that are
+relevant for downstream science users (in this case, by providing the
+big picture that ties together a number of more detailed papers). With
+only a handful of minor cleanups (see detailed notes below), I think
+the paper is ready for publication, and most of my comments represent
+ideas for improvement that I hope the authors will consider (but
+should not feel obliged to act on).
+
+My only general concern is that the paper often misses the opportunity
+to pass on lessons learned to the developers of future pipelines, and
+this makes much of the detailed description of how the PS1 systems
+work (particularly in Section 5) feel like it belongs more in operator
+documentation rather than an article like this one. I suspect a small
+amounof additional historical context - how different systems evolved
+over the course of the survey - and commentary on what worked well and
+what was a regular pain point would go a long way.
+
+In particular, the described system seems to involve a both fair
+amount of duplication (e.g. multiple databases, sky-tiling systems,
+and task orchestration layers) and a number of in-house solutions to
+what seem like fairly general problems (the DVO database and
+especially the pantask/opihi system stand out in this regard). This is
+not intended as criticism; I am quite aware that there are many good
+reasons for both duplication and keeping central components in-house,
+from deliberately keeping components loosely coupled to taking into
+account the often-brief shelf-life of off-the-shelf solutions,
+especially as compared to the duration of a major astronomical
+survey. But describing *which* of many potential reasons actually
+played a role in each of various design choices (and which, if any,
+look less good in hindsight) would make the paper much more
+interesting.
+
+** We have greatly expanded the Conclusion to address these questions,
+   and to identify choices we made which either turned out well or
+   which we would have done differently given changes to the software
+   landscape.
 
 # Detailed Notes