Hello guys, How the update of jemalloc is going? It's November now.
Thanks. On Monday, July 22nd, 2024 at 7:02 PM, Minsoo Choo <minsoochoo0...@proton.me> wrote: > First, sorry for late response. > > cglogic, thank you for bringing up this issue again since I nearly forgot > that this issue was still open. > > Warner, as I can't access to my FreeBSD instance until the end of August, but > I can still edit and push the code through my Arm Mac. This means that I > can't test the updated code on my machine, but I can join the review process > and listen to change proposals. > > I'll open a Github PR in a few hours. (The phabricator review will stay > opened just in case) > On Monday, July 22nd, 2024 at 5:08 AM, Warner Losh <i...@bsdimp.com> wrote: > >> On Sun, Jul 21, 2024 at 2:03 PM cglogic <cglo...@protonmail.com> wrote: >> >>> On Sunday, July 21st, 2024 at 6:54 AM, Warner Losh <i...@bsdimp.com> wrote: >>> >>>> On Sat, Jul 20, 2024 at 1:59 AM cglogic <cglo...@protonmail.com> wrote: >>>> >>>>> Hello FreeBSD community, >>>>> >>>>> After Jason Evans stepped aside from maintaining jemalloc in FreeBSD, >>>>> it's not updating in time anymore. >>>>> Version 5.3.0 was released May 6, 2022 and FreeBSD still not imported it >>>>> into the tree. >>>>> >>>>> There is a pending review https://reviews.freebsd.org/D41421 from Aug 11, >>>>> 2023. >>>>> I'm successfully running FreeBSD/amd64 system with D41421 applied for 8 >>>>> months, as well as many other people. >>>>> >>>>> Can it be reviewed and committed to CURRENT? >>>>> Or, if there is no committers willing to do it, can commit bit be given >>>>> to submitter or another person willing to do this? >>>>> >>>>> It's very disappointing when users spend their time to fill such gaps and >>>>> their efforts just ignored by the developers. >>>>> >>>>> Every year FreeBSD Community Survey asking about user experience in >>>>> contributing to FreeBSD. >>>>> >>>>> Here you can see an example of such contributing. >>>> >>>> First, thank you for being persistent and continuing to bring it up. It's >>>> important to do that to make sure this (and your many other) contribution >>>> doesn't fall on the floor. >>>> >>>> And to be fair, we're only 3 months since the last update. Still, quite a >>>> bit longer than you should have to wait, but not nearly the year the >>>> original date suggests. >>>> >>>> And this is a perfect storm of "how the project is bad at accepting >>>> contributions": >>>> (1) The original submission was close to the 14 branch creation time. This >>>> meant that we weren't well prepared to look at it since it is such an >>>> invasive change (at least on its surface). It also slowed the initial >>>> response... >>>> (2) There was a number of back and forth requests for changes, which took >>>> time to sort out... >>>> (3) The size of this is huge, well beyond the capacity of Phabricator to >>>> review accurately... >>>> (4) It's a vendor import. That means we can't just drop the Phabricator >>>> review into the tree... >>>> (5) It's phabricator: this is a great tool for developers, but we have a >>>> terrible track record of using it for intake from new contributors. We >>>> don't have any oversight at all over this tool, at there's at best tepid >>>> and luke warm attempts to look for drop balls. >>>> >>>> All of these things are a terrible experience. I can only apologize. These >>>> days, we might steer this towards github, but the 'vendor import' means >>>> you really need someone on the inside, or you need to be on the inside to >>>> make that work. >>>> >>>> So, how to move forward? Well, I'd like to propose the following: >>>> (1) submit all the other Phabricator reviews you have open (they are >>>> mostly good, or close to good) to github. Github is being actively managed >>>> and will make it faster to get things it. It's a much better tool for new >>>> contributors (and even frequent contributors of smallish things). >>>> (2) I should do an vendor import of 5.3.0 from github, and do the merge to >>>> a branch and push that to github. You can then layer on your changes and >>>> those can be reviewed more closely as a pull request against the branch I >>>> push. I suspect that most of the issues are sorted out already >>>> (3) I'll land it via that route... >>>> >>>> And, if the sum of the other pull requests and this are good (and I >>>> suspect they will be), then we can talk about commit bits and such. >>>> >>>> It's experiences like this which is why I'm trying to stand up github pull >>>> requests as a reliable way to get things and and the best place to send >>>> people... >>>> >>>> Thanks again for persisting, and also for expressing this criticism that >>>> we (hopefully) can use to make it better. >>>> >>>> Warner >>> >>> Hello. >>> >>> I'm not the author of D41421. Just applied the patch to test it 8 months >>> ago. And recently discovered that it's still not committed. >>> I can't copy your message to Phabricator because don't have an account. >>> Please, if you have time, help the author in D41421. >> >> Ah yes. I've been in touch with the author for other things, and somehow >> thought it was you.... I'll reach out to him via other means... >> >> Warner
