It's not obvious to me these are necessary since the entire concept behind submitting an ebuild update is to, well, install and use it. My base assumption is that users submitting such an update have done so because it solved a problem for them.This covers 1, 2, and 3, unless the user has done some fairly heavily nonstandard things or submits effectively untested spam which admittedly might happen -- but the checkboxes don't seem the easiest way to solve this.
Well, not really, there were many cases where pkg was broken on sandbox! The latest example would be nim (before I updated it myself) where contributor submitted broken pkg without telling anybody. It was a WIP PR but nowhere they specified that it did not merge under sandbox. I want to encourage contributors to outright say when they know/think something might be wrong with package.
W dniu 1.05.2024 o 16:47, Eli Schwartz pisze:
On 5/1/24 10:27 AM, Maciej Barć wrote:Maybe we could consider also adding something along the lines (4 additional positions): 1. I have emerged the package(s) on a Gentoo-based system (be it "native" or virtualized by means of hardware-based virtualization or system layer virtualization). 2. I have tested that the package(s) merge inside both the user and net sandbox without violations on a Gentoo-based system. 3. I can assure that the packages would be able to be merged on the currently default Gentoo profile (with or without modifications to USE flags). 4. If manual intervention (beyond "emerge PKG") is required ro complete the install/update of the package(s) I have explained the steps needed to be taken in the PR and/or package ebuild(s) and/or Gentoo Wiki.It's not obvious to me these are necessary since the entire concept behind submitting an ebuild update is to, well, install and use it. My base assumption is that users submitting such an update have done so because it solved a problem for them. This covers 1, 2, and 3, unless the user has done some fairly heavily nonstandard things or submits effectively untested spam which admittedly might happen -- but the checkboxes don't seem the easiest way to solve this. 4 seems semantically wrong since it's not the job of a PR to describe what users should do to manually intervene to install a package, but IMHO this is already covered by 3. The only interesting case I can actually think of is where updating a package requires some sort of e.g. database migration to run after updating and before the next use -- this is the minority of packages and should be handled by a postinst message, but could also be reviewed on a case by case basis... It is *not* the job of a packager to ensure that the gentoo wiki excellently describes how to use the software, as that's a different skillset. I wouldn't want to discourage users from contributing code because they aren't skilled documentarians. The existing pull request template suggestion proposes to add checkboxes for 3 types of requirements that aren't necessarily obvious to users who had a problem, fixed it, and want to share the fix -- they are all about complying with Gentoo policy. Your 4 suggestions are all about requirements for fixing a problem and successfully fixing it even as a local ebuild. We don't need to remind people that the PR has to actually fix the problem.
-- Have a great day! ~ Maciej XGQT Barć https://wiki.gentoo.org/wiki/User:Xgqt 9B0A 4C5D 02A3 B43C 9D6F D6B1 14D7 4A1F 43A6 AC3C
OpenPGP_0x14D74A1F43A6AC3C.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
