Page MenuHomeFreeBSD

status/report-2022-01-2022-03: Add report
ClosedPublic

Authored by salvadore on Jun 4 2022, 10:46 AM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Apr 23, 5:55 AM
Unknown Object (File)
Mar 16 2024, 7:52 AM
Unknown Object (File)
Mar 16 2024, 7:52 AM
Unknown Object (File)
Jan 18 2024, 9:56 AM
Unknown Object (File)
Jan 14 2024, 11:25 PM
Unknown Object (File)
Dec 23 2023, 12:40 PM
Unknown Object (File)
Nov 22 2023, 4:16 AM
Unknown Object (File)
Nov 22 2023, 4:16 AM

Diff Detail

Repository
R9 FreeBSD doc repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

salvadore created this revision.

If you have any comment regarding the order of reports, please also check this GitHub pull request:
https://github.com/freebsd/freebsd-quarterly/pull/471

That is the file that establishes what the order is.

The report has been generated using the new automated tools, that I will soon commit to the GitHub repository. They are still at the first version: most probably, I am going to add new features to them.

I've made some suggestions for where various entries belong, but that's about it I think.

Also, to make it clear to everyone: @salvadore has blanket permission from me to commit things related to quarterly reports in the doc/website/content/en/status for these reports, as well as making changes to doc/website/data/en/news/news.toml which is needed to make announcements appear on the front-page.

website/content/en/status/report-2022-01-2022-03/_index.adoc
66

Having seen several talks from @cperciva on this topic, I think it's fair to say that boot performance belongs thoroughly in the projects category above, since it spans both the boot loader, kernel, and userland. :)

127

We have a category for third-party projects, that this seems to belong in, more-so than the ports category - that's at least how I read the entry, about it being primarily a third-party project that just so happens to be in ports.

140

Entries from helloSystem have in prior reports been in the third-party category as well, so I'd like to see them moved there.

grahamperrin added inline comments.
website/content/en/status/_index.adoc
16

Realistically: I can't see that single-paragraph summaries are a norm.

The preceding paragraph relates to the operating system, for which there is a single repository.

This paragraph relates to development within and beyond multiple repositories.

website/content/en/status/report-2022-01-2022-03/clusteradm.adoc
28
website/content/en/status/report-2022-01-2022-03/doceng.adoc
30

Is this intentionally a duplicate of the point that appears in clusteradm.adoc above?

website/content/en/status/report-2022-01-2022-03/freebsd-foundation.adoc
36
152–153

Open Source Voices Episode 29: Deb Goodkin - Executive Director of The FreeBSD Foundation

https://www.opensourcevoices.org/29

website/content/en/status/report-2022-01-2022-03/gunion.adoc
2

Instead of Facility: Utility?

(All subsequent descriptions of gunion(8) are of a utility.)

website/content/en/status/report-2022-01-2022-03/hellosystem.adoc
25

This is effectively a duplicate of the second bullet point.

website/content/en/status/report-2022-01-2022-03/iwlwifi.adoc
7

Uppercase .ORG is non-conventional.

24
website/content/en/status/report-2022-01-2022-03/ocf-wg.adoc
4
website/content/en/status/report-2022-01-2022-03/portconfig.adoc
24

Presumably written by Alfonso, one of the two named contacts.

website/content/en/status/report-2022-01-2022-03/pot.adoc
2
website/content/en/status/report-2022-01-2022-03/releng.adoc
5
website/content/en/status/report-2022-01-2022-03/rtw88.adoc
8

Uppercase .ORG is non-conventional.

13

I'm undecided about the because-it's-late updates (changes in 13.1 status, etc.).

website/content/en/status/_index.adoc
16

Realistically: I can't see that single-paragraph summaries are a norm.

I can. Notice it says "includes", not "limits itself to".

This paragraph relates to development within and beyond multiple repositories.

While on that topic, though, I'd use less restrictive language than "developers". The explicit list "developers, documenters, and ports maintainers" feels awkward, so maybe "regular contributors"? ("Regular" because occasional contributors would be less likely to submit a report or need to, I think.)

website/content/en/status/report-2022-01-2022-03/gunion.adoc
2

I'm not sure. I'm tempted, if they need to be the same, to use "facility" everywhere, since there's more to it than the administration utility. This is really about the geom class aw a whole. But considering this change should really be cleared with the author, I would ignore it to save a roundtrip.

website/content/en/status/report-2022-01-2022-03/hellosystem.adoc
25

This is effectively a duplicate of the second bullet point.

website/content/en/status/report-2022-01-2022-03/iwlwifi.adoc
7

A recent email to me used

Bjoern A. Zeeb <bz@FreeBSD.org>

So while I can sort of see s/ORG/org/, I'd let the rest be.

website/content/en/status/report-2022-01-2022-03/ocf-wg.adoc
4
website/content/en/status/report-2022-01-2022-03/rtw88.adoc
8

As above, I'd use FreeBSD.org.

Thank you very much to all of you for your feedback. I should be able to address all of your comments in the next 48 hours.

@debdrup: I have updated the GitHub pull request with your comments. As soon as I have fixed the other issues too this review will also be updated.

website/content/en/status/report-2022-01-2022-03/_index.adoc
140

I wanted to put helloSystem in third-party category too, but I got confused and put it in the wrong one. The same issue applies to pot.adoc below: in https://www.freebsd.org/status/report-2021-10-2021-12/ the report was in the third-party project and not in miscellaneous. I have moved that too.

I'm undecided about the because-it's-late updates (changes in 13.1 status, etc.).

