<story><title>Python moved to GitHub</title><url>https://github.com/python/cpython</url></story><parent_chain><item><author>ajdlinux</author><text>Everyone I know who has had to use Gerrit has &lt;i&gt;absolutely, utterly despised&lt;/i&gt; it.&lt;p&gt;Until I got a job working as a kernel developer I had never had to use emailed patches. It simply isn&amp;#x27;t an &amp;quot;absolutely necessary&amp;quot; skill for a good developer these days.&lt;p&gt;The kernel community is too attached to email patch submission for it to ever move away, and to be fair, email does have the benefit of being scalable and matches our decentralised workflow much better than any of the current alternatives.&lt;p&gt;But it&amp;#x27;s still not &lt;i&gt;good&lt;/i&gt;. There are plenty of ways to screw up email threading or forget conventions on labelling patchset versions or whatever (this happens &lt;i&gt;all the time&lt;/i&gt;). You have to rely on external tools such as Patchwork to provide a bare minimum of state-tracking. There&amp;#x27;s not much by way of generic CI tooling that&amp;#x27;s designed with email in mind (I&amp;#x27;m working on this!). Doing code review from an email client definitely has its benefits, but it&amp;#x27;s also limiting - web-based code review tools have much more scope for experimenting with better ways of presenting comments.&lt;p&gt;I can&amp;#x27;t see the Linux kernel ever moving away from email, and honestly it&amp;#x27;s not too bad once you&amp;#x27;ve figured out your workflow, but I would like to see kernel &lt;i&gt;hackers&lt;/i&gt; thinking about what it is that the kernel community loves so much about email compared to GitHub and other centralised services. It &lt;i&gt;is&lt;/i&gt; disappointing to see other large open source projects becoming incredibly dependent on a for-profit proprietary software company that may well not survive the next few years. How can we do proper decentralised version control and development &lt;i&gt;better&lt;/i&gt;?</text></item><item><author>ycmbntrthrwaway</author><text>Centralizing around proprietary software is not a good idea generally.&lt;p&gt;Git is distributed, so when GitHub goes down, every developer has a backup of entire history. However, issues are lost forever. Python does not use &amp;quot;issues&amp;quot; feature for good.&lt;p&gt;One way to avoid email without centralization is setting up Gerrit. That is how Ring [1] and LineageOS (former CyanogenMod) [2] manage their &amp;quot;pull requests&amp;quot;.&lt;p&gt;Still, being able to submit patches via email is an absolutely necessary skill for everyone who considers himself a hacker. Lack of it makes you unable to contribute to many great projects, such as all suckless [3] projects and Linux itself.&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;gerrit-ring.savoirfairelinux.com&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;gerrit-ring.savoirfairelinux.com&amp;#x2F;&lt;/a&gt;&lt;p&gt;[2] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;review.lineageos.org&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;review.lineageos.org&amp;#x2F;&lt;/a&gt;&lt;p&gt;[3] &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;suckless.org&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;suckless.org&amp;#x2F;&lt;/a&gt;</text></item><item><author>laurentdc</author><text>Yes!&lt;p&gt;I quite like the idea of &amp;quot;centralizing&amp;quot; development on GitHub, or similar services. It makes it much easier for everyone to fork, test, make a pull request, merge, etc..&lt;p&gt;For example, one reason why I gave up contributing to OpenWrt was their absolutely legacy contribution system [1], which required devs to submit code diff patches via email (good luck not messing up the formatting with a modern client) on a mailing list. It took me an hour to submit a patch for three lines of code. It seems like Python wasn&amp;#x27;t much different. [2]&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;dev.openwrt.org&amp;#x2F;wiki&amp;#x2F;SubmittingPatches#a1.Creatingapatch&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;dev.openwrt.org&amp;#x2F;wiki&amp;#x2F;SubmittingPatches#a1.Creatingap...&lt;/a&gt;&lt;p&gt;[2] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;docs.python.org&amp;#x2F;devguide&amp;#x2F;patch.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;docs.python.org&amp;#x2F;devguide&amp;#x2F;patch.html&lt;/a&gt;</text></item></parent_chain><comment><author>mugsie</author><text>Sure, gerrit has a learning curve.&lt;p&gt;When you end up using it for a long time, going back to pull requests is awful.&lt;p&gt;Its basic things:&lt;p&gt;- history of a PR - I cannot see the diff of last version of the patch and latest&lt;p&gt;- dependant changes - I need to do some work that depends on a patch someone else is working on. This can&amp;#x27;t be done in github.&lt;p&gt;- clean history  - no &amp;quot;added tests&amp;quot;, &amp;quot;fixed docs typo&amp;quot; etc commits&lt;p&gt;I learnt recently that most people don&amp;#x27;t use git-review[0] - and yeah, if you are manually doing the &amp;quot;git push gerrit ref&amp;#x2F;for&amp;#x2F;master&amp;quot; crap, it&amp;#x27;s really annoying. but git review and repo were written to help that.&lt;p&gt;0 - &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;docs.openstack.org&amp;#x2F;infra&amp;#x2F;git-review&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;docs.openstack.org&amp;#x2F;infra&amp;#x2F;git-review&amp;#x2F;&lt;/a&gt;</text></comment>
<story><title>Python moved to GitHub</title><url>https://github.com/python/cpython</url></story><parent_chain><item><author>ajdlinux</author><text>Everyone I know who has had to use Gerrit has &lt;i&gt;absolutely, utterly despised&lt;/i&gt; it.&lt;p&gt;Until I got a job working as a kernel developer I had never had to use emailed patches. It simply isn&amp;#x27;t an &amp;quot;absolutely necessary&amp;quot; skill for a good developer these days.&lt;p&gt;The kernel community is too attached to email patch submission for it to ever move away, and to be fair, email does have the benefit of being scalable and matches our decentralised workflow much better than any of the current alternatives.&lt;p&gt;But it&amp;#x27;s still not &lt;i&gt;good&lt;/i&gt;. There are plenty of ways to screw up email threading or forget conventions on labelling patchset versions or whatever (this happens &lt;i&gt;all the time&lt;/i&gt;). You have to rely on external tools such as Patchwork to provide a bare minimum of state-tracking. There&amp;#x27;s not much by way of generic CI tooling that&amp;#x27;s designed with email in mind (I&amp;#x27;m working on this!). Doing code review from an email client definitely has its benefits, but it&amp;#x27;s also limiting - web-based code review tools have much more scope for experimenting with better ways of presenting comments.&lt;p&gt;I can&amp;#x27;t see the Linux kernel ever moving away from email, and honestly it&amp;#x27;s not too bad once you&amp;#x27;ve figured out your workflow, but I would like to see kernel &lt;i&gt;hackers&lt;/i&gt; thinking about what it is that the kernel community loves so much about email compared to GitHub and other centralised services. It &lt;i&gt;is&lt;/i&gt; disappointing to see other large open source projects becoming incredibly dependent on a for-profit proprietary software company that may well not survive the next few years. How can we do proper decentralised version control and development &lt;i&gt;better&lt;/i&gt;?</text></item><item><author>ycmbntrthrwaway</author><text>Centralizing around proprietary software is not a good idea generally.&lt;p&gt;Git is distributed, so when GitHub goes down, every developer has a backup of entire history. However, issues are lost forever. Python does not use &amp;quot;issues&amp;quot; feature for good.&lt;p&gt;One way to avoid email without centralization is setting up Gerrit. That is how Ring [1] and LineageOS (former CyanogenMod) [2] manage their &amp;quot;pull requests&amp;quot;.&lt;p&gt;Still, being able to submit patches via email is an absolutely necessary skill for everyone who considers himself a hacker. Lack of it makes you unable to contribute to many great projects, such as all suckless [3] projects and Linux itself.&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;gerrit-ring.savoirfairelinux.com&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;gerrit-ring.savoirfairelinux.com&amp;#x2F;&lt;/a&gt;&lt;p&gt;[2] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;review.lineageos.org&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;review.lineageos.org&amp;#x2F;&lt;/a&gt;&lt;p&gt;[3] &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;suckless.org&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;suckless.org&amp;#x2F;&lt;/a&gt;</text></item><item><author>laurentdc</author><text>Yes!&lt;p&gt;I quite like the idea of &amp;quot;centralizing&amp;quot; development on GitHub, or similar services. It makes it much easier for everyone to fork, test, make a pull request, merge, etc..&lt;p&gt;For example, one reason why I gave up contributing to OpenWrt was their absolutely legacy contribution system [1], which required devs to submit code diff patches via email (good luck not messing up the formatting with a modern client) on a mailing list. It took me an hour to submit a patch for three lines of code. It seems like Python wasn&amp;#x27;t much different. [2]&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;dev.openwrt.org&amp;#x2F;wiki&amp;#x2F;SubmittingPatches#a1.Creatingapatch&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;dev.openwrt.org&amp;#x2F;wiki&amp;#x2F;SubmittingPatches#a1.Creatingap...&lt;/a&gt;&lt;p&gt;[2] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;docs.python.org&amp;#x2F;devguide&amp;#x2F;patch.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;docs.python.org&amp;#x2F;devguide&amp;#x2F;patch.html&lt;/a&gt;</text></item></parent_chain><comment><author>rando832</author><text>I used gerrit and did not utterly despised it. Hi.</text></comment>