Re: Long time outdated jemalloc

I've been swamped. we need to bootstrap the vendor branch, and the way
prior updates were done
isn't so great.

Warner

On Mon, Nov 25, 2024 at 2:21 AM cglogic <cglogic@protonmail.com> wrote:

> 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 <
> minsoochoo0122@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 <imp@bsdimp.com> wrote:
>
>
>
> On Sun, Jul 21, 2024 at 2:03 PM cglogic <cglogic@protonmail.com> wrote:
>
>>
>> On Sunday, July 21st, 2024 at 6:54 AM, Warner Losh <imp@bsdimp.com>
>> wrote:
>>
>>
>>
>> On Sat, Jul 20, 2024 at 1:59 AM cglogic <cglogic@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
>
>
>
>