guusdk
commented
7 years ago I can't shake the impression that we're overreacting here. This (not your specific approach, but the generic idea of separating content from generation) seems to introduce technical complexity and procedural red tape, and have little benefit for the XSF.
The amount of people actively involved with maintaining the website is pretty low. Making use of individual expertise is good, but explicitly defining what people can or cannot do won't be productive. We're a small bunch of people - instead of segregating, we should work more as one team, and take responsibility for any failures as one team.
horazont
I’ll be dropping some random notes here about how we could move forward on separating the content of the website from the generating code. This is sparked by a discussion in the XSF MUC and the todays Board meeting.
First, I did this already for another organisation. You can see the repositories here:
This could be a starting point for us here. Note that the Makefile in the -build repository is not the default Pelican makefile; we made some modifications to make it support an out-of-tree
contentandoutputdirectory.Also note that this is not 100% safe. Pelican is not really made for this kind of scenario (I think) and even though https://github.com/getpelican/pelican/pull/2099 got merged, it is not in any release (yet) I think. One can thus write to arbitrary writeable paths from within the content. Just something to keep in mind – doesn’t matter when the build process is chrooted I think.
The idea is to separate the privilegues for changing code vs. changing content. Content doesn’t need to be reviewed by infrastructure (assuming you assume pelican to be reasonably safe) that way.
As mentioned, dropping random notes here. Please challenge everything in this you want to challenge.