From nobody Tue Apr 23 19:34:46 2024 X-Original-To: dev-commits-src-main@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 4VPC4j0n0Cz5Hwd2 for ; Tue, 23 Apr 2024 19:35:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VPC4h4zkQz4flq for ; Tue, 23 Apr 2024 19:35:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-518a3e0d2ecso9115353e87.3 for ; Tue, 23 Apr 2024 12:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1713900898; x=1714505698; 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=4nABtxjxFiAq3elyYlUpVzeUNJzI/LREKyWCXdEbjjU=; b=IpxfeBiQ3snlai+mewC18ierXhoqF/Z9dneWX25IoI6fnZ0Tkgq3aL9cyCMImWbZQO G0u384O/AZ8jmdaKgHMKkCi+mqv6cP5JBV44g5RlarUGR8TflaHbfa4Ecje8GzPCD0P5 kgNWNm7mr4y/z/Ite+6TPwzXeiZe3OphiCDRVQMbZ66huitQPKK8jF2zeVWFklETY1GB eaCCEhgx/sPCII+zTyTgG2I/4iLO3SlNslHhNQxIdu2ziQxfDbipbt7ECpTUH8OWfycO rF8W5VlVaL3bBkn5kCK0/cH9SNcll1aGZ6YLbgm2xpjGy7FL49F1rmJJDhRolbgH2Ar3 oeyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713900898; x=1714505698; 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=4nABtxjxFiAq3elyYlUpVzeUNJzI/LREKyWCXdEbjjU=; b=oyb0106jVYHNvV6jn8h9FWQvvGcaGJfztIVc+Rca4FO3X69P9RteAc6afUUxVMHcjk zz3ef/sMQ7SRYisXR3/SAHVAtfaUCq/Jo/8NJNjC012Ou2pqAGb+w3Kxx7IAbhbcfPrH jH1bul7/gQQnV/5fnkjk7YHgKvmyQU4E89atlpUxp+JfK3ciQqcjlAJaodtTHH5bH6iA mZnMcnf///DINi4pAE2dBODYuc/1Q5nxrwdWek03zloW5jea8OwgyqPaAPAJm3BaeqKl sxgNic9TPdn2AtstThD0jO2adHYtQ5kKhNKxy6suQp2F4qButKTid9W1QsgkDRu5eaB1 NjOA== X-Forwarded-Encrypted: i=1; AJvYcCVntLsLJSapBXr3w7nxjeJsC+Ygw3gSC0UNw4CkI4K7xJO482KVeNFRGQ4hDMq2j8MqIEbYl4fn4yFdiIO9m2nEwgHgsRPbhEu+yCPx/kznkA== X-Gm-Message-State: AOJu0Ywa2BtdnWB+YGSf+qWup/oRV1LgfGdAiiTJlxM9WoH46lwFjfci PSk+Tyn20ybdyMlqFUi1hGB+HVyV4IR0f4hPtgmqRqD5VNfexpcE6JzPlyZ4bH7nbN3I5I392Ty b1s9+KMu9k4GWSupGH4lVwoumjce278b4ePnJmw== X-Google-Smtp-Source: AGHT+IGoQKi2BkPQ6szTmdYqlx2d8fzEwCrPUqvpv8t2ccXNM63BOiB8I2i8TCPErjOcnDB+0EPeS2DKXUV8AESPwlM= X-Received: by 2002:ac2:4ed9:0:b0:51a:f362:ab40 with SMTP id p25-20020ac24ed9000000b0051af362ab40mr443789lfr.2.1713900898322; Tue, 23 Apr 2024 12:34:58 -0700 (PDT) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 References: <202404181915.43IJFEoG020480@gitrepo.freebsd.org> In-Reply-To: From: Warner Losh Date: Tue, 23 Apr 2024 13:34:46 -0600 Message-ID: Subject: Re: git: 67783db661f8 - main - CONTRIBUTING: request only one submission type per change To: Gleb Smirnoff Cc: Lexi Winter , Ed Maste , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org, imp@freebsd.org Content-Type: multipart/alternative; boundary="00000000000039b3cd0616c8a614" 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:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4VPC4h4zkQz4flq --00000000000039b3cd0616c8a614 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 23, 2024 at 1:02=E2=80=AFPM Gleb Smirnoff = wrote: > Lexi, > > On Thu, Apr 18, 2024 at 08:27:56PM +0100, Lexi Winter wrote: > L> as a non-committer src contributor, i've discussed this with imp@ quit= e > L> a bit and i think this should be phrased more strongly in favour of > L> using GitHub for commits. > L> > L> the current situation is that Phabricator is useless for non-committer= s > L> because 1) you have to know who can review your commit, and 2) once yo= ur > L> commit is reviewed, someone has to commit it, and Phabricator doesn't > L> address this. > > The 1) is actually not as bad. Phabricator has subscribtion hooks, and > many > committers have rules installed to get notifications of new reviews that > touch certain paths of code. > Except we have really crappy coverage in phabricator from the herald rules, so external submitters usually don't even get a 'hey we got it' feedback from the submission.... networking gets good reviews, ports get decent reviews, some other select areas are OK... but on the whole, random submissions just disappear here. > The problem 2), IMHO, equally applies to github and Phabricator. > I can land a github PR in < 5 minutes. I can find all the open ones and make sure they are progressing. The tools to automate this are easy to write. I keep refining to reduce this time and push more automation into useful places. We've not even begun to explore what we can do in this space. With Phabricator, though, it's impossible to find things that are languishing, landing them is much harder, and there's no clear set of responsibility for doing something with it. Plus, Phorge doesn't really address these concerns... > L> i think it might make more sense to suggest that people submit all > L> patches via either GitHub or Bugzilla, and only use Phabricator if > L> specifically asked to. > > I don't agree here. Looks like we should address those phabricator > submissions that go unnoticed due to lack of maintainers of a code. > I don't think submitting same patch to github will improve visibility. > I've put a ton of energy into that... Good luck. I'm done trying because it's too hard. I can't even easily do a query for 'Find me all the stalled requests'. Or 'find all the ones I tagged as interesting' or half a dozen other things that are necessary to manage the queue. And lots of people (myself included) have been bad about closing out the stale requests, making the problem even worse. While specific queries can be written to address my concerns, they are so tightly focused that I can't refine them at all (since the criteria for selection isn't in the search interface). It's a mess, and not likely to get better. So until the "disappearing into phab" is fixed, we should concentrate on github pull requests. I've had good luck tagging the right people on github of late... and most of the submissions, frankly, don't require a lot more than a quick once-over to know if it's good or not. There are some that have languished, though, due to this lack... But I've learned to pull people in earlier in the process rather than letting it languish. So respectfully, I'd like to leverage the little bit of github pull request success we've had, reserve phabricator for the 'exception path' when something needs actual review from a developer who will take the responsibility to either commit or explicitly reject the phab review than to pin our hopes on making phabricator easier to use first. Warner --00000000000039b3cd0616c8a614 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Apr 23, 2024 at 1:02=E2=80=AF= PM Gleb Smirnoff <glebius@freebsd= .org> wrote:
=C2=A0 Lexi,

