From nobody Sun Jul 21 03:54:36 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WRV0p5Dtxz5Qr2d for ; Sun, 21 Jul 2024 03:54:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WRV0n4Nc5z4LPH for ; Sun, 21 Jul 2024 03:54:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-1fc2a194750so31191045ad.1 for ; Sat, 20 Jul 2024 20:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1721534088; x=1722138888; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=kiE9r9ybYackSey1NUpLQOZvFwKJka3fsFClgxKOe6E=; b=D+g5c7jQ/lOahPe739mKGVaX2yV1tcKfXjNsCZxVBJrwrL50490U0f6AsuDDONyPVb zjQ3sivbJLgYX2G4jSlk7Ly6Z0agvfhP1FdOneVh+q2COHKTI62URm1SdRxk3csSIg3A u7ueWyxHysEgzCXvNoMPu+aiD2EGVfaqFS+5MSIjc4sxvKTGEWJOSByaRDiI+GHjvZVE jfRCiYi9iwJWWc9pqHQW61JxfrbbczAvZ4eZEnz/DiVwHCpXmEFoc2IzcobWiAeQvgms x8ZRS+fyUbJeCmIkvLTLzaDwet/O3sJ0V0Tgc4vTZqE1IRT0BY1rTv/rj2tRzRzkzsph 9Nrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721534088; x=1722138888; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=kiE9r9ybYackSey1NUpLQOZvFwKJka3fsFClgxKOe6E=; b=fl8iH92YbF8iqSRkccAj9zAO/KgOx0F1aaEN8lSIba24Mdrv2h3IvFBYRzbd1Pb6Vu /AxMo6xo40IeArlF2liGP5beuvpzB+ZtoH/6c+yEoWY8X9v6H9LY460ODQd2rx/EtZjX S0c18bhlP4A3nTDzG11bzrORp8mX/izmSMKyP/bGCLxg8ilfJMpWtL7LQ61AXWWCgDse 6mSm+rlzuUCRbtIFW1GcQE+OHlkw2i4SK16qaxLJwCU9n9rRozsYwMEFQgD4lLZk2r1X 276aISm18O0/PyeaqV7FV3e05ojma+1cqLNKYA5yOinFQIT/o669UssR6GK48QdQgLUh tzYw== X-Gm-Message-State: AOJu0YwQfyZy0Qbj3AlBTLzyUDNFJtT8ema7PWGzlQYUzqa1htzRhGMK gDjd/Og2c1H4REaVXEo7XjtUtwMsOAeIq6YmelfbKQ5UDu06uQ9385kiWGO60o529iUe1GjQu4Q IJ8Fuvt11QcKlTeAeCwtEBCzen6/DouMiR4BBVHBxDyA8N+R4Ooc= X-Google-Smtp-Source: AGHT+IE0sSQsMy9NKpp1vLMkPNzvTC0dghF8pPpzB8udSwenSgveGhFcUdiPus9qMZ/6CLNyiv4j58O4CFpWLLJosKs= X-Received: by 2002:a17:902:da92:b0:1fd:876f:ed79 with SMTP id d9443c01a7336-1fd876ff02amr20530565ad.65.1721534087646; Sat, 20 Jul 2024 20:54:47 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sat, 20 Jul 2024 21:54:36 -0600 Message-ID: Subject: Re: Long time outdated jemalloc To: cglogic Cc: FreeBSD CURRENT Content-Type: multipart/alternative; boundary="000000000000c3734e061db9e3f9" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WRV0n4Nc5z4LPH --000000000000c3734e061db9e3f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jul 20, 2024 at 1:59=E2=80=AFAM cglogic wr= ote: > 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 t= o > 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 --000000000000c3734e061db9e3f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jul 20, 2024 at 1:59=E2=80=AF= AM cglogic <cglogic@protonmail= .com> wrote:
Hello FreeBSD community,

<= span style=3D"display:inline;background-color:rgb(255,255,255)">After=C2=A0= Jason Evans steppe= d aside from maintaining jemalloc in FreeBSD, it's not updating in time= anymore.
Version 5.3.0 = was released=C2=A0May 6, 2022 and FreeBSD still not imported it into = the tree.

<= /div>
There is a pending review=C2=A0https://reviews.freebsd.org/D41421=C2=A0fr= om=C2=A0Aug 11, 2023.
I'm successfully running FreeBSD/amd64 system with D= 41421 applied for 8 months, as well as many other people.

Can it be reviewed and committ= ed to CURRENT?
= Or, if there is no committers willing to do it, can commit bit be giv= en 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 ignore= d by the developers.
Every year FreeBSD Community Survey aski= ng about user experience in contributing to FreeBSD.
= Here you can see an example of such contributing.
=


First, thank you for being persistent and cont= inuing 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 upda= te. 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 contributio= ns":
(1) The original submission was close to the 14 branch = creation time. This meant that we weren't well prepared to look at it s= ince it is such an invasive change (at least on its surface). It also slowe= d the initial response...
(2) There was a number of back and = forth requests for changes, which took time to sort out...
(3) Th= e size of this is huge, well beyond the capacity of Phabricator to review a= ccurately...
(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 tr= ack 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 mig= ht steer this towards github, but the 'vendor import' means you rea= lly need someone on the inside, or you need to be on the inside to make tha= t work.

So, how to move forward? Well, I'd lik= e to propose the following:
(1) submit all the other Phabricator = reviews you have open (they are mostly good, or close to good) to github. G= ithub is being actively managed and will make it faster to get things it. I= t's a much better tool for new contributors (and even frequent contribu= tors 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 c= an then layer on your changes and those can be reviewed more closely as a p= ull request against the branch I push. I suspect that most of the issues ar= e sorted out already
(3) I'll land it via that route...<= /div>

And, if the sum of the other pull requests and thi= s 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 g= et things and and the best place to send people...=C2=A0
Thanks again for persisting, and also for expressing this criti= cism that we (hopefully) can use to make it better.

Warner
--000000000000c3734e061db9e3f9--