On Mon, Jun 29, 2026 at 10:03:45AM -0400, Ben Cotton wrote:
Hi,
[...]
> I would argue against storing Changes in Markdown, though, as it
> doesn't really solve the "wikitext is bad for this" problem. Markdown
> is more familiar and reusable, but the real problem is that a Change
> proposal isn't just text. There's a lot of metadata.
What metadata are you referring to here? Is it about the bits stored in
"Current status"? Or is there something more special?
> So something like
> yaml, with some fields being Markdown, would be a more apt choice.
> This, of course, means that people would either have to hand-write
> yaml (boo!) or we'd have to write and maintain a small program that
> would take input from the user and write the yaml (or json or XML or
> ...).
This YAML + Markdown sounds like an unncessary complication. Can you
please explain why we can't keep everything in a single file?
As an example, the OpenStack project has a process of "specs" to propose
moderate-to-large changes and features. These are written in a single
reStructuredText (rST) file, and are rendered in HTML. E.g. for the
compute project (called "Nova"), this is its latest template. If you
scroll twice, on the left, you'll see the structure of the page under
"Page Contents":
https://specs.openstack.org/openstack/nova-specs/specs/2026.2/implemented/2026.2-template.html
You can skim a "real" feature spec based on the above template, rendered
in HTML:
https://specs.openstack.org/openstack/nova-specs/specs/2026.2/approved/intel-tdx-libvirt-support.html
(The raw rST source of the above:
https://raw.githubusercontent.com/openstack/nova-specs/refs/heads/master/specs/2026.2/approved/intel-tdx-libvirt-support.rst)
Change proposers need not edit any additional YAML or anything. All the
changes and whatever "metadata" (including brief revision history across
releases) is kept entirely in a single source (rST) file. It is
proposed as a change, it gets reviewed and if accepted, merged.
A similar, simplified template could be used for Fedora's needs.
> I get the appeal of a git-based workflow and I think it offers a lot
> of benefits. But it's not as easy as it sounds on the surface. Or at
> least, it still puts the Change Wrangler in a position where they
> spend a lot of time fixing formatting issues to make the scripts work.
I don't understand -- why should the Change Wrangler spend a lot of time
fixing formatting issues?
How about this flow:
Write a change in Markdown, or whatever, and submit it as a patch / PR
for review. Until all formatting errors or whatever "broken basics" are
fixed by the change submitter, the Wrangler can choose not to review it.
Once it is ready, review, merge/reject as appropriate.
[...]
--
Kashyap Chamarthy / Red Hat / RISC-V and Fedora
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://forge.fedoraproject.org/infra/tickets/issues/new
