> 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