From nobody Sat Feb 4 18:12:34 2023 X-Original-To: freebsd-git@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 4P8LGY5nNGz3nhLH for ; Sat, 4 Feb 2023 18:12:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 4P8LGX6Hw0z3Cgn for ; Sat, 4 Feb 2023 18:12:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=T9XIrBZE; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::535) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ed1-x535.google.com with SMTP id v10so7998456edi.8 for ; Sat, 04 Feb 2023 10:12:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AUXBxQldnHVfmYyxrUC9M+C/KnAd14aroNUHAowO4yI=; b=T9XIrBZE09ZdwcS2hS2qLRFsMH/E/26o6Wq9yngmGuP+7pBs6q67q4HbZO2pua7Wp1 SDbGy8XItUWHbOvGK34VeFMfKDqDMmROnKNSAUrIUZt6Mi04iiFRjDKhBD+WWh2Z8snl IAvI7Npu9yn148UnYUblNYPbo76H21NLHQns9bJAgbKr6dSSWhsNSb5NMHWpI9bKjNJU y2TcXRP42E5O7Kmm6eZoXWHYNIiscjQ4uK0g744T3r5S4gY3kX/vYFpjC1vTRozc1q6p 6unjygrOA2N9QGE8ZjejvqtsgJ/xoKwbiGqvnLkNJgkuyCLPzDf+ahw4sJrxZ2/Yv7Vu JIng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=AUXBxQldnHVfmYyxrUC9M+C/KnAd14aroNUHAowO4yI=; b=P4VBqk/RTyXoi7CLhhn6a6X4pLD+7WGOKuwllPJkM911A9nCdCB+bUnSOSDUiU/RYp m4P4kS0wXxo28hrOixup2jOR1Hs+6oygas05D6vdrXOmEQCokdHka7asu7vnavAArWjk 8IU5YRoWRlGVsBrZRYOy3ov28HkZpBJyYlRLjoETYd4UnPJZnHBgkV+fbE0R++uxVonK I0+jf1YNS/8ZSSdj/G+l4W4jI4S6kHgbR9eDs6RQM2M2hAeo1FOeOO3Zy5SsSsbzp5Tx pKNsYAKkFktRl4L4RCeYB48dSEPLzmib1Cy+pL2eH0xZyqgffvaWpGGTAZDtI1hHwS1m uwsg== X-Gm-Message-State: AO0yUKUEQcZS+Rs5hokuSrDp0ak2pvA7v3DUJkAs9bJ70X4rGyeriz90 1QY9ygxlL6ioYWqVy8/rtR00VxiAKa5rxP2bVySZM0KYmMzv/enw X-Google-Smtp-Source: AK7set973UYBtytWqZnhOOVl9DjjeZyY9Q6VMDsGIIMmesKzqmdRyaJ275aSJ2gGkByqC8wJKiaxZnBhaSuotzfPX3w= X-Received: by 2002:a05:6402:2489:b0:4a0:f071:3656 with SMTP id q9-20020a056402248900b004a0f0713656mr4550852eda.81.1675534355219; Sat, 04 Feb 2023 10:12:35 -0800 (PST) List-Id: Discussion of git use in the FreeBSD project List-Archive: https://lists.freebsd.org/archives/freebsd-git List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-git@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sat, 4 Feb 2023 11:12:34 -0700 Message-ID: Subject: Re: Proposed Github Pull Request Policy To: Brooks Davis Cc: freebsd-git Content-Type: multipart/alternative; boundary="0000000000000d60ef05f3e3bee9" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-git@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::535:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; PREVIOUSLY_DELIVERED(0.00)[freebsd-git@freebsd.org]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[bsdimp.com]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-Rspamd-Queue-Id: 4P8LGX6Hw0z3Cgn X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --0000000000000d60ef05f3e3bee9 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 3, 2023 at 9:42 AM Brooks Davis wrote: > On Thu, Feb 02, 2023 at 07:12:29PM -0700, Warner Losh wrote: > > Geetngs, > > > > I'd like to put some parameters around the pull requests on github. To > that > > end, I'd like us to consider the following policy: > > This seems like a good start. > > > Pull requests shouldn't expand in scope in response to feedback: If the > > feedback suggests a new series of changes, please create a new pull > > requests. > > I think I'd prefer: "Pull requests shouldn't expand in scope once > created:...". > > Some direction on using rebase and forced push when addressing feedback is > probably also in order. If I'm taking a few minutes to look at a PR that > caught my eye I don't want to wade through a bunch of fixups. > I've written this up as https://reviews.freebsd.org/D38382 which I'm open to feedback on. Especially other areas of the docs that need to be fixed to be consistent. Warner --0000000000000d60ef05f3e3bee9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Feb 3, 2023 at 9:42 AM Brooks= Davis <brooks@freebsd.org>= wrote:
On Thu, = Feb 02, 2023 at 07:12:29PM -0700, Warner Losh wrote:
> Geetngs,
>
> I'd like to put some parameters around the pull requests on github= . To that
> end, I'd like us to consider the following policy:

