On Fri, Dec 11, 2020 at 12:07:57AM +0000, max porter wrote: > Hi, > > Sorry for resending this, apparently the list didn't like my primary email > address and the message got encoded. Resending to max it easier for everyone. > > I don't use OpenBSD but a friend asked for help since they do. They saw a > patch for Ansible which will help them manage their systems from other OS, > but it wasn't in Ansible itself. They told me they asked the maintainer (who > has an openbsd.org email) about it and got the following quote after some > discussion (if there is somewhere they should forward the original I can pass > it along): > > "If somebody starts telling me that I must do something because they just > decided so, I don't care if is it bad education, stupidity or mental illness. > " > > But it looks like the policy here > https://www.openbsd.org/faq/ports/guide.html#PortsPolicy suggests this patch > should have been shared, but was not. I went ahead and opened a PR > (https://github.com/ansible/ansible/pull/72937) and pinged the maintainer for > their feedback in case I missed something.
the policy might need to be reworded. In all case, you must remember that people working on openbsd mostly do it on their own free time, and because it's fun, or technically interesting, everyone has its own reasons. generally, it's nice to send upstream patches which make sense to be upstreamed (*not* the ones which are openbsd-specific, changing paths, defaults, etc..) - in the case of this rcctl ansible patch, yes it makes sense. the 'good way of doing this' is first contacting the maintainer, asking him (nicely) if he plans to upstream patch, if there's a particular reason some patches arent upstreamed (for reasons maybe only he knows, not everyone adds notes to patches), and then offer your help for upstreaming, as you more or less did. you open a PR upstream, which is fine. but in the PR you tell upstream developers to contact the openbsd developer who worked on this patch for more questions, who already told your friend he's nobody to tell him what he has to do. at that point you started it, so *YOU* need to be in charge of the upstreaming, replying to questions from upstream etc. redirecting upstream developers to the maintainer, potentially putting more work on him, is definitely not nice. Landry