cybergreen-net / pm

Tech project management repo (issue tracker only)
2 stars 1 forks source link

Maintenance Log #39

Closed rufuspollock closed 7 years ago

rufuspollock commented 8 years ago

Assigned to: Arastoo Taken by Aaron

aaronkaplan commented 7 years ago

@rgrp , @chorsley , @kxyne I need the latest code to be uploaded to the github repos (etl2 and aggregator). Only then can I finish exporting the git commit log for the maintenance log

kxyne commented 7 years ago

we've provided the git log so we're done on this one.

rufuspollock commented 7 years ago

@aaronkaplan it is uploaded. I'd have imagined a maintenance log was more like: "System was down on X for planned maintenance. We upgraded site on XX date" rather than full commit log - but if this is what is needed no problem for us :-)

ataslim commented 7 years ago

@rgrp @aaronkaplan The issues you mentioned are the most crucial, and what we would expand on as a brief narrative if it was the case that, for example, the stats site went down for a period of time (and our gameplan to get it back up and operational). What would be the best way to record those events? Would the stats-new issues log suffice as a place to record that information?

That being said, the commit logs are also helpful to show JPCERT (especially for the stats site) some progress with development.

aaronkaplan commented 7 years ago

@ataslim:

I thought we said that the commit logs+issue list was sufficient ? (In the sense of what work was done ). Maybe the word "maintenance" log was not the best choice. Maintenance in the classical sense: we have no HW maintenance with AWS.

I did some maintenance work for my server which was / is used to calculate aggregated data. That would be classical Sysadmin work.

Please then define what "maintenance log" means. It's an ill defined term for me at the moment.


Mobile

On 30.09.2016, at 13:20, ataslim notifications@github.com wrote:

@rgrp @aaronkaplan The issues you mentioned are the most crucial, and what we would expand on as a brief narrative if it was the case that, for example, the stats site went down for a period of time (and our gameplan to get it back up and operational). What would be the best way to record those events? Would the stats-new issues log suffice as a place to record that information?

In general we put everything into issues. That being said, the commit logs are also helpful to show JPCERT (especially for the stats site) some progress with development.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

ataslim commented 7 years ago

@aaronkaplan JPCERT defines "Platform Operation" as the operation and maintenance of the CGI platform through AWS. That was defined at the beginning of the contract with JPCERT, so things are a little different now with respect to the servers (physical+AWS). I don't think it's a particularly well-defined deliverable, but if you have other ideas for how we can fulfill this request, let me know.

I still think the commit logs and issue list should suffice, along with Google Analytics. The last time we submitted an invoice, it was not sufficient because of the CSIRT Gadgets incident which resulted in the stats site being offline for some time. That required a more detailed explanation of our plan of action moving forward.

aaronkaplan commented 7 years ago

done