This seems like a good start.

> Pull requests shouldn't expand in scope in response to feedback: I= f the
> feedback suggests a new series of changes, please create a new pull > requests.

I think I'd prefer: "Pull requests shouldn't expand in scope o= nce
created:...".

Some direction on using rebase and forced push when addressing feedback is<= br> probably also in order.=C2=A0 If I'm taking a few minutes to look at a = PR that
caught my eye I don't want to wade through a bunch of fixups.

I've written this up as https://reviews.freebsd.org/D38382 which I&#= 39;m open to feedback on. Especially other areas of the docs that need to b= e fixed to be consistent.

Warner
<= /div> --0000000000000d60ef05f3e3bee9-- From nobody Sat Feb 25 23:54:26 2023 X-Original-To: freebsd-git@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 4PPNsV1Xwvz3v2RV for ; Sat, 25 Feb 2023 23:54:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 4PPNsT1sHLz3CHp for ; Sat, 25 Feb 2023 23:54:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=wVf1WtN+; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::532) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ed1-x532.google.com with SMTP id f13so11726928edz.6 for ; Sat, 25 Feb 2023 15:54:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=mESGeI5/OWKwKPrHT7AnkjJrWiEH/j731mYX0Hkt3BM=; b=wVf1WtN+TL1msBWmA4NZhP3m8Oxo+NxmvqOaKT6h8DWhuCZJSJXFpGPg1b6joTz2kU XVWOuSLqYn0awYylo4zjASkyyz3D9YwS9tV8bqfITCEeZdlW/b7C3y70aLXFpSFhzPSh 1+2pDPSXBJcZ63hhAM8eb/0dYVwW4ICWWD95wWlwvhqmUJTLtWKZH11xG5T/JpyMJc7K v2hfZee5Pd85U0mQMKKjazvpq8Sj1vo9mqNctVCYYNcLUL7E9EIgpboGnJFiZ9X3wWUM tK2I3u7LCSWS2gWD4tL60bfEl++73ApQfaBduFv/Y31FiH8UjkSmBv53u0l/MPNo1ZtZ 50wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=mESGeI5/OWKwKPrHT7AnkjJrWiEH/j731mYX0Hkt3BM=; b=zc3/GKDH538cxoYol2vCBrHE6iG4QMNUwKKoiUu+wHBjmSYS3P0ErUTK8a9RyONh93 y6lXUF+sKIpiFYAnX1UDg9kJ9EQ6ywAq+V6mKM1sF4ZPTKaHEE9S28gFFFFah4ZF+f/c BI2m34bMHAk9g7ELD3xwx+XG0xDGIkYe6gi8tx+6txMwKv/OCYLZ9Zg7wkQuATWPjxI2 yQfAkvjJwZh83NWodM4fJh4PUP010sETAOW3yA0xR8g4zQkjE9Q3zJzAf6FVQPtFYkgw vehM9W3O6AJhYYqkDAv9lB+0MiorCEr9zuFbUdJwFQh4pJLizd9izcXqg7vlMvxQ2gvf 6/lg== X-Gm-Message-State: AO0yUKXcCMuhFqWVYyU1w4qUtDzzVU8RC+lfCeRu25d0vrBvgT0eK7Jy By07lsf7sw9AL/0g40a/1jwn/vk/+cZ9eim1Y9Hma4QsjW6V2Xsx X-Google-Smtp-Source: AK7set81AXba8ZvA+r9GmvNgXU0cD0oYJnDXEjwAyKk6WWVAaaR2d8T5bBWV4N6kid4C/jg9WuUcF6r/aESX0mKLF04= X-Received: by 2002:a50:d086:0:b0:4ad:72b2:cf57 with SMTP id v6-20020a50d086000000b004ad72b2cf57mr9726009edd.0.1677369274203; Sat, 25 Feb 2023 15:54:34 -0800 (PST) List-Id: Discussion of git use in the FreeBSD project List-Archive: https://lists.freebsd.org/archives/freebsd-git List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-git@freebsd.org MIME-Version: 1.0 From: Warner Losh Date: Sat, 25 Feb 2023 16:54:26 -0700 Message-ID: Subject: Report on the pull request experiment so far To: freebsd-git Content-Type: multipart/alternative; boundary="000000000000bf108605f58ef721" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::532:from]; MLMMJ_DEST(0.00)[freebsd-git@freebsd.org]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-git@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4PPNsT1sHLz3CHp X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --000000000000bf108605f58ef721 Content-Type: text/plain; charset="UTF-8" Recently, I committed changes to our handbook that suggested submitting a pull request for simple changes. Since then, we've had about 30 pull requests opened. Here's some lesions that I've learned. First, I've tried to script things so that we have the right tagging so that pull requests notice when the changes are made. I've discovered that git has a way to add these things automatically. git commit --amend --trailer... will do that. However, it assumes a strict RFC822 format, which means 'Reviewed-by:' is valid, but 'Reviewed by:' is not. I can cope with this by some pre/post processing, but it suggests that the project may want to alter its practices. I'd recommended this originally in the git cutover, but could not point to a good reason to do that. Now I can point to a good reason: git supports it a lot better. Second, I'm preparing an update to create CONTRIBUTING.md. See https://reviews.freebsd.org/D38771 for the review. The only thing so far I'm unsure of is whether I should place it in .github or not. We're not planning on doing anything with gitlab at the moment, so I think it's OK at the top level. We can move it whenever. We're getting a mixed bag of changes, which has influenced the CONTRIBUTING. Some are decent bug fixes, while others are some variation on style changes. I think we'll want to discourage it generally, but accept it when someone is about to do work in some area. Otherwise we'll be spending a lot of time on low-value changes. I can understand it is useful to 'train' on, and I'm willing to put up with some level of it, but I don't want to have lots and lots of things here. A balancing act. Next, we've had three or four new people pop up, which is cool. We'll see if they will contribute long term. They are still in the small, useful but also not super high value range. And that's fine: lots of these changes are good incremental changes that didn't take me long to land. So we'll need to find some way to nurture this, and we'll likely need a 'how to land a pull request and grow new contributors into regular contributors' section in our handbook. Hopefully the how to land part soon will be 'land with this script, and it takes care of all the details'. I also landed one commit that was from 2021. Yikes. The commit date is right, but the author date is in the past. I suggest that we add a git commit --amend --date="`date`" to the process. This likely is a good thing. There's no simple --reset-date, alas: only a reset that also resets the author. Finally, I've rebranded our github description. It is now a 'publish only repo' that we 'process pull requests from' which conveys that it's more active than just a 'read-only mirror'. I got that language from git's description and used it because I liked it. I'm open to feedback on this for ways to make it better. I've wanted to get away from the very passive, 'read-only mirror' description for a while because you can push things to github and have things happen based on it. Anyway, that's all for now. Warner --000000000000bf108605f58ef721 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Recently, I committed changes to our handbook that su= ggested submitting a pull request for simple changes. Since then, we've= had about 30 pull requests opened. Here's some lesions that I've l= earned.

