On Sun Nov 30 2014 at 10:55:26 AM Ian Cordasco <graffatcolmin...@gmail.com> wrote:
> On Sun, Nov 30, 2014 at 7:01 AM, Antoine Pitrou <solip...@pitrou.net> > wrote: > > On Sun, 30 Nov 2014 16:23:08 +1100 > > Chris Angelico <ros...@gmail.com> wrote: > >> > >> Yes, GitHub is proprietary. But all of your actual code is stored in > >> git, which is free, and it's easy to push that to a new host somewhere > >> else, or create your own host. This proposal is for repositories that > >> don't need much in the way of issue trackers etc, so shifting away > >> from GitHub shouldn't demand anything beyond moving the repos > >> themselves. > > > > I hope we're not proposing to move the issue trackers to github, > > otherwise I'm -1 on this PEP. > > > > Regards > > > > Antoine. > > So I usually choose not to weigh in on discussions like these but > there seems to be a lot of misdirection in some of these arguments. > > To start, I'm generally neutral about this proposal or Nick's proposal > that spurred this one. I've found the most frustrating part of > contributing to anything involving CPython to be the lack of reviewer > time. I have had very small (2-line) patches take months (close to a > year in reality) to get through in spite of periodically pinging the > appropriate people. Moving to git/GitHub will not alleviate this at > all. > > To be clear, the main reasoning behind Nick's was being able to submit > changes without ever having to have a local copy of the repository in > question on your machine. Having a complete web workflow for editing > and contributing makes the barrier to entry far lower than switching > VCS or anything else. BitBucket (apparently, although I've never used > this) and GitHub both have this capability and *both* are > free-as-in-beer systems. > > No one as I understand it is proposing that we use the per-distro > proprietary interface to these websites. > > All data can be removed from GitHub using it's API and can generally > be converted to another platform. The same goes for BitBucket although > it's arguably easier to retrieve issue data from BitBucket than > GitHub. That said, *the issue tracker is not covered by these > proposals* so this is a moot point. Drop it already. > > If we're seriously considering moving to git as a DVCS, we should > consider the real free-as-in-freedom alternatives that come very close > to GitHub and can be improved by us (even though they're not written > in Python). One of those is GitLab. We can self-host a GitLab instance > easily or we can rely on gitlab.com. GitLab aims to provide a very > similar user experience to GitHub and it's slowly approaching feature > parity and experience parity. GitLab is also what a lot of people > chose to switch to after the incident Steven mentioned, which I don't > think is something we should dismiss or ignore. > > We should refocus the discussion with the following in mind: > > - Migrating "data" from GitHub is easy. There are free-as-in-freedom > tools to do it and the only cost is the time it would take to monitor > the process > > - GitHub has a toxic company culture that we should be aware of before > moving to it. They have a couple blog posts about attempting to change > it but employees became eerily silent after the incident and have > remained so from what I've personally seen. > > - GitHub may be popular but there are popular FOSS solutions that > exist that we can also self-host at something like forge.python.org > > - bugs.python.org is not covered by any of these proposals > > - The main benefit this proposal (and the proposal to move to > BitBucket) are seeking to achieve is an online editing experience > allowing for *anyone with a browser and an account* to contribute. > This to me is the only reason I would be +1 for either of these > proposals (if we can reach consensus). > But that's not just it. As you pointed out, Ian, getting patch submissions committed faster would be a huge improvement over what we have today. GitHub/Bitbucket/whatever could help with this by giving core devs basic CI to know that I patch is sound to some extent as well as push button commits of patches. For me personally, if I knew a simple patch integrated cleanly and passed on at least one buildbot -- when it wasn't a platform-specific fix -- then I could easily push a "Commit" button and be done with it (although this assumes single branch committing; doing this across branches makes all of this difficult unless we finally resolve our Misc/NEWS conflict issues so that in some instances it can be automated). Instead I have to wait until I have a clone I can push from, download a patch, apply it, run the unit tests myself, do the commit, and then repeat a subset of that to whatever branches make sense. It's a lot of work for which some things could be automated.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
