Templates: take PR Club content from YAML header

bitcoinops · Jun 26, 2024 · d14d242 · d14d242
1 parent 2f7d9f1
commit d14d242
Show file tree

Hide file tree

Showing 2 changed files with 49 additions and 33 deletions.
diff --git a/_includes/functions/pr-club.md b/_includes/functions/pr-club.md
@@ -0,0 +1,12 @@
+<div class="{{include.class | default: 'qa_details'}} {{jekyll.environment}}" markdown="1">
+{% for qa in page.qa %}
+  {% capture alink %}{% if qa.link != nil %}<a href="{{ qa.link }}" class="external">➚</a>{% endif %}{% endcapture %}
+  {% if jekyll.environment == "email" %}
+   - <i markdown="1">{{qa.question}}</i><br>{{qa.answer}}&nbsp;{{alink}}
+  {% else %}
+   - <details id="{{qslug}}" markdown="1"><summary><span markdown="1">{{qa.question}}</span></summary>
+     {{qa.answer}}&nbsp;{{alink}}
+     </details>
+  {% endif %}
+{% endfor %}
+</div>
diff --git a/_posts/en/newsletters/2024-06-14-newsletter.md b/_posts/en/newsletters/2024-06-14-newsletter.md
@@ -6,6 +6,42 @@ slug: 2024-06-14-newsletter
 type: newsletter
 layout: newsletter
 lang: en
+
+qa:
+  - question: What is the behavior change introduced by this PR?
+    answer: |
+      Behaviour is changed in three ways. First, as per the goal of this
+      PR, optional indexes are no longer wiped again when the node is
+      restarted before reindexing is completed. This aligns the wiping
+      behavior of optional indexes with that of required indexes. Second,
+      when a user requests a reindex through the GUI, this request is no
+      longer ignored, reversing a subtle bug introduced in [b47bd95][gh
+      b47bd95]. Third, the log line "Initializing databases...\\n" is
+      removed.
+    link: https://bitcoincore.reviews/30132#l-19
+
+  - question: What are the two ways an optional index can process new blocks?
+    answer: |
+      When an optional index is initialized, it checks if its highest
+      block is the same as the current chaintip. If it is not, it will first
+      process all missing blocks with a background sync, through
+      `BaseIndex::StartBackgroundSync()`. When the index catches up
+      with the chaintip, it will process all further blocks through the
+      validation interface using `ValidationSignals::BlockConnected`.
+    link: https://bitcoincore.reviews/30132#l-52
+
+  - question: How does this PR affect the logic of optional indexes processing new blocks?
+    answer: |
+      Before this PR, wiping the optional indexes without wiping the
+      chainstate means these indexes will be considered out-of-sync. As per
+      the previous question, that means they will first perform a background
+      sync before switching to the validation interface. With this PR, the
+      optional indexes remain in sync with the chainstate, and as such no
+      background sync is required. Note: background sync only starts after
+      reindex has completed, whereas processing validation events happens in
+      parallel.
+    link: https://bitcoincore.reviews/30132#l-70
+
 ---
 This week's newsletter announces a draft BIP for a quantum-safe Bitcoin
 address format and includes our regular sections with the summary of a
@@ -60,39 +96,7 @@ necessary.
 
 {% assign timestamp="23:28" %}
 
-{% include functions/details-list.md
-  q0="What is the behavior change introduced by this PR?"
-  a0="Behaviour is changed in three ways. First, as per the goal of this
-  PR, optional indexes are no longer wiped again when the node is
-  restarted before reindexing is completed. This aligns the wiping
-  behavior of optional indexes with that of required indexes. Second,
-  when a user requests a reindex through the GUI, this request is no
-  longer ignored, reversing a subtle bug introduced in [b47bd95][gh
-  b47bd95]. Third, the log line \"Initializing databases...\\n\" is
-  removed."
-  a0link="https://bitcoincore.reviews/30132#l-19"
-
-  q1="What are the two ways an optional index can process new blocks?"
-  a1="When an optional index is initialized, it checks if its highest
-  block is the same as the current chaintip. If it is not, it will first
-  process all missing blocks with a background sync, through
-  `BaseIndex::StartBackgroundSync()`. When the index catches up
-  with the chaintip, it will process all further blocks through the
-  validation interface using `ValidationSignals::BlockConnected`."
-  a1link="https://bitcoincore.reviews/30132#l-52"
-
-  q2="How does this PR affect the logic of optional indexes processing
-  new blocks?"
-  a2="Before this PR, wiping the optional indexes without wiping the
-  chainstate means these indexes will be considered out-of-sync. As per
-  the previous question, that means they will first perform a background
-  sync before switching to the validation interface. With this PR, the
-  optional indexes remain in sync with the chainstate, and as such no
-  background sync is required. Note: background sync only starts after
-  reindex has completed, whereas processing validation events happens in
-  parallel."
-  a2link="https://bitcoincore.reviews/30132#l-70"
-%}
+{% include functions/pr-club.md %}
 
 ## Releases and release candidates