First, I've tried to script things so = that we have the right tagging so that pull requests notice when the change= s are made. I've discovered that git has a way to add these things auto= matically. git commit --amend --trailer... will do that. However, it assume= s a strict RFC822 format, which means 'Reviewed-by:' is valid, but = 'Reviewed by:' is not. I can cope with this by some pre/post proces= sing, but it suggests that the project may want to alter its practices. I&#= 39;d recommended this originally in the git cutover, but could not point to= a good reason to do that. Now I can point to a good reason: git supports i= t a lot better.

Second, I'm preparing an updat= e to create CONTRIBUTING.md. See https://reviews.freebsd.org/D3877= 1 for the review. The only thing so far I'm unsure of is whether I = should place it in .github or not. We're not planning on doing anything= with gitlab at the moment, so I think it's OK at the top level. We can= move it whenever.

We're getting a mixed bag o= f changes, which has influenced the CONTRIBUTING. Some are decent bug fixes= , while others are some variation on style changes. I think we'll want = to discourage it generally, but accept it when someone is about to do work = in some area. Otherwise we'll be spending a lot of time on low-value ch= anges. I can understand it is useful to 'train' on, and I'm wil= ling to put up with some level of it, but I don't want to have lots and= lots of things here. A balancing act.

Next, we= 9;ve had three or four new people pop up, which is cool. We'll see if t= hey will contribute long term. They are still in the small, useful but also= not super high value range. And that's fine: lots of these changes are= good incremental changes that didn't take me long to land. So we'l= l need to find some way to nurture this, and we'll likely need a 'h= ow to land a pull request and grow new contributors into regular contributo= rs' section in our handbook. Hopefully the how to land part soon will b= e 'land with this script, and it takes care of all the details'.

I also landed one commit that was from 2021. Yikes. = The commit date is right, but the author date is in the past. I suggest tha= t we add a git commit --amend --date=3D"`date`" to the process. T= his likely is a good thing. There's no simple --reset-date, alas: only = a reset that also resets the author.

Finally, I= 9;ve rebranded our github description. It is now a 'publish only repo&#= 39; that we 'process pull requests from' which conveys that it'= s more active than just a 'read-only mirror'. I got that language f= rom git's description and used it because I liked it. I'm open to f= eedback on this for ways to make it better. I've wanted to get away fro= m the very passive, 'read-only mirror' description for a while beca= use you can push things to github and have things happen based on it.
=

Anyway, that's all for now.

Warner
--000000000000bf108605f58ef721--