On Thu, Apr 18, 2024 at 08:27:56PM +0100, Lexi Winter wrote:
L> as a non-committer src contributor, i've discussed this with imp@= quite
L> a bit and i think this should be phrased more strongly in favour of L> using GitHub for commits.
L>
L> the current situation is that Phabricator is useless for non-committe= rs
L> because 1) you have to know who can review your commit, and 2) once y= our
L> commit is reviewed, someone has to commit it, and Phabricator doesn&#= 39;t
L> address this.

The 1) is actually not as bad.=C2=A0 Phabricator has subscribtion hooks, an= d many
committers have rules installed to get notifications of new reviews that touch certain paths of code.

Except we = have really crappy coverage in phabricator from the herald rules,
so external submitters usually don't even get a 'hey we got it'= ; feedback from
the submission.... networking gets good reviews, = ports get decent reviews,
some other select areas are OK... but o= n the whole, random submissions just
disappear here.
= =C2=A0
The problem 2), IMHO, equally applies to github and Phabricator.

I can land a github PR in < 5 minutes. I can f= ind all the open ones and
make sure they are progressing. The too= ls to automate this are easy
to write. I keep refining to reduce = this time and push more automation
into useful places. We've = not even begun to explore what we can
do in this space.

With Phabricator, though, it's impossible to find thing= s that are languishing,
landing them is much harder, and there= 9;s no clear set of responsibility
for doing something with it. P= lus, Phorge doesn't really address these
concerns...
=C2=A0
L> i think it might make more sense to suggest that people submit all L> patches via either GitHub or Bugzilla, and only use Phabricator if L> specifically asked to.

I don't agree here. Looks like we should address those phabricator
submissions that go unnoticed due to lack of maintainers of a code.
I don't think submitting same patch to github will improve visibility.<= br>

I've put a ton of energy into that.= .. Good luck. I'm done trying
because it's too hard. I ca= n't even easily do a query for 'Find me
all the stalled r= equests'. Or 'find all the ones I tagged as interesting'
<= div>or half a dozen other things that are necessary to manage the queue.
And lots of people (myself included) have been bad about closing
out the stale requests, making the problem even worse. While specif= ic
queries can be written to address my concerns, they are so tig= htly
focused that I can't refine them at all (since the crite= ria for selection
isn't in the search interface). It's a = mess, and not likely to get better.

So until the &= quot;disappearing into phab" is fixed, we should concentrate
on github pull requests. I've had good luck tagging the right people
on github of late... and most of the submissions, frankly, don'= ;t require
a lot more than a quick once-over to know if it's = good or not. There are
some that have languished, though, due to = this lack... But I've learned
to pull people in earlier in th= e process rather than letting it languish.

So resp= ectfully, I'd like to leverage the little bit of github pull request
success we've had, reserve phabricator for the 'exception p= ath' when
something needs actual review from a developer who = will take the
responsibility to either commit or explicitly rejec= t the phab review than
to pin our hopes on making phabricator eas= ier to use first.

Warner
--00000000000039b3cd0616c8a614--