On 2022/01/26 17:41, Damien Miller wrote: > On Fri, 21 Jan 2022, joshua stein wrote: > > > Using CVS and dealing with tarballs is probably pretty > > ancient-feeling for many outsiders. I don't know that more > > documentation is really the problem. > > > > I personally tend to ignore most ports@ emails that aren't diffs I > > can easily view in my e-mail client because it's a hassle to save > > the attachment, tar -t it to see what its directory structure is, > > untar it in the proper place, try to build it, then provide feedback > > by copying parts of the Makefile to an e-mail or doing some other > > work to produce a diff. > > > > Maybe we can do something radical like enable GitHub pull requests > > to let people submit changes against the ports repo on GitHub, do > > review and feedback on those on GitHub, and once it's been approved > > by a developer, that developer can do the final legwork of > > committing it to CVS and closing the pull request (since we can't > > commit directly to the Git repo). > > I'm late to the party (as usual), but we've been doing this for a while > in OpenSSH - we'll review pull requests on github and have one of the > developers do the final tidying and commit to CVS.
I can certainly see this working for some areas of OpenBSD. Especially more defined areas where primarily a smaller group of people handle most diffs going in, and where the mechanics of getting something committed account for a small part of the overall time taken to handle a submission. i.e. a higher % of the overall time is taken for review etc than with the mechanics of committing than is often the case for ports. In particular I think it's the case for OpenSSH where the vast majority of people using it are not OpenBSD users at all. > It's worked pretty well, and the quality of submissions is about as > good as we get from other outside sources. I believe it's allowed > a number of people who would otherwise not have contributed to do so, > since the tools are familiar and the hassle factor is so much lower. Ports by its nature needs domain-specific knowledge to successfully prepare an update. Nothing difficult, just some things to learn and do. Things like bumping revision numbers when changes are made, regenerating plists to pick up new files, looking for ABI changes in shared libraries, working on -current. In the context of that, putting the diff in an email rather than in a github PR isn't a high extra hurdle,
