HW Relnotes: Enable Table of Contents Subsections

[concussious.bugzilla_runbox.com]

Summary

I think this really helps the page. I only did the template and upcoming releases, but would be willing to do past ones for consistency if that is appropriate.

May I also (I'm thinking separate reviews):

1. Put the TOC below the introduction?
2. Remove or add "Architecture Support" to all subsection titles in section 2 for consistency?
3. Rename 2.2 "32-bit x86 (i686)" for consistency with the other subsection titles (also these do not support i386 or i486.)
4. Remove 2.3 entirely for consistency.

If this is acceptable, please git commit --author ="Alexander Ziaee <[e-mail]>" so I can demonstrate my activity. Thanks!

[pauamma_gundo.com]

Re your 3, if you change the section title, I would suggest keeping "i386" since it's the name FreeBSD for the architecture itself, minimum processor generations supported regardless, and instead mention which processor generations it supports, or maybe link to the section of the release notes with that info.

[concussious.bugzilla_runbox.com]

Okay, sounds good to me!

[concussious.bugzilla_runbox.com]

Polite ping? I made this commit atomic and scoped tightly so that we can move quickly, to facilitate ease of contribution to the HW relnotes. Is this controversial?

[cperciva]

@bofh Can you look at this and the submitter's other questions? You're in charge of release notes. :-)

[cperciva]

In D47272#1081379, @concussious.bugzilla_runbox.com wrote:

Polite ping? I made this commit atomic and scoped tightly so that we can move quickly, to facilitate ease of contribution to the HW relnotes. Is this controversial?

Sorry, been busy with other stuff. Hopefully Moin can handle this and your other release notes changes.

[concussious.bugzilla_runbox.com]

Copy! No problem, thank you for the quick response! I'll tag him in the future.

[concussious.bugzilla_runbox.com]

Oh grandmasters, please accept my humble and respectful ping! Beta 2 just branched. This commit makes the release hw notes are more accessible, so it can be easier for people to notice where to improve them, which they are less inclined to do the further the release progress comes.

[bz]

@bofh ping6

[mhorne]

This is indeed an improvement. On its own the change is non-controversial, so if @bofh does not reply today I will just commit it.

Personally I agree with your point 4, that section no longer serves a purpose and can be removed.

FYI for next time, this change would have been much easier to evaluate if it was uploaded with a screenshot of the affected content (phabricator can embed this in the summary/testing section). I had to build it myself to see the result.

[concussious.bugzilla_runbox.com]

Thank you so much! I will screenshot these in the future.

[bz]

In D47272#1084351, @mhorne wrote:

FYI for next time, this change would have been much easier to evaluate if it was uploaded with a screenshot of the affected content (phabricator can embed this in the summary/testing section). I had to build it myself to see the result.

Yes. Ia also wondered if the website could have the template build as "CURRENT" continuous release notes so we'd have an almost constant view of the expansion and the state of FreeBSD main AS-IS. I know it's unrelated but in worst case this could have been committed to the template and backed out a few hours later.. doceng

[concussious.bugzilla_runbox.com]

Yes. I also wondered if the website could have the template build as "CURRENT" continuous release notes so we'd have an almost constant view of the expansion and the state of FreeBSD main AS-IS.

This would be a major step forward, and probably less stressful than trying to fix this stuff at the end when it finally becomes visible. I would love to learn how to fix these types of problems. Also it would be helpful for new users in our social spaces constantly asking if $foo is fixed in CURRENT.

[concussious.bugzilla_runbox.com]

Thanks Mitchell!