<p dir="ltr"><br>
</p>
<blockquote><blockquote><p dir="ltr">On 11 Oct 2015, at 14:48, John Crispin <<a href="mailto:blogic@openwrt.org">blogic@openwrt.org</a>> wrote:<br></p>
<p dir="ltr">patches will linger in mailing list until someone has time to look at<br>
them. the version control system used is completely irrelevant<br>
</p>
</blockquote>
</blockquote>
<blockquote><p dir="ltr"></p>
<p dir="ltr">Which is true enough if the switch just encompasses moving to another VCS. However, what has not been made explicit enough is that switching to git _and_ a git web interface like Github/Gitlab may make it easier to contribute. My understanding is that it would be much easier to test proposed changes as people can simply do a checkout on a pull request and run the proposed code. Currently (unless I am missing something which is unfortunately quite possible), one would have to manually insert the patches to test.<br></p>
<p dir="ltr">Someone said earlier that switching to github for the packages made a positive difference in contributions. I would like to see that supported by some numbers, or possibly a contributor can elaborate a bit on the process and whether they perceive any benefits. That way, the migration of the packages might show a practical use case in the context of this project and its workflows.</p>
</blockquote>
<blockquote><p dir="ltr"><br></p>
<p dir="ltr">I can comment on this last question.  I maintain fwknop, and before the move of the third party packages to github, I had major issues trying to get my patches committed.  The thing that was most frustrating is that I was the maintainer for the package, and my patches that only touched that package were not committed.  It was bad enough that I actually gave up and wasn't doing anything related to OpenWrt development for over a year.</p>
<p dir="ltr">When the packages feed moved to github, I decided to come back and try pushing patches again.  The experience has been much better.  I've had 24 hour turnarounds for many pull requests.  I think there are several factors that led to such an improvement.  One is the easy interface to see changes and the ability for someone with commit access to accept them so trivially.  Expanding who has commit access to that repository has helped as well.</p>
<p dir="ltr">Another big problem we see quite often is mangled patches in emails.  If trivial patches could be pull requests instead of emails, it would lower the noise level of mangled patches, and help new committers get their patches in with less frustration.</p>
<p dir="ltr">Realistically, I think it's obvious that at some point we will have to move away from SVN, if only because so many other projects are also doing so.  Because of the mass exodus from SVN, it seems destined to become legacy and eventually unmaintained.  The sooner we commit to transitioning to git, and start that transition, the easier it will be in the long run.</p>
<p dir="ltr">This brings another question to mind.  If we move to github/gitlab, do we want to do bug tracking there as well, and retire trac altogether?</p>
<p dir="ltr">--Jonathan Bennett</p>
</blockquote>
<blockquote><p dir="ltr"><br>
</p>
</blockquote>
<p dir="ltr"><br>
</p>