Add 2022q4 Azure report.

[lwhsu]

No description provided.

[pauamma]

URL: link:https://wiki.freebsd.org/MicrosoftAzure[https://wiki.freebsd.org/MicrosoftAzure] and likewise for the next one.

[pauamma]

s/requirted/required/

What does "ZFS-bared" mean?

s/image/images/, I think.

[pauamma]

s/automaitc/automatic/

[pauamma]

link:https://docs.microsoft.com[https://docs.microsoft.com] (or more explicit link if there's a specific subdir for FreeBSD)

[lwhsu]

I think repeat the same URL in the square brackets isn't very useful, and may even cause some editing error in the future. Just using the link: macro and [] to explicitly mark the URL part should be enough for all the cases, including the special characters.

Also, I just found that this seems what other files do. I am OK to add to this one, but I strongly suggest let's remove to a simpler syntax, in this, or at least the next quarter.

[grahamperrin]

… repeat the same URL in the square brackets …

If I understand correctly, the repetition is currently to add links to the mail version:

• Avoid breakage of URLs in plain text representations of quarterly reports #530 (comment)

[grahamperrin]

From https://github.com/freebsd/freebsd-quarterly#readme, with emphasis:

… please, do not squash or force-push …

[pauamma]

NTS: fill in empty []s.

[lwhsu]

From https://github.com/freebsd/freebsd-quarterly#readme, with emphasis:

… please, do not squash or force-push …

Apologies, didn't notice this policy change. BTW, force-push on feature branch is quite common and useful to keep the history (of the main branch) clean, this is widely used in many other pleases. Also the review feature of GitHub is improved to cope with it. Please seriously consider this.

cc @lsalvadore

[lsalvadore]

The reviewing procces is mainly in @pauamma's and @grahamperrin's hands, so I think they should choose what works best for them about squashing and force-pushing. Personally, I have no preference.

A few thoughts about the topic:

• starting from the next quarter, if everything goes as planned, authors will be able to submit their reports on Phabricator too. Things such as squashing and force-pushing are not part of the usual Phabricator workflow: authors will submit their work, modify their files following the reviewing process and only one single commit to the docs repository will end the review. Further changes will require more commits and could not be squashed in the past commits;

• if one wants a cleaner history in the main project, it is not necessary to force-push anything in pull requests: it is enough to select the "Squash and merge" option in GitHub when merging the pull request and only one commit will result. And using git from command line allows for even more flexibility (and then GitHub might not automatically recognize the pull request merging: this often happens to me. Not a big deal). However I also understand that some report authors might prefer to keep a clean history with multiple commits, which would require to force-push.

• policies are useful and important, but they also need to be applied with care for special cases. See for example my recent pull request 2022q4/core.adoc: Add report #562: I only had to fix a typo in a commit message, without modifying any file. It would have been absurd to merge the pull request including the commit message with the typo instead of amending it and force-pushing;

• attempting to keep a clean history is nice, but is also difficult. Indeed, what happens in pull requests is only the first main reviewing process, but later the reports are reviewed again. I review them once again when I put them together and render them, correcting a few things here and there as needed (mostly adoc syntax and typos). Then they can be reviewed again when I open the Phabricator review to commit the changes to the docs repository. And the final review is done by our readers, who are often able to spot a few more things after publication in spite of our best efforts. Thus, many reports happen to get more than one commit even if they were created with only one clean single commit pull request;

• I think we all agree that a cleaner history is better. However, we should not forget that if we use a VCS it is also to keep track of who does what and why. And also to change our mind if we want to. Cleaning history risks to go against these goals.

[grahamperrin]

Thanks, all

… choose what works best for them about squashing and force-pushing.

I'm aware of the plea in https://github.com/freebsd/freebsd-quarterly/blob/main/README.adoc only because I helped to edit the file.

Personally, I have no preference. …

I don't know enough about Git to express a preference.

If someone can point me to a case where a squash or force-push did cause difficulty, I might form a preference …