On 9/24/20 5:32 AM, Christian Zietz wrote:
Larry,
I'm all for contributing changes back to the community. I'm a maintainer of multiple open-source SW projects, too.
However, the feedback I got to my first email when I courteously wanted to discuss possible changes was only negative:
- The NanoVNA is an inexpensive device, so I should not expect it to implement the time domain like a R&S/Keysight VNA would do.
- It's not of interest to many users.
- It should not be done in firmware for code size reasons.
All valid comments for one reason or another. Many folks do ask for improved functionality, and the relatively few people actively developing for the box as volunteers can easily feel like they're responding to customers, not colleagues. It's an open forum, not everyone is tactful <grin>
That's sort of different from saying "hey, *I* am willing to implement the changes".
Maybe I'm misreading the emails but to me that's not the warmest of welcomes to someone new to the forum, either. This leads me to the question whether contributing my changes (via pull request) would only result in similar negativity/disinterest. So, why should I try it, then?
I think you should ask the owners of the various repos (perhaps offline) how they'd like to do it.
It *might* be that you wind up forking, and publishing your own repo. Then, at some later time, yours could be pulled in with one of the others, or you could wind up being a major source.
I'll just add there's a bit of history here too - there are, as in all online communities, differences in development methodology especially with distribution of trial executable versions vs publishing source tree updates. And, as well, some strongly held and not necessarily tactfully expressed opinions about such things, well beyond whether vi or emacs is the one true editor.
Bear in mind that not everyone is comfortable with collaborative multideveloper work on a code base where multiple people are making changes and submitting back on a continuing basis. It does require a somewhat different style of working than cloning a repo and developing as a separate fork, single handedly. I suspect that the existing developers of firmware for the NanoVNA are used to "single developer, single tree" monolithic development. In such environments, you'll never worry about whether diff worked right, or resolving repo hiccups. It's just a directory full of code.
Give it a shot - pick a repo from the three (I think there's three) as your base and go for it.
