Subject: [Tools-implementation] Analyzing the directory structure

From: Robert Sparks <[email-masked]>
Date: Mon, 24 Aug 2020 09:48:39 -0500

When going through the directory survey, I found it helpful to classify 
things this way:

* Should these be archived

     Contains things that likely could be moved offline

* Other ops related things

     Contains things like user home directories

* Place for packaged software to be or do its thing

     Things like amavis postfix and etherpad

     Things like postfix

     Things like the datatracker source and postconfirm

     Things like the many wikis and static websites

* Backup related things

     Dumps databases (though some of this may end up being artifact 
material)

* Artifact related things

     Charters, internet drafts,  audio files, public keys, and much 
miscellany

     This is where I think this group should spend a lot of time 
focusing - figuring out what we really should keep, what we only expose 
to software, and what we expose for public consumptions through rsync or 
other interfaces.

* Static web content (stuff that should be cached close to the edge)

     This is stuff like jquery libraries

* Mail archive related truth

     In the end I think this should all be thought about as artifacts, 
but we need to talk through this to make sure we're doing the right 
thing with all of it.

* Old website data that we could archive and remove?

     Also stuff that could likely be taken offline, but may need a 
closer look since it supported older websites

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 24 Aug 2020 17:41:30 +0200

> When going through the directory survey, I found it helpful to classify 

I find this classification very helpful, and I think it will make it
more possible to keep things in order going forward.  I see one issue,

>      Contains things that likely could be moved offline

Given the historic inability to migrate and update all relevant pages when
we've shifted platforms and working methods, I'd argue for moving things
into clearly labelled 'archive' locations, but never move them completely
offline.

As long as the IETFs model on openness doesn't change, anything that has
been web accessible should continue to be so.  Moving things to an 'archive'
area and definitely stopping to care for and order that material is fine;
making it inaccessible except to some few isn't right, I think.

> closer look since it supported older websites

Same comment as above, about 'archived' vs. 'offline'.

Best regards,

	Henrik

---

From: Robert Sparks <[email-masked]>
Date: Mon, 24 Aug 2020 11:06:44 -0500

I think the "archive" approach is the right principle to use.

However, there are a few things that might really be removable as they 
weren't external artifacts, or were so badly used as to not contain 
anything useful.

Examples:

/a/svn : A legacy svn server - perhaps only internally used?

/a/www/webdav - attempts at supporting webdav-based calendaring

/a/www/wwws/calendars - more attempts at calendaring

/a/ietf - scripts used by the old mail archiving pipeline

For the things we keep in such an archive, I think we want to be very 
clear that these are in cold storage, nothing reads from them or serves 
them. If something is still exposed in any fashion, it should be treated 
in a separate bucket (as an artifact if it's static, or as a "still in 
production even if really dead" website.