Closed guusdk closed 1 year ago
Thank you Georg for the support!
Some further input from Jonas:
attic maintenance + email notification both have a core issue, which is that they need to keep state somewhere. Once the state-keeping is resolved, the implementation is quite trivial, because tooling does exist for both archiving stuff to the attic (maybe it needs like 5 lines of extra bash to automate the commit, pulling and modifying a quote from Edgar Allan Poe's The Raven and pushing, but that's about it). This state-keeping would then also be extremely helpful for automating the publication of new documents; with the current process of building without keeping state, we have to expect to pay significant CI fees soon, because we're building not only HTML but also PDF versions from scratch every time, a task which takes about 10-15 minutes on my 8-core machine when it does nothing else. On the other hand, there is not much, if any, tooling for XEP-0001 conformance checking. Hence a person would have to first understand XEP-0001 and the implications and then implement a tool to check that and provide useful feedback to the PR author. I.e. there's much more work to do here than for the other three tasks I mentioned so far, especially if one makes use of the synergies between them.
Just leaving further information from Jonas in xsf@. It needs it to do a diff of the old and new git master (which means keeping the state of the last master) and do calculations based on that.
( I proposed an approach:
foreach xep in *.xml:
extract ver
if not check attic for ver:
git tag
copy to attic
commit attic
push to attic and xeps.git
that doesn't use Git diffs, so isn't what's needed)
Closed in favour of #1236 and #1241, which should make for more clearer work packages. Re-open if you disagree.
Ensuring versions showing up in the attic is a manual process, which should be automated. There should be some automation which detects addition of a
<revision>
block, tags the commit, builds the thing and pushes it into the attic.For the point above to work correctly, it is required that a revision block is only ever added after all changes belonging to that revision. Hence, it must be enforced that a PR does not change a document in any commit after the one adding a revision block.