<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 20, 2021 at 4:51 PM Dan Smith via chirp_devel <<a href="mailto:chirp_devel@intrepid.danplanet.com">chirp_devel@intrepid.danplanet.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
This is assuming we're going to move to github, which is at least not a plan currently. I personally don't like github, and there are several developers here comfortable with the mercurial process and who have contributions to chirp that outweigh a lot of perceived benefit of moving to a "new" platform. Of course I'm 100% git in my day job outside of chirp, but I don't want to screw over the existing contributors. I also definitely do not want to have the github page be the thing that "regular" users find or try to file bugs against.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">The world has moved to Git. Today there are *far* more developers who are familiar with Git than are familiar with Mercurial. Bitbucket started life as a Mercurial-only service, added Git 3 years later, and last year dropped support for Mercurial entirely. As for Chirp, I would hazard a guess that a significant proportion of the small number of contributors learned Mercurial just so they could contribute to Chirp. I know I did. I would hazard a further guess that many more people are likely to contribute to a Git-based project, and simply aren't willing to learn another source control system just to help out with Chirp. So if you want more help with Chirp, you're much more likely to get it if it's a Git project than if it continues with a dying SCM that people don't want to learn.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I'd be interested in hearing your objections to GitHub. In my experience with a significant number of projects, the pull request mechanism has no equal elsewhere, and makes it easy for a lot of people to contribute, even if they only contribute small changes, and for the project maintainers to apply those changes easily and with excellent tracking. The ability for project maintainers to comment on a pull request, and request additional changes, which can then be made to the same updated pull request, really helps track threads of change. Much better than "please make these changes to your patch and submit another one" via e-mail. GitHub also has great built-in support for Continuous Integration, and with minimal effort, users can see the status of the latest builds and tests at a glance on the repo home page. If there are features that you don't like - you mention the issue tracker - then you don't need to use them. Most of them are optional. The Python project itself is a great example of using GitHub to great effect without buying into the issue tracker, wiki, etc.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><a href="https://github.com/python/cpython">https://github.com/python/cpython</a><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">That said, Git doesn't have to mean GitHub. As someone else has already mentioned, there are alternatives such as Bitbucket, GitLab, or even self-hosted Git. (This last, though, can take significant work to harden, security-wise - just ask the PHP folks, who have now moved to GitHub after their self-hosted repo was hacked).</div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This is easy to say, but it's just not that simple. We can't stop chirp development for two years while we completely rewrite the GUI (again?) and sort out the immense number of unicode/bytes violations in all the drivers. So, we have to be able to keep releasing on python2 from the main branch while we get something on python3 close to ready - at least close enough to be able to replace the current distribution for most people.</blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">But this is not what's happening today. The py3 branch is languishing while development continues on trunk. Very little work is happening on the py3 branch, so it is falling further and further behind. You may not want to stop development for two years to rewrite things, but the py3 branch has already been sitting for two years, almost untouched over that period. Even if the py3 branch is progressed to a working state in its current form, the task of merging in all the changes from trunk is going to be massive. And only then will Chirp be at the point that you can have Py2 & Py3 building out of the same tree.</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Especially since (almost) nobody other than myself ever works on the GUI, it's just a huge disincentive to go in that direction at all, IMHO. The py3 branch was being sync'd from the default branch regularly while I was working on it, which wasn't too terrible, but it's definitely work and it's hard to get casual contributors to make sure things work on both for submissions. Rick probably wants to strangle me (more than usual) right now.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I really do believe that you're going to get many more people willing to contribute to a Git project than a Mercurial project. You're certainly more likely to find more GUI developers that way. I also believe that a pure Py3 version is likely to gain more traction with contributors than one where people have to futz around with all the Py2/Py3 compatibility cruft in full knowledge that it's all in service of supporting an obsolete version of the language. There is so much good stuff in Py3, and so much that could benefit Chirp, that it really hobbles the project - and the experience of contributors - to require the use of a compatibility layer to support (develop, build, test) both. (On a personal note, I was quite interested in working on the py3 branch until I discovered all of the compatibility cruft, at which point I lost interest entirely.)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Martin.</div><div class="gmail_default" style="font-size:small">KD6YAM</div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I definitely agree that the various trees that have sprung up with no history is causing confusion, and I really don't want to see that as I think it benefits nobody. I guess if it would help for me to create a master github clone that tracks the mercurial tree (at least for a while) I can do that, but I don't want to orphan the people that actually contribute via the current process for several people that have made a couple tweaks via github. No offense. Hopefully at least that would create a stake in the ground for the "official" chirp git tree, with history, and then we can see if the heavy contributors here are comfortable moving to that.<br>
<br>
--Dan<br>
_______________________________________________<br>
chirp_devel mailing list<br>
<a href="mailto:chirp_devel@intrepid.danplanet.com" target="_blank">chirp_devel@intrepid.danplanet.com</a><br>
<a href="http://intrepid.danplanet.com/mailman/listinfo/chirp_devel" rel="noreferrer" target="_blank">http://intrepid.danplanet.com/mailman/listinfo/chirp_devel</a><br>
Developer docs: <a href="http://chirp.danplanet.com/projects/chirp/wiki/Developers" rel="noreferrer" target="_blank">http://chirp.danplanet.com/projects/chirp/wiki/Developers</a><br>
</blockquote></div></div>