Jonathan Perkin <jperkin%joyent.com@localhost> writes: > * On 2020-10-06 at 11:43 BST, Ottavio Caruso wrote: > >> I'm not a "quick fire PR" kind of guy, so I asked on IRC if it was worth >> sending a PR for these packages. The reply I got was (recalling from memory >> and paraphrasing): "if the package already shows up as failed in the bulk >> build logs AND you're not providing a patch, there's not much point >> submitting a PR". > > That was me, and yeh I think it's at best pointless, and at worst just > means a lot of busywork for volunteers to now read, handle, assign and > follow-up on the PR, reducing the time they have available to actually > fix problems. Plus the time for the 100+ people subscribed to the > pkgsrc-bugs list to read the mails for every update to it. > > Personally I find it annoying, as someone on the pkgsrc-bugs list, > when I have to spend time reading a PR only to find out it's just a > less useful version of a bulk build report that I've already seen, and > if I happen to go and fix the issue I now have extra work to also go > and find any PRs for that issue and close them too. Or the issue gets > fixed independently without the PR being closed, and 10 years later > someone is doing a GNATS cleanup and finally closes it, resulting in a > pretty terrible user experience all round. > > However I do know that other people disagree with me, and I hope they > will say speak up to say why. I basically agree with this. A key point is that there is no "development team" in terms of resources that can be tasked by managers to work on specific bugs, like you might find in a company environment. People work on what they want to work on, and that's usually some combination of packages they want to use on platforms they use, packages they care about on all platforms, or generally fixing things on a platform they care about. The number of people in pkgsrc who care about old versions of various OSes is pretty small. Generally we are happy to take fixes that don't cause other trouble and aren't really icky, but at some point it gets to be not broadly in the interests of pkgsrc and users. The other huge point about pkgsrc PRs is that people often expect pkgsrc to fix upstream problems, and this is IMHO not reasonable. So if a package doesn't build on your OS, first get the upstream source, and follow the upstream build insructions, and build it. If it doesn't work, file an issue with the upstream, not pkgsrc. If it does build from upstream, then you are already on the way to figuring out what's different in pkgsrc and a fix. At times I am inclined to demand that submitters build from upstream and then close the PR if they don't follow up. > The only piece of useful data is confirmation that there is a user out > there trying to use a particular package on a particular OS, and it > feels to me that we should have a much simpler way of recording this > than a full PR every time. It would certainly be nice if we had the > option of ordering bulk build results by popularity rather than by > dependency count. It would, but it also seems that as we get the big things under control more things show up. > Taken to its logical conclusion, I think we can all agree that a PR > for every failing package in bulk builds (i.e. thousands) would be > ridiculous, so one question is why would a smaller number be ok, and > at what point does it become ridiculous. Agreed. Overall I agree with "don't file PRs that basically duplicate a bulk results". And I would encourage Ottavio and others to try to fix failing packages. pkgsrc survives over the long term by turning users into developers.
Attachment:
signature.asc
Description: PGP signature