Re:Non-official site with a tampered version of KeePass
by mehrdadn on Friday July 27, 2018 @02:23PM
(#17627983)
I assure you I'm not naively just dumping code on random developers and telling them to merge it. I do talk to them first, that's exactly how I figure out they think their code is fine and my changes are unwelcome whenever that's the case. (Edit: Well, mostly. It's also happened that my changes were rejected after I made the patch, but that was nevertheless after discussions had already taken place. Like when I said they later decide the patch is too big.) And regarding the upstream project issue: in the case I had in mind, the upstream project had its own reasons for not doing things the way I mentioned. The changes really did belong in the downstream project, but the downstream guy just didn't care to have to maintain the changes. Although, I also have to point out that upstream projects tend to present even more obstacles for merging code -- not only when the entire reason there's a downstream fork is that upstream is not going to support the entire platform/architecture/whatever, but also when they're big projects with their own hoops I don't care to jump through on my end as I explained earlier.
Then you're not going to the good people. Stop going through intermediaries, go straight for the source (package specific issues on Ubuntu must be reported to Ubuntu -like python not recognizing a new module-, but bad code inside the package must be dealt with with upstream).
> Half the time the developers are extremely resistant to changes and believe the change is wrong/unnecessary, or the current state is already correct, or that the changes are too big and/or not worth it, [...]
That's why I take the habit of jumping on IRC first, talking with devs a bit and trying to understand why I find a specific piece of code problematic.
I was trying to add support for i686 on an AUR package I maintain; quickly dismissed "we don't support i686 anymore anyway, just slap comments in your PKGBUILD and ship it".
I was working with the btrfs(8) util, which has the most horrific interface ever designed; "OK, we're not hostile to a new interface design, but you'll have to provide a comprehensive explanation of what you want and how it should behave".
And finally, documentation usually gets merged real fast (recently on cbsd(8) and nextcloud).[0][1]
[0] https://github.com/nextcloud/documentation/pull/826
[1] https://github.com/cbsd/cbsd-wwwdoc/pull/12