I am going to try to leave the original text as it is to reflect what the state of the projects was in 2022q1. But since at the same time it is true that we are late and things have changed, I am also adding notes from the status reports team.

For example,

The upcoming 0.8.0 release will be based on FreeBSD 13.1-RELEASE once it is available.

would become

The upcoming 0.8.0 release will be based on FreeBSD 13.1-RELEASE once it is available [note from status report: link:https://www.freebsd.org/news/newsflash/#2022-05-12:1[13.1-RELEASE has now been released]]

Let me know what do you think of this solution.

website/content/en/status/_index.adoc
16

Since there is no immediate agreement on this fix, I suggest we deal with it in another review and focus now on the 2022q1 quarterly report.

Personally, I also interpret the actual text as implying that reports are one paragraph only, so, although other interpretations are possible, I think it can be improved so that it becomes unambiguous.

As for the "developers" word being too restrictive, I would go with "developers and contributors" or just "contributors". Indeed, those are the words that are used in the FreeBSD contributors list, which include developers:
https://docs.freebsd.org/en/articles/contributors/

@grahamperrin_gmail.com: Since you spotted the issue, I think it would make sense that you create the new revision. May I ask you to do it please?

website/content/en/status/report-2022-01-2022-03/clusteradm.adoc
28

I think the mirror has been chosen on purpose. I think this should help some users to access the site more smoothly.

website/content/en/status/report-2022-01-2022-03/doceng.adoc
30

It seems it is. I think it makes sense:

  • the point is relevant for clusteradm as it concerns mirrors;
  • it is also relevant for docs as it concerns documentation.
website/content/en/status/report-2022-01-2022-03/gunion.adoc
2

I am not sure either. My interpretation is that a new facility called "gunion" has been added and that you interact with it through an utility also called "gunion". As I am not a native English speaker, I don't feel very confident with this interpretation however and in general I would simply trust that the author choose his words with care.

But since in this case the author is on phabricator, it is easy enough to ask him. Moreover, the editing of the report still requires some time, so asking him should not slow things down much.

@mckusick: Do you confirm that the words "facility" in your quarterly status report title and "utility" in the text are the terms you want to use or do you prefer to change something?

website/content/en/status/report-2022-01-2022-03/portconfig.adoc
24

You must be right, he also submitted the pull request:
https://github.com/freebsd/freebsd-quarterly/pull/452

salvadore marked 17 inline comments as done and an inline comment as not done.Jun 7 2022, 11:39 AM

Here is the new version of the status report.

Let me know if this helps clarify gunion.

website/content/en/status/report-2022-01-2022-03/gunion.adoc
2

gunion provides a new capability to GEOM. Much like raid, or stripping, or mirroring.
Each of these could be considered utilities as they are accessed using the graid3(8), gstripe(8), and gmirror(8) utilities. I do understand your confusion as the body of my text just launches into the gunion(8) utility.

I propose that all instances of "gunion(8) utility" be changed to "gunion facility" Here is my proposed new description:

A New GEOM Facility, gunion

Contact: Marshall Kirk McKusick <mckusick@mckusick.com>

The gunion facility is used to track changes to a read-only disk on a writable disk.
Logically, a writable disk is placed over a read-only disk.
Write requests are intercepted and stored on the writable disk.
Read requests are first checked to see if they have been written on the top (writable disk) and if found are returned.
If they have not been written on the top disk, then they are read from the lower disk.

The gunion facility can be especially useful if you have a large disk with a corrupted filesystem that you are unsure of how to repair.
You can use gunion to place another disk over the corrupted disk and then attempt to repair the filesystem.
If the repair fails, you can revert all the changes in the upper disk and be back to the unchanged state of the lower disk thus allowing you to try another approach to repairing it.
If the repair is successful you can commit all the writes recorded on the top disk to the lower disk.

Another use of the gunion facility is to try out upgrades to your system.
Place the upper disk over the disk holding your filesystem that is to be upgraded and then run the upgrade on it.
If it works, commit it; if it fails, revert the upgrade.

The gunion(8) utility is used to create and manage an instance of a gunion. Further details and usage examples can be found in the gunion(8) manual page.
At this time, gunion(8) is available only in 14.0.

Netflix sponsored the development of gunion.

@mckusick: Thank you very much for your quick response. I have updated the report with your proposed new description, which is clear for me.

@grahamperrin, @debdrup, @pauamma_gundo.com: Let me know if you have any more comments. Once we agree on the final version, I will commit the new quarterly status report and also push the edits we are discussing in the GitHub repository, which I am already committing locally as the process reviewing goes forward.

I don't think there's anything else I remarked on that needs to be addressed, so if everyone else would accept it if theirs has been dealt with, we can get the needful done.

This revision is now accepted and ready to land.Jun 8 2022, 4:56 AM

With the nits above fixed, LGTM. Thanks for the IRC ping.

website/content/en/status/report-2022-01-2022-03/freebsd-foundation.adoc
152

*donning unofficial accessibility advocate hat briefly*

website/content/en/status/report-2022-01-2022-03/gunion.adoc
24

IIRC, the usual wording (see end of report-sample.adoc) is

Sponsor: Netflix

website/content/en/status/report-2022-01-2022-03/hellosystem.adoc
25

Uh. Forgot what I meant to write here.

This revision was automatically updated to reflect the committed changes.

Report has finally been committed, with the last edit from Pau Amma. Thanks everyone for your work.

@debdrup: In the commit message I wrote "Approved by: debdrup (status blanket)". Since you actually approved explicitely, this is a mistake, I should not have used the blanket: sorry about that. On the other hand, at least the status blanket approval has been seen for the first time, so maybe it is not that bad.