I believe that we also want to add him to contrib-develalumni.adoc

In D49061#1121430, @yklaxds_gmail.com wrote:

I have already talked with Li-Wen. If there are no issues, please help merge it.

Per https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284875 , I can check the content of this site.

As there is no announcement of extension from sectem or releng, I believe it's fine to commit this without explicitly approval from them.

In D48199#1099009, @aokblast wrote:

The elf parse, ctf parser is all from ctfdump and refactor it into C++. However, because it is cddl licensed, I am wondering if there is any legal concern?

In D48194#1099000, @bofh wrote:

In D48194#1098982, @lwhsu wrote:

Another thing also not directly related to this openjdk23 port is that the bootstrap chain would be long this time. It would be 23 -> 22 -> 21 -> 20 -> 19 -> 18 -> 17. We may want to create bootstrap-openjdk21 in the future, before openjdk17 decommission.

Considering 17 as an LTS version of somewhat although openjdk builds are not considered LTS I think we should concentrate on bootstrap-openjdk21 and decommission 18, 29 and 20.

Another thing also not directly related to this openjdk23 port is that the bootstrap chain would be long this time. It would be 23 -> 22 -> 21 -> 20 -> 19 -> 18 -> 17. We may want to create bootstrap-openjdk21 in the future, before openjdk17 decommission.

One very minor stuff, we can update the comment in Mk/bsd.default-versions.mk

How about Realtek 802.11n wireless 8188 (RTL8188CE, RTL8188EE)?

Will we (or how about directly) move them to wifi-firmware- ports?

In D47942#1093222, @emaste wrote:

want to remove the repo data in the cache and unregister the pkg itself like what we do in VM

Perhaps, but I think this issue is fundamentally different than the VM case and I would suggest we both make this (D47942) change and MFC it as soon as we can, and consider following up with further changes.

In D47930#1093223, @phil wrote:

Patch looks fine. I'll add to the main libxo repo.

Thanks,
Phil

In D47942#1093167, @lwhsu wrote:

That's a good catch, and not sure if we also want to remove the repo data in the cache and unregister the pkg itself like what we do in VM. Having those might cause an issue when pkg is boostraped but repo data is seriously out-of-date. We encountered this in the past in the cloud images.

That's a good catch, and not sure if we also want to remove the repo data in the cache and unregister the pkg itself like what we do in VM. Having those might cause an issue when pkg is boostraped but repo data is seriously out-of-date. We encountered this in the past in the cloud images.

The Joining_the_Organisation section of the wiki pages mentions sending a signed mail to gitadm@ but somewhere (new commit bit mail template?) says filing a bugzilla ticket, thought. That's something we may need to check next.

This will result an empty https://www.freebsd.org/srcmgr page and only https://www.freebsd.org/srcmgr/charter/ . I suggest create a simple doc/website/content/en/srcmgr/_index.adoc file.

In D47595#1086754, @emaste wrote:

Is there any concern? Or we can adjust this comment?

No concern, we should just be (eventually) consistent and either prefer and use these here and in general, or if we don't prefer them we should abandon this review.

In D47595#1086661, @emaste wrote:

It looks like prison_lock/prison_unlock is not widely used, other than in sys/kern/sysv_msg.c. Should this be done more widely?

In the proposed commit message, I guess you mean:

I read the commit message and haven't finished the code. The GID rules seems having much more features and I would like to know more. Do you think you can share some use scenarios and how to config the rule? I believe it would also be useful to have these in mac_do(4).