Date: Sat, 25 Feb 2023 16:54:26 -0700 From: Warner Losh <imp@bsdimp.com> To: freebsd-git <freebsd-git@freebsd.org> Subject: Report on the pull request experiment so far Message-ID: <CANCZdfoOm3iWZHvh6oy4Cj6qpcvnHjAWpbvNp7r9msfwO_r5fg@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
--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 <div dir=3D"ltr"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Second, I'm preparing an updat= e to create CONTRIBUTING.md. See <a href=3D"https://reviews.freebsd.org/D38= 771" rel=3D"noreferrer" target=3D"_blank">https://reviews.freebsd.org/D3877= 1</a> 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.</div><div><br></div><div>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.</div><div><br></div><div>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'.</d= iv><div><br></div><div>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.</div><div><br></div><div>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.</div>= <div><br></div><div>Anyway, that's all for now.</div><div><br></div><di= v>Warner<br></div></div> --000000000000bf108605f58ef721--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoOm3iWZHvh6oy4Cj6qpcvnHjAWpbvNp7r9msfwO_r5fg>