Python moved to GitHub(github.com)

820 pointsby c8g9 tahun yang lalu305 comments

https://github.com/python/cpython

315 comments

payne929 tahun yang lalu

Part of Github's secret sauce: Web source tree browsing that's front and center, that's relatively decent, with OK search. (versus making the log/history the central part of the Web UI as other tools seem to do)

There are SO many times I need a short peek at something, and am glad don't have to clone/download, etc.

Stratoscope9 tahun yang lalu

> Web source tree browsing that's front and center, that's relatively decent, with OK search.

The source browsing feels barely adequate to me. There are so many simple things they could do to make it better.

• Show file sizes. When I'm exploring a repo I'm unfamiliar with, one thing that's helpful for me is to get a sense of what the code is like. To do this, I want to look at some of the larger files; that's where I'll probably find the more interesting code. As it is I just click around on random files hoping to find something interesting.

• Show real dates instead of the vaguely rounded off "how long ago". If it says "a month ago", well, what is it, two weeks or six? And why not show the time? A couple of times I've been looking for a code change and I didn't remember what day it was but I did remember it was right before lunch, maybe around 11:30 or so. It feels like their priority is a "clean and simple" display as opposed to a useful and informative display.

• Fix the display for code that indents with tabs. It still defaults to 8 columns, which hardly anyone (with a few notable exceptions) likes. And you, the user, can't override this. They did recently start honoring the indent_size setting if you have a .editorconfig file, but that really misses the point. Many of us who use tabs don't want to specify an indent_size. That's one of the virtues of tabs: people who read the code can use whatever indentation they prefer. The indent size for tabs should be a user preference setting. As it is, I started adding indent_size=4 to my .editorconfig files just to get a decent looking display on GitHub.

• Use a readable font on mobile. Courier, really? And not such low contrast! Everything is hard to read on mobile, and they even disabled pinch-zoom so I can't make the text a little bigger.

• Show a directory tree on the left. If I'm exploring a repo, I'd like to get the big picture of the directory layout, and also have an easy way to click around to look at the various directories. As it is, I have to do a lot of back and forth. Google Code had this from the beginning.

Edit: Thank you everyone for the helpful replies! I learned some great tips from you all.

timdorr9 tahun yang lalu

> Show file sizes

Those are at the top of the display of file contents. However, they aren't in the tree view, as you've stated. Unfortunately, this is hard because I don't believe Git stores this info in their index of files, which is what is used to generate the tree view. It might be infeasible to gather that data for the tree view.

> Show real dates instead of the vaguely rounded off "how long ago".

If you hover over any relative date, the real date is shown. It's on the title attribute for any relative date.

> Use a readable font on mobile.

The have Consolas and "Liberation Mono" on the font stack, but those probably aren't on your phone. They are limited in font selection because they have switched to native fonts. This avoids the download of some giant font file that contains all the possible glyphs (which is needed on a site like GitHub's). Unfortunately, the monospace options on mobile are pretty limited: http://iosfonts.com/

> Show a directory tree on the left.

Best tip I can offer is to type `t` to search by file name. Works great and has partial matching support, which makes it really quick to navigate to certain key files.

benhoyt9 tahun yang lalu

It's pretty cheap to get the file size with decompressing the whole blob. You can decompress just the first hundred of so bytes of the .git blob object, which starts with "blob {size}\x00". For example, using Python:

   >>> import zlib
   >>> f = open('.git/objects/00/331d4c2e12984f70df4a3dd3bc7296825faab0', 'rb')
   >>> zlib.decompressobj().decompress(f.read(100))
   b'blob 11708\x00...'

So that particular file is 11708 bytes. It still requires an open and read operation. But they could cache that on a per-file or per-tree basis, so it's very doable.

timdorr9 tahun yang lalu

At least until you try to open up https://github.com/Homebrew/homebrew-core/tree/master/Formul... :)

a1a9 tahun yang lalu

Just had to test what the other keys did.

What i found:

t = search file

j/k = move down/down (selected file)

w = select branch

s = focus search field

y = expands url

Anyone know any more?

EDIT: Found this https://help.github.com/articles/using-keyboard-shortcuts/

geerlingguy9 tahun yang lalu

Press ? on any page.

OJFord9 tahun yang lalu

Oh my, this just led to me finding https://github.com/issues.

I'm guessing I should be slightly embarrassed to have not realised that existed - was it there before they changed the top bar to black a few days ago? (I now see that there's a link to it from said bar...)

hobo_mark9 tahun yang lalu

OHHHH! It works on gitlab as well!

igravious9 tahun yang lalu

Would _love_if that became standard practice.

ehsankia9 tahun yang lalu

It kinda is. Across most Google products it is (gmail, music, calendar, etc). Most hotkey JS libraries I've seen also use ? as the default for seeing all of the bound hotkeys, so anyone who uses a library should have it by default too. It's always the first thing I try on a website.

igravious9 tahun yang lalu

Interesting. Thanks.

dsacco9 tahun yang lalu

That's incredible.

tlb9 tahun yang lalu

Size = 0 is a common case, useful to highlight, and (I think) should have a common hash value. __init__.py files are a great place to look if they're not empty, but most are.

u801e9 tahun yang lalu

> Unfortunately, this is hard because I don't believe Git stores this info in their index of files,

I don't know if they keep a work tree on the server side, but if they did, then it would be trivial to store the file size as determined from the file on disk and display it on the front-end regardless of the type of view. Alternatively, they could determine the size from the blob associated with the file in the object store.

KayEss9 tahun yang lalu

> keep a work tree on the server side

That's complicated by the fact you could be viewing any commit, not just HEAD of master.

u801e9 tahun yang lalu

Presumably the branch/tag/commit that's currently chosen is stored in the session. You can retrieve the size of a blob by running

    git cat-file -s commit:path/to/file

and the tree object has a listing of the blobs and trees it references. I would think they could do this and store the results when a particular commit is chosen from the drop-down menu on the web page.

recentdarkness9 tahun yang lalu

Just because you can get it, it doesn't mean that this is efficient and fast enough to do when you are browsing through the directories. Now imagine the slowness, since caching this doesn't even make remotely sense for many repos.

u801e9 tahun yang lalu

> Just because you can get it, it doesn't mean that this is efficient and fast enough to do when you are browsing through the directories.

It's already doing this for the last time modified value it retrieves or calculates for each file and directory as I'm browsing through the repo. That requires determining which commit last changed each file and in the case of directories, which commit most recently changed one of the files within the directory.

The file sizes, on the other hand, are available by determining which blob is associated with the file. That file to blob mapping available by recursing through the trees associated with the commit that's currently selected. This does not require iterating through multiple commits, unlike the former case, and it shouldn't be any more complex.

eridius9 tahun yang lalu

The tree doesn't tell you when the blob was last modified either. If they can show last modified time (and commit message), showing file size is surely even easier.

fratlas9 tahun yang lalu

I actually prefer the "time since" method. Don't have to do date maths in your head to see how active the repo/file is.

jakub_g9 tahun yang lalu

> Show a directory tree on the left.

FYI there's a Chrome extension for that

https://chrome.google.com/webstore/detail/octotree/bkhaagjah...

fredley9 tahun yang lalu

It can be a bit of a faff to set up with private repos, but it's a fantastic tool, well worth trying out if you want directory-tree navigation in GitHub.

TACIXAT9 tahun yang lalu

I'd be really happy if they parsed the code and indexed definitions vs usage in search. A lot of times when I'm digging through a project I'll find a function and want to look up the definition. Ok, try searching for the type and function name, nothing, it must be type, a line break, then the function name. A lot of times I end up clicking through pages of search results trying to find something that is a little elusive. It would be awesome if they did it like IDEs and you could filter searches by usage or definitions (go to declaration sort of thing). Given the number of languages they would have to implement that over, I don't think it will happen, but it would be cool.

whatever_dude9 tahun yang lalu

> Fix the display for code that indents with tabs. It still defaults to 8 columns, which hardly anyone (with a few notable exceptions) likes

I still think GH's insistence on 8-space tabs is part of a secret conspiracy campaign to get people to stop using tabs. It always looks bad when you look at tabbed source code in there, so the easier way to avoid it is to start using spaces instead.

haukur9 tahun yang lalu

> Fix the display for code that indents with tabs.

Hidden feature: you can actually add ?ts=2 (or 4) to the URL. It would be nice to be able to configure it, though.

jsheard9 tahun yang lalu

You can use a simple Stylish rule to force it to your preferred indentation:

https://userstyles.org/styles/70979/github-better-sized-tabs...

gnicholasgreen9 tahun yang lalu

This is what I do, and now GitHub styles match my editor styles. It makes my brain tranquil.

Sohcahtoa829 tahun yang lalu

> disabled pinch zoom

Can anyone explain to me why this is even a feature?

Why did the powers that be decide that web sites should be able to prevent pinch zooming? Why do mobile browsers not provide the option to disable this bug?

ayosec9 tahun yang lalu

> Why do mobile browsers not provide the option to disable this bug?

In Firefox, you can set browser.ui.zoom.force-user-scalable to true.

Unfortunately, if have JavaScript enabled, some pages are still able to disable the zoom.

krzyk9 tahun yang lalu

I agree, it is a real PITA when using <7" phones.

netheril969 tahun yang lalu

What I want most is "jump to definition". Maybe not as full fledged as the true IDE, but just ctags like behavior is immensely helpful.

jdormit9 tahun yang lalu

The Sourcegraph Chrome extension provides this for Python, JavaScript and a few other languages I think.

netheril969 tahun yang lalu

I known. But their language support is very limited.

zielmicha9 tahun yang lalu

I've made codesearch.xyz with that purpose. It lets you enter repo URL and then it lets you search and browse the code.

bdcravens9 tahun yang lalu

> Show a directory tree on the left

The OctoTree extension is great for this (all browsers, and works for both Github and Gitlab)

c8g9 tahun yang lalu

> Show file sizes

https://github.com/harshjv/github-repo-size

arthurfm9 tahun yang lalu

> GitHub Plus [1][2] does that and more.

Features

1. Displays repo size.

2. Displays each file size in every active branch (not applicable for folder / symlink).

3. Show download link for each individual file (not applicable for folder / symlink).

4. Copy file's contents directly to Clipboard (just won't work for markdown files).

5. Download file while viewing it's contents.

[1] https://github.com/softvar/github-plus

[2] https://chrome.google.com/webstore/detail/github-plus/anlikc...

rbanffy9 tahun yang lalu

> • Fix the display for code that indents with tabs. It still defaults to 8 columns

God made the ASR-33 with 8-column tabs for a reason. ;-)

As for style, it is relatively easy to make a browser plugin that overrides the default styles of a site. While working for Canonical, I did one for Launchpad:

https://chrome.google.com/webstore/detail/launchpad-tweaks/p...

strictfp9 tahun yang lalu

To me the real killer is that the code formatter is too slow on mobile, with no way (AFAIK) of opting out.

findjashua9 tahun yang lalu

"Show a directory tree on the left"

if you use Chrome, try out Octotree

wilg9 tahun yang lalu

Hovering over any time on GitHub shows the absolute time.

mkesper9 tahun yang lalu

That's as bad for compairing as giving file sizes in bytes, kilobytes and megabytes in the same listing.

strictfp9 tahun yang lalu

gioele9 tahun yang lalu

> Part of Github's secret sauce: Web source tree browsing that's front and center, that's relatively decent,

Plus decent rendering of README.md at the same base URL.

You get a decent homepage for your project by just pushing your repo.

I wish GitLab just copied the base project page of GitHub.

sytse9 tahun yang lalu

We're thinking about adding the file tab to the default view in https://gitlab.com/gitlab-org/gitlab-ce/issues/26834

sb82449 tahun yang lalu

Going to second this.

I love the idea of gitlab but I absolutely cannot enjoy the UI. I have trouble understanding the layout of the project from the base URL. I don't have that problem at all on github.

Edit: I'm a fool. I swapped gitlab and bitbucket. BB interface is absolutely bad to me.

Insanity9 tahun yang lalu

Even though you did not mean to say so, I would actually agree that the UI of gitlab is not great either. GitHub's UI/UX is better than Gitlab imo.

tyingq9 tahun yang lalu

I wish github would add an option for a case sensitive search. Tired of getting back ThisThing when I specifically want thisthing (lower case).

Also, the search documentation is spread out and seems to be missing guidance on features that are crucial. For example, AND works as you would expect (like: hello AND world), but it isn't mentioned anywhere.

dajohnson899 tahun yang lalu

This this this. I would spend so much time on GitHub if the search were better. I'm tempted to say that search is less than OK. I do have a huge Java repo, but I'm usually shocked when I quickly find what im querying for.

EmielMols9 tahun yang lalu

I'm always stuped by the fact that when I search for SomeClass I get a dozen of results from tests and the actual class SomeClass in a file called SomeClass.x appears on page 4. Haven't found a way yet to exclude those pesky tests.

avn21099 tahun yang lalu

It still boggles my mind that there is no (good) way to search all an organization's repos at once. The docs (e.g. [0] but also in other places) claim you can just put "org:foo" in the search bar, but it has never worked for me.

[0] https://help.github.com/articles/searching-code/

thebelal9 tahun yang lalu

"user:foo" will search an organisation named foo.

iSnow9 tahun yang lalu

Using google and site:github.com? I never use the search on the site...

Gracana9 tahun yang lalu

And then clicking Tools->Verbatim because google otherwise gives results that are wildly different from what you specify..

GrinningFool9 tahun yang lalu

I can't believe I've missed this. The quality of my search results at google has been steadily going downhill, and I'm often left with a thought along the lines of, "But if you just searched for only the words I used..."

Anyway, thanks for posting it!

dajohnson899 tahun yang lalu

There should be a search mode for IT professionals. That way, things like curly braces, numbers, and non-words are still treated as meaningful.

brettlangdon9 tahun yang lalu

I am always amazed at how hard it is to find something with GitHub's search, when `git grep` works so well.

kevincox9 tahun yang lalu

git grep is far more expensive and slower the what GitHub does, especially on large repositories.

justinclift9 tahun yang lalu

So... ?

josteink9 tahun yang lalu

grep works on the actual, full repo data and not a precomputed index (which is computationally speaking orders of magnitude faster).

No online service in the world does not index things.

If you need full access to everything, why not just clone the repo and do these things in the comfort of your command line?

flamedoge9 tahun yang lalu

why not just full regex

tyingq9 tahun yang lalu

Actually, I would really just be happy with better docs. In code search, for example, this appears to work:

foo AND bar NOT baz OR fizz

So, it supports AND, NOT, and OR. Nowhere, though, does it say that. I don't know if I can group these to get around precedence either. Parenthesis are ignored. It does mention NOT somewhere. And, there's no navigation to search help by the search button. I had to google to find out any help was available.

Also, it ignores some characters for unknown reasons. Like $, for example. That's a meaningful sigil in Perl, PHP, and so on...it's quite frustrating that it's ignored.

OJFord9 tahun yang lalu

> this appears to work: foo AND bar NOT baz OR fizz

`AND` being implicit in `bar NOT baz`, and in `foo bar`. Also AND/OR is per file, rather than line which I wondered after reading this comment.

There's some information here [0] that's mainly centred on issues/PRs, but some transferable (this might be what you referred to that does mention NOT). There's also a bit more information here [1]; it does at least acknowledge that `$` will be swallowed.

[0] - https://help.github.com/articles/search-syntax

[1] - https://help.github.com/articles/searching-code/

mbell9 tahun yang lalu

regex search is slow and difficult to index efficiently.

jcoffland9 tahun yang lalu

It's plenty fast for many purposes. I grep large source code repos all the time. It's very fast as long as you avoid grepping large binary files for no reason.

The link below shows timings for various regex on a 20MiB text file for several different regex softwares. The best code never exceeds half a second for even the worst expressions. Most are much faster.

http://sljit.sourceforge.net/regex_perf.html

bdonlan9 tahun yang lalu

For most reasonable search regexes, it's reasonably fast if your repository is already cached in memory. However, it's still fairly heavyweight, and the cost of running even these reasonable searches hundreds or thousands of times a second becomes significant.

When you add to this the fact that it's possible to deliberately construct regexes that are much more complicated to evaluate (particularly if you allow extensions beyond a true regular language) - potentially being a DoS target - and many repos won't be cached when the search comes in (or caching them would also be very expensive), the costs just get higher.

In contrast, a simple keyword search can be performed with a predictable, low cost, so it's no wonder that they'd prefer to implement this instead.

milesrout9 tahun yang lalu

>When you add to this the fact that it's possible to deliberately construct regexes that are much more complicated to evaluate (particularly if you allow extensions beyond a true regular language) - potentially being a DoS target

Only if you allow extensions, but then they aren't regular expressions.

tyingq9 tahun yang lalu

Backreferences aren't really an extension though, are they?

Re2 excludes them specifically .

milesrout9 tahun yang lalu

Backreferences are certainly an extension. They are the primary reason that regular expression engines that allow them are slow.

tyingq9 tahun yang lalu

Ahhh, "extension" meaning not in the POSIX basic definition. Sure. Though I don't know many tools that implement REs in that basic form. They almost all include features outside that definition.

burntsushi9 tahun yang lalu

No, extension as in it is not regular. Nothing to do with POSIX. RE2, Go and Rust do not provide backreference support in exchange for predictable performance.

[deleted]9 tahun yang lalu

notriddle9 tahun yang lalu

There are plenty of regex engines that are guaranteed O(n) for all regexes they accept. There's re2, go-regex, and rust-regex just to list a few popular ones.

They still use Perl-like syntax, and might still be able to parse non-regular languages, but you don't need to worry about users deliberately crafting regexes to eat up CPU time like PCRE.

kevincox9 tahun yang lalu

Do you remember Google code search? Difficult yes, but definitely not slow. This seems like it would be a high value feature as well.

Jedd9 tahun yang lalu

If you're using chrome / chromium, and you don't know already, then you may be cheered to find out about the Octotree extension: https://github.com/buunguyen/octotree

rickycook9 tahun yang lalu

readme says that it also works in ff and safari

jefffan2419 tahun yang lalu

Thank you for introducing this to me, that is amazing.

beliu9 tahun yang lalu

Check out Sourcegraph: web source tree browsing with jump to def, find refs, and a bunch of other intelligent features. For example, try diving into the Go std lib: https://sourcegraph.com/github.com/golang/go/-/blob/src/net/...

(Disclaimer: I'm one of the creators. We currently only support Go officially, but other languages soon on the way via the open-source Language Server Protocol standard. Also, big fans of GitHub and glad to see this move!)

yomly9 tahun yang lalu

Even just being able to browse code when I'm on the go on my phone is useful!

I am guilty of occasionally even viewing my own projects on github to avoid having to put down what I'm doing to check what's in production...

trevor-e9 tahun yang lalu

It's unfortunate that their mobile site is very watered down compared to desktop. Every time I view something on my phone I have to request the desktop version of the site.

metaobject9 tahun yang lalu

I do that for every site i can think of because, as a person with very poor eyesight, the ability to zoom seems better on desktop-site pages than on mobile-site pages.

tedmiston9 tahun yang lalu

On iOS, Safari Reader helps solve this problem on text heavy pages. I crank the font size up to 16–18px with white text on black background.

kevincox9 tahun yang lalu

Firefox mobile (at least on Android) has an option that prevents sites from disabling zooming in.

Gracana9 tahun yang lalu

Chrome also has an accessibility option for this. That discovery solved my problems with a lot of sites.

yomly9 tahun yang lalu

agree - I do the same too.

SamReidHughes9 tahun yang lalu

For what it's worth, there are git client apps that you can run on your phone. I've found them to be... usually nicer than GitHub.

torg9 tahun yang lalu

Any particular ones you'd recommend.

tedmiston9 tahun yang lalu

The "t" key shortcut to do repo wide file search is one off my favorite features.

TeMPOraL9 tahun yang lalu

> with OK search

As far as I can tell, Gitlab (still) doesn't have search within repo. It's one of the most useful features on Github for me; often I want to see the definition or uses of some symbol without having to clone the repo. I don't understand why Gitlab doesn't seem to support it.

daxelrod9 tahun yang lalu

It does, but I believe you need GitLab EE with ElasticSearch turned on: https://docs.gitlab.com/ee/integration/elasticsearch.html

jackyb9 tahun yang lalu

I just tried on my Gitlab 8.16 and it seems to be able to do that. If you go to the Code tab, it shows snippets of files that contain the search term.

wott9 tahun yang lalu

> OK search

Damn... I can't even manage to figure out how it works. I consider myself extremely lucky when it returns the expected result, and that seldom happens.

aub3bhat9 tahun yang lalu

Could not agree more while I was learning to program, it took me months before realizing that it was possible to Browse a Google Code project online.

mythz9 tahun yang lalu

GitHub code search + file navigation is so good, that I prefer it to search/navigate code vs opening a VS.NET sln of a repo already cloned locally.

kzrdude9 tahun yang lalu

git grep is still much better than github's search, when it comes to code. Github search doesn't show enough when there are many matches in the same file.

mythz9 tahun yang lalu

Not when searching for files, find-as-you-type lets you type the least chars/camelHumpsNotation to quickly find + open files you're looking for and its deep linkability lets you quickly share code fragments with remote devs.

notriddle9 tahun yang lalu

Ctrl-P in SublimeText.

agumonkey9 tahun yang lalu

I actually dislike their "tree browsing", which is not a tree .. herein lies the problem.

What I like in github .. it's a multiformat http file viewer.

celim3079 tahun yang lalu

same reason i like npm 'run this in your browser' feature. lets u play around with the actual implementation

laurentdc9 tahun yang lalu

Yes!

I quite like the idea of "centralizing" development on GitHub, or similar services. It makes it much easier for everyone to fork, test, make a pull request, merge, etc..

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't much different. [2]

[1] https://dev.openwrt.org/wiki/SubmittingPatches#a1.Creatingap...

[2] https://docs.python.org/devguide/patch.html

ycmbntrthrwaway9 tahun yang lalu

Centralizing around proprietary software is not a good idea generally.

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 "issues" feature for good.

One way to avoid email without centralization is setting up Gerrit. That is how Ring [1] and LineageOS (former CyanogenMod) [2] manage their "pull requests".

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.

[1] https://gerrit-ring.savoirfairelinux.com/

[2] https://review.lineageos.org/

[3] http://suckless.org/

ajdlinux9 tahun yang lalu

Everyone I know who has had to use Gerrit has absolutely, utterly despised it.

Until I got a job working as a kernel developer I had never had to use emailed patches. It simply isn't an "absolutely necessary" skill for a good developer these days.

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.

But it's still not good. There are plenty of ways to screw up email threading or forget conventions on labelling patchset versions or whatever (this happens all the time). You have to rely on external tools such as Patchwork to provide a bare minimum of state-tracking. There's not much by way of generic CI tooling that's designed with email in mind (I'm working on this!). Doing code review from an email client definitely has its benefits, but it's also limiting - web-based code review tools have much more scope for experimenting with better ways of presenting comments.

I can't see the Linux kernel ever moving away from email, and honestly it's not too bad once you've figured out your workflow, but I would like to see kernel hackers thinking about what it is that the kernel community loves so much about email compared to GitHub and other centralised services. It is 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 better?

mugsie9 tahun yang lalu

Sure, gerrit has a learning curve.

When you end up using it for a long time, going back to pull requests is awful.

Its basic things:

- history of a PR - I cannot see the diff of last version of the patch and latest

- dependant changes - I need to do some work that depends on a patch someone else is working on. This can't be done in github.

- clean history - no "added tests", "fixed docs typo" etc commits

I learnt recently that most people don't use git-review[0] - and yeah, if you are manually doing the "git push gerrit ref/for/master" crap, it's really annoying. but git review and repo were written to help that.

0 - http://docs.openstack.org/infra/git-review/

rando8329 tahun yang lalu

I used gerrit and did not utterly despised it. Hi.

mugsie9 tahun yang lalu

I have been using it for a few years, and I miss it when I am working on github projects :/

ajdlinux9 tahun yang lalu

Well I'm glad someone likes Gerrit. :D

[deleted]9 tahun yang lalu

webmaven9 tahun yang lalu

> There's not much by way of generic CI tooling that's designed with email in mind (I'm working on this!).

Ooh, interesting. Where can I find out more?

BTW, you might consider supporting NNTP as well, among other advantages, crappy email clients can't screw up the threading & you avoid Reply-To munging debates.

ymse9 tahun yang lalu

> There's not much by way of generic CI tooling that's designed with email in mind (I'm working on this!).

I am interested in learning more about this. Can you share some details? Is there a prototype?

durin429 tahun yang lalu

All the communities I know that are centered around diff-in-email patch review are quite frustrated by the available GUI tools (most of them are only good for one patch at a time, or treat an entire stack of patches as one change). If you get somewhere with this, let me know? We might be interested in testing it on Mercurial depending on how it integrates with the email side...

breakingcups9 tahun yang lalu

I've only used Gerrit occasionally, but when I had to the experience was mostly pleasant. Getting set up is a bit more work than just git push but it made sense after reading into it.

Maybe it's a matter of configuration?

djeikyb9 tahun yang lalu

i absolutely loved it, especially compared to atlassian's bitbucket code review features.

hueving9 tahun yang lalu

>Everyone I know who has had to use Gerrit has absolutely, utterly despised it.

Everyone I know who has had to use github has utterly despised it. I work with a lot of systems and kernel programmers that use gerrit or email workflows.

See how anecdotes aren't very useful?

lucb1e9 tahun yang lalu

No because pretty much everyone will know counterexamples of the later anecdote but not the former.

I'm all for facts and statistics instead of personal experiences, but I doubt HN would survive the night if we suddenly prohibited personal experiences and required a double blind test with a good sample size before posting a single comment.

hueving9 tahun yang lalu

>No because pretty much everyone will know counterexamples of the later anecdote but not the former.

Just because so many more people use Github. It's easy to shit on less popular things via second-hand anecdotes like you did because there is a good chance very few users will see it.

Consider something like this: "Everyone I know who had to use the flight control computer of the F-35 has absolutely, utterly despised it."

So few people will be able to refute that in this forum that many people would just take what you said at face value and assume the F-35 flight control computer is garbage.

"People tell me X" is just a terrible form of discussion because you can't speak authoritatively on what they said X if you are pressed for details. It's just noise without any depth.

>I'm all for facts and statistics instead of personal experiences

What you provided wasn't even as good as a personal experience. It was a personal experience of a conversation you had with someone else about their personal experience.

ajdlinux9 tahun yang lalu

It should probably be clarified that the people I know who despise Gerrit actually prefer email workflows. They're all kernel programmers.

fake-name9 tahun yang lalu

Anything is better then e-mail based systems.

The discoverability, browsability, and useability of something with actual markup and design is infinitely better then e-mail.

I've tried several times to make submissions to several e-mail based projects, never with any success. At the same time, I've had zero issues contributing to a dozen or so github hosted projects.

E-mail systems are a shitshow. First, you generally have to join a mailing list, which is regularly broken, or requires someone somewhere to manually acknowledge your membership. Then, you have to figure out how they want shit formatted, figure out how to generate a diff (I've been using SVN for 8+ years, git for ~3 years, and have never had to deal with diff files!), send an e-mail, find the mailing list shat itself and troubleshoot, try again, etc....

Basically, e-mail is the death of any sort of low-effort contribution. If you're starting a new project, and chose a mailing list, you're probably excluding a huge quantity of potential contributors.

If there's a project where I want to make a few-line change or minor enhancement, and it's on github, I'll generally PR it back into the original. If it's somewhere else, or requires another account, there's no way I'm going to spend the effort.

Plus, just reading mailing lists is a fucking disaster. Literally no mailing list host I know of lets you just view a complete topic thread in simple chronological order on ONE PAGE. They all operate on a per-message response-tree structure, so just reading the discussion is a huge pain in the ass.

E-mail is basically dying among younger people, including the ones that code, and with good reason. For actual forum-type discussions, it's a completely shit solution.

cyphar9 tahun yang lalu

> I've tried several times to make submissions to several e-mail based projects, never with any success.

$ git send-email --to=<mailing list> <commit range to send>

That was hard.

> First, you generally have to join a mailing list, which is regularly broken, or requires someone somewhere to manually acknowledge your membership.

Most public MLs that accept patches are Cc'd for posterity's sake, and thus generally don't require being a member to post. You will always get Cc'd to discussions (git send-email automatically adds you to the Cc list).

> Then, you have to figure out how they want shit formatted, figure out how to generate a diff [...], send an e-mail, find the mailing list shat itself and troubleshoot, try again, etc....

See above. It's one command, or two (git format-patch + send-email) if you want to tweak the email.

> (I've been using SVN for 8+ years, git for ~3 years, and have never had to deal with diff files!)

I find this hard to believe. You've never hand-edited a diff file with `git add -p` or `git checkout -p` -- or even done a `git diff`, `git show` or `git log -p`? I did all of the above things just today, let alone in the past three years...

> If it's somewhere else, or requires another account, there's no way I'm going to spend the effort.

I'm going to be honest, as someone who maintains a project hosted on GitHub I don't like it when someone decides they'll "help out" by dropping three lines of code in a patch and disappearing off the face of the earth. If you're not bothered to follow up on your patch review, then you've just inflicted a net negative on the project.

> Literally no mailing list host I know of lets you just view a complete topic thread in simple chronological order on ONE PAGE.

But chronological order isn't what you want for ML threads. You want to read it as a tree, because that's how people use email... Patch review isn't like a YouTube comment thread.

fake-name9 tahun yang lalu

> $ git send-email --to=<mailing list> <commit range to send> > > That was hard.

So how the hell does that work?

Like, how does git know how to send e-mail? Do I have to stick smtp creds in somewhere?

> I find this hard to believe. You've never hand-edited a diff file with `git add -p` or `git checkout -p` -- or even done a `git diff`, `git show` or `git log -p`? I did all of the above things just today, let alone in the past three years...

There are many, many ways to interact with git, such as the many, many tools that make it so you don't have to interact with all that shit. tortoisegit is a wonderful tool, and it makes git SO much nicer.

> But chronological order isn't what you want for ML threads. You want to read it as a tree, because that's how people use email... Patch review isn't like a YouTube comment thread.

Except generally, before I'd interact with a ML, I want to see what the ML is like, and having to click through many, many pages with little content on each is just dumb.

Also, you may use e-mail as a tree, but that's you. I use thunderbird, and you can set it to display as a tree, or you can set it to not, and I personally don't.

As far as I can tell, 99% of the ML content I've read is basically a shitty, shitty implementation of a simple forum on a much crapper transport.

toomuchtodo9 tahun yang lalu

> As far as I can tell, 99% of the ML content I've read is basically a shitty, shitty implementation of a simple forum on a much crapper transport.

And when Github goes belly up, or whatever the SaaS version control flavor of the month is, mailing lists and their archives will still be there.

Simplicity is the ultimate sophistication.

orf9 tahun yang lalu

And they will still be shit, until it's too hard to find anyone to collaborate on your projects.

[deleted]9 tahun yang lalu

cyphar9 tahun yang lalu

> > $ git send-email --to=<mailing list> <commit range to send>

> > That was hard.

> So how the hell does that work?

> Like, how does git know how to send e-mail? Do I have to stick smtp creds in somewhere?

git send-email implements SMTP. You can give it your credentials directly using git config, or by using sendmail which quite a few people have set up (I use esmtp which is an implementation of sendmail that is very simplistic and just requires a password, server and username). And it all "just works".

> As far as I can tell, 99% of the ML content I've read is basically a shitty, shitty implementation of a simple forum on a much crapper transport.

Except forums are shit if you want to have different discussions about four somewhat-related patches. How do you handle trees of discussion like that?

> Also, you may use e-mail as a tree, but that's you. I use thunderbird, and you can set it to display as a tree, or you can set it to not, and I personally don't.

I don't use it as a tree when answering normal emails, but if you're Cc'd to three different discussions in the same thread it's much nicer to be able to see WTF the person above was responding to with better granularity than "something said on this mailing list at some point in the past".

notriddle9 tahun yang lalu

> Except forums are shit if you want to have different discussions about four somewhat-related patches. How do you handle trees of discussion like that?

You're literally typing this into a forum that supports that kind of tree of discussion, and you're literally having a side-conversation right now. A web forum can implement any style of conversation you can conceive; the web's very generic that way.

I think GitHub deliberately doesn't support that kind of thing because they want to encourage having lots of little issues instead of a few big ones. It does get annoying for pull requests, though...

orangeshark9 tahun yang lalu

You can add send-email configuration in your .gitconfig. Here is an example from the documentation that uses gmail. https://git-scm.com/docs/git-send-email#_use_gmail_as_the_sm...

voltagex_9 tahun yang lalu

> $ git send-email --to=<mailing list> <commit range to send>

> That was hard.

What does this do by default in Windows?

In Linux, what if you don't have a local MTA installed/configured? I'd wager most GMail users aren't going to set up Mutt and an application specific password to make it all work.

ajdlinux9 tahun yang lalu

You can configure it with SMTP, so it's usable with or without a local MTA.

Buuuuuuuuuut, that's still more effort than I'd be comfortable imposing on a new contributor, honestly. Guess why the kernel community keeps pushing away drive-bys?

voltagex_9 tahun yang lalu

The Eudyptula Challenge was my first exposure to git-send-email. My first email was rejected due to the attachment being base64 encoded, I think. This is how I know setting up Mutt with GMail is fairly painful.

I kinda get why LKML pushes away drive by contributions - if the quality of the patch is low it can cause problems for maintainers and subsystem maintainers. The kernel has stuff like checkpatch.pl to help though. If you're contributing to the kernel you should probably be able to run a Perl script.

zeveb9 tahun yang lalu

> Guess why the kernel community keeps pushing away drive-bys?

Because drive-by contributions to the kernel are likely to be more trouble than they're worth? This is code which will run on every Linux device out there, from thermostats to WiFi access points to individual computers to Google's & Facebook's data centres: it had better come from someone who knows his stuff, inside & out, and it's probably a Good Thing™ if he's not afraid of a command line and email.

gkya9 tahun yang lalu

If you don't have a local SMTP setup (MTA is sth else): obtain your patch from your VCS (e.g. git diff revs...), save it to a file, attach to the mail via your mail client.

PuercoPop9 tahun yang lalu

No need to git diff. Git format-patch does the work for you. Apply the patch with git apply-patch. Less work than sending a PR and the receiver has to do less work to merge locally in a branch should they want to modify something. Github does make it easy for drive by commits for typos an trivial changes like that.

netheril969 tahun yang lalu

> But chronological order isn't what you want for ML threads. You want to read it as a tree, because that's how people use email... Patch review isn't like a YouTube comment thread.

If any of them can display all of the tree on one page, then maybe I won't hate mailing lists so much. I hate clicking back and forth in a swath of emails, each having a little and often irrelevant content, and getting lost in where I am in this "tree".

Manishearth9 tahun yang lalu

> That was hard.

Yes, it was. I need to set up command-line email locally on my computer. How do I do this on Windows? (or, on Linux, for that matter) How do I do this if behind a proxy? What if port 25 is blocked entirely (i.e. many university networks)? I have been in at least one of these three situations for very long periods of time, each.

Of course, I can just format-patch + email, if I don't want to set this up locally.

Wait, no, I can't. Gmail replaces tabs with spaces in plaintext emails. Most MLs want plaintext emails. I could use an attachment but not all patch submission processes allow that. So I'm back to needing a client or switching my email provider. Welp.

Okay, let's say I managed to get git send-email working locally. Now, how do I send my updated patch after having gotten review?

Oh, I see, I need to muck with a Message-ID header. Looking at the first Google result (what most folks trying this will hit) http://studioidefix.com/2014/06/17/replying-to-lkml/ -- it's literally building the email headers from the command line, after some manual copypasting. There may be tools for this, but they're definitely not discoverable.

I could sync up my email client via POP or IMAP, but now I have to emails locally, and possibly change how I interact with email. Also, this is another bundle of confusingness. When I first set this up many years ago I synced a bit more than I needed, but was afraid of deleting things because the deletion may be reflected. Getting this set up just right is a whole other world of pain.

Nope.

Github isn't as easy as those used to it think either, but emailing patches is definitely not easy.

I've done a lot of mentoring for folks getting involved in open source. Like I said, it becomes apparent that GitHub isn't as easy as folks think it is. But it's well documented, and still not hard to ramp up on. I've had folks nearly give up on mailing list contributions.

> You've never hand-edited a diff file with `git add -p` or `git checkout -p` -- or even done a `git diff`, `git show` or `git log -p`? I

People interact with tools differently. GUIs exist. Interacting with diffs is different from interacting with diff files. I've got my `git diff` setup to show a much cleaner colorful diff (except when piped, in which case it shows a diff file). The only time I see normal diff files is when I'm submitting patches to MLs, (or when I'm copying patches across vendored repos; a niche task) the rest of my diff-viewing is with colorful commandline diffs that look quite different. It's easy for me to imagine that folks using GUIs would never directly deal with a diff file.

> because that's how people use email...

No that's how you use email. Others may not. Reading flattened comment threads is totally fine, even if the underlying review is treelike. Treelike viewing is more suited for viewing updates to a conversation you're otherwise caught up on, but often it's better to view a conversation you haven't seen before in a linear fashion.

u801e9 tahun yang lalu

> Yes, it was. I need to set up command-line email locally on my computer. How do I do this on Windows? (or, on Linux, for that matter)

All of those questions are answered in the man page for git send-email. You can specify them via a command line option when invoking that command, or just add that information to the git config file.

> Wait, no, I can't. Gmail replaces tabs with spaces in plaintext emails.

Is that done by the Gmail web client or is it something done by their SMTP server?

> Oh, I see, I need to muck with a Message-ID header.

One thing that I think would be an improvement to git format-patch and git send-email is having it default to setting the Message-Id header in the email it generates rather than relying on the SMTP server to generate it.

> but often it's better to view a conversation you haven't seen before in a linear fashion.

How do you deal with the case when multiple discussion threads are interleaved with each other? Is it easy to find the email that was partially quoted the message you're viewing?

Manishearth9 tahun yang lalu

> All of those questions are answered in the man page for git send-email. You can specify them via a command line option when invoking that command, or just add that information to the git config file.

Many, many pages below in the configuration section.

Yes, on its own that's not too big a deal (you can always google the setup, though for me it's the fourth result on google that is not the man page itself). But this stacks up with the rest of the issues -- with send-email it's tricky to respond to existing review threads with new patches. Clients fix that, but they have a whole host of other issues.

> Is that done by the Gmail web client or is it something done by their SMTP server?

The web client. Whether or not SMTP does this isn't the point here -- I brought up the web client as an alternative to using SMTP, because SMTP is not an option for many, and even if it is, one really shouldn't have to set up an email client and potentially change their email workflow to contribute patches.

> One thing that I think would be an improvement to git format-patch and git send-email is having it default to setting the Message-Id header in the email it generates rather than relying on the SMTP server to generate it.

That doesn't make sense, it doesn't know what message id to set. It needs to hook in to a mail client to know that.

> How do you deal with the case when multiple discussion threads are interleaved with each other? Is it easy to find the email that was partially quoted the message you're viewing?

I meant chronological view for a given thread. You still need fully threaded view, but comprehending an entire thread in non-inlined fully-threaded view is really annoying. Inlining the emails or using some JS for expand/collapse can help, but as it stands most if not all web interfaces for MLs are terrible.

u801e9 tahun yang lalu

>> Is that done by the Gmail web client or is it something done by their SMTP server?

> The web client. Whether or not SMTP does this isn't the point here

If I happen to be using a mail client that doesn't modify the content of the patch and configure it to use Gmail's SMTP server, then it certainly renders that point moot. On the other hand, if it was the SMTP server then it would not be possible to send patches in that fashion regardless of what MUA was used (and would be a bigger problem in terms of contributing to projects that require inline patch submission via email).

>> One thing that I think would be an improvement to git format-patch and git send-email is having it default to setting the Message-Id header in the email it generates rather than relying on the SMTP server to generate it.

> That doesn't make sense, it doesn't know what message id to set.

It could use the value like <commit-sha1>@localdomain. Basically the message-id value should be a relatively unique value.

> It needs to hook in to a mail client to know that.

I think we may not be on the same page here. I was referring to the Message-Id header of the message itself (when it's written to disk by git format-patch), not the value of the In-Reply-To header or the last value in the References header.

So if git format-patch set that header when generating the message (rather than relying on the SMTP server to set that header), then you could easily have it refer to the file generated by the previous invocation by name, via a command option, to retrieve the message-id value and use it to populate the In-Reply-To and References headers (instead of having to retrieve the message from some remote server and copying its message-id value to specify as a command line option).

> but as it stands most if not all web interfaces for MLs are terrible.

This is why I prefer having an NNTP gateway (like gmane) to browse mailing lists using my locally installed MUA (or newsreader).

Manishearth9 tahun yang lalu

> If I happen to be using a mail client that doesn't modify the content of the patch and configure it to use Gmail's SMTP server, then it certainly renders that point moot.

The whole point was that I was discussing an alternative to mail clients, however. If this was an issue with clients I would have brought it up with clients.

> It could use the value like <commit-sha1>@localdomain. Basically the message-id value should be a relatively unique value.

git commit --amend breaks this. You need to come up with some stable scheme here. Branch name could work. Ties you to a specific contribution model, though. So does github; but in a more overt way, this could lead to hidden bugs occurring. I usually don't use a branch when contributing to GDB (which uses an ML), for example, I just use a detached head.

> I think we may not be on the same page here. I was referring to the Message-Id header of the message itself (when it's written to disk by git format-patch), not the value of the In-Reply-To header or the last value in the References header.

Yeah, but that's tricky to autoset in a stable way, too, like I say above.

> This is why I prefer having an NNTP gateway (like gmane) to browse mailing lists using my locally installed MUA (or newsreader).

Right, but this just increases the barrier to easy participation

u801e9 tahun yang lalu

> The whole point was that I was discussing an alternative to mail clients, however. If this was an issue with clients I would have brought it up with clients.

Granted, but I think that if projects require submitting patches via email, then using a local mail client makes it much easier to do so. I don't see having to install and configure an MUA any more of a barrier to contributing than it is to install a web browser to use Github to contribute to other projects that expect pull requests.

>> It could use the value like <commit-sha1>@localdomain. Basically the message-id value should be a relatively unique value.

> git commit --amend breaks this.

No, it doesn't. git am doesn't make any use of the message-id header when applying the patch to your working copy. The commit in your local repository will have a different sha1 compared to the corresponding commit the patch author has (or any other reviewer who has applied that patch to their own working copy for that matter).

Basically the steps would be:

1. Generate a patch series using git format-patch

2. Use git-send-email to send the patches to the mailing list.

3. Get reviews

4. Address comments

5. Use git format-patch to generate a new patch series for re-roll with a command line parameter that refers to the file containing the cover letter for the original patch series.

The command line parameter that I mention would be able to retrieve the value of the message-id that was generated by the first invocation of git format-patch and then set the values of the In-Reply-To and References headers in the new cover letter message without you having to manually copy it from your original message when viewing it in your MUA (or web browser).

> Yeah, but that's tricky to autoset in a stable way, too, like I say above.

The sha1 of the commit should be unique enough. Assuming the SMTP server doesn't override what was set by the client, then it should work without any issues. I have tested this with one commercial SMTP server by manually setting the Message-Id header in a telnet session and did see it unaltered in the message I received. I still need to run this test with other SMTP servers to see if I get the same result.

>> This is why I prefer having an NNTP gateway (like gmane) to browse mailing lists using my locally installed MUA (or newsreader).

> Right, but this just increases the barrier to easy participation

I disagree. It's not fundamentally harder to use a MUA, news reader, or IRC client than it is to use a web browser.

Manishearth9 tahun yang lalu

> I don't see having to install and configure an MUA any more of a barrier to contributing than it is to install a web browser to use Github to contribute to other projects that expect pull requests.

Almost everyone has a web browser installed. Not everyone has a MUA installed.

> 5. Use git format-patch to generate a new patch series for re-roll with a command line parameter that refers to the file containing the cover letter for the original patch series.

This was the step I missed, thanks. This could work. You now need to keep your patches around, but it could work.

> The sha1 of the commit should be unique enough.

I meant stable across local changes to the commit. I didn't realize you were serializing this commit hash to some file and fetching it from the file later.

> I disagree. It's not fundamentally harder to use a MUA, news reader, or IRC client than it is to use a web browser.

I believe more people have a web browser set up than they do a MUA. You cannot browse the web effectively without a web browser (I mean, you can use lynx, but the modern web is not well suited for that), and this is pretty necessary these days. You can use email effectively without a local email client, however.

It's not just that the MUA is harder to set up, it's that you're asking people to effectively change their entire workflow for interacting with email just so that they can contribute.

And yes, MUAs are harder to set up. Refer to aforementioned points about blocked ports, confusing IMAP/POP3 deletion semantics (I don't want to accidentally delete all my email!), proxies, etc.

u801e9 tahun yang lalu

> Almost everyone has a web browser installed. Not everyone has a MUA installed.

It shouldn't be an issue to install one. A somewhat related example I recently came across was when I had to install Google chrome to use a feature of Slack that wasn't supported in Firefox. To get around that issue, I installed chrome. If I had to, I would have also had to set up the necessary proxy configuration for that browser to work (though that wasn't the actually the case).

Similarly, if one wants to contribute to a project that requires emailed patch files, then part of the process should be installing and setting up a MUA if the web based front-end doesn't work properly.

> This was the step I missed, thanks. This could work. You now need to keep your patches around, but it could work.

I think it's easier than having to retrieve the original message via IMAP, POP, or HTTP and copying its message-id value :)

> I meant stable across local changes to the commit. I didn't realize you were serializing this commit hash to some file and fetching it from the file later.

Typically, when contributors do a re-roll of a patch set, they effectively either use git commit --amend or git rebase to update the commits in the branch they're working on. The updated patchset is sent to the mailing list and pulled down by reviewers and applied to their working tree (which results in a commit with the same change, but a different SHA1). This is unlike the case where one runs git fetch or git pull and pulls down the commits and gets the commits with the same SHA1 applied to their local copy.

In other words, the SHA1 value isn't that important other than to serve as a unique value of the message-id header.

> You can use email effectively without a local email client, however.

I use both web based clients (hotmail, gmail) and a locally installed MUA (thunderbird). I can say that I have a better user experience with the MUA compared to the web based front ends.

For the purposes of patch submission, reviewing, etc, I think that web based clients are really not sufficient due to the lack of threading (as I would see it in a traditional email client).

> it's that you're asking people to effectively change their entire workflow for interacting with email just so that they can contribute.

There are a number of steps one has to take to contribute to a project. Reading documentation, installing the software, documenting the bug they're proposing to fix, discussing the approach with project maintainers, implementing the change, testing the change, submitting the fix, responding to reviews, etc.

Just submitting the patch is a small part of the overall process. For example, a contributer would have to set up the development environment such that they can run the tests that come with the project. That in itself could be a bit more work than figuring out how to use git send-email to submit the patches.

> MUAs are harder to set up. Refer to aforementioned points about blocked ports, confusing IMAP/POP3 deletion semantics

It's easy enough to see whether or not ports are blocked by attempting to connect to the SMTP, POP/IMAP servers. As for the "confusing [...] deletion semantics", I have never encountered an issue where I accidentally deleted all my email in the last 22 some years of using email while using my local MUA.

ycmbntrthrwaway9 tahun yang lalu

Some people hate web as much as you hate email.

Email is ancient, web is bloated.

fake-name9 tahun yang lalu

To be clear, I don't hate e-mail, and you could probably construct a UI for a mailing list that's nice.

On the other hand, doing so would basically just be re-implementing github/gitlab/gitea with a much less optimal storage backend.

mememachine9 tahun yang lalu

Web is far more usable

The big difference here is that you seem to hate web for what amounts to meaningless ideology, whereas people like me hate email for very practical reasons.

zAy0LfpBZLC8mAC9 tahun yang lalu

I hate web because it provides a user interface instead of a programming interface.

If I don't like the existing user interface to a standardized machine-readable protocol/format, I can write my own user interface for my own needs, as can anyone else, which has two big advantages: People with different needs can have user interfaces that match their respective needs, even while working on the same project, and that leads to easier innovation (when people share their respective solutions).

Now, github currently provides the low-barrier solution that seems to be good enough for many people, which is why the development of tools for email-based workflows is stagnating, instead building more lock-in for github, and preventing any serious improvement in workflows.

So, your hate for email is for practical reasons, but those practical reasons are not inherent properties of email, but rather the result of github trying to capture the market for later exploitation, and you are happy to help them for the momentary convenience, while probably not realizing how much potential convenience you are missing out on as a side effect.

notriddle9 tahun yang lalu

> I hate web because it provides a user interface instead of a programming interface.

https://api.github.com/

zAy0LfpBZLC8mAC9 tahun yang lalu

Which is mostly missing the point.

First of all, github is not the web, and much of the web does not have an API (and I don't have a clue how good the github API is).

But more importantly, even if they have an API: Is there any legally binding committment on their part that that API will be a reliable basis for me to build on for the next 20 years or so, assuming they still exist then? Won't they change it as it suits their needs, in particular their business needs?

A "programming interface" that I can't rely on in the long run is still kindof a user interface, as I have to bother with it whenever it changes. It's a real programming interface only if I can build an abstraction on top of it and essentially forget the layers beneath.

jcranmer9 tahun yang lalu

This is how you submit a patch to an email list: 1. Clone the repository locally 2. Make the fix 3. Run $VCS email --to=<list> 4. Done!

This is how you submit a patch via github: 1. Clone the repository locally 2. Make the fix 3. Fork the repository on GitHub 4. Push your changes to your GitHub fork 5. Go through several screens to make a pull request on GitHub.

(This is assuming you have a GitHub account. If you don't have one, or if you don't know its UI well, insert several more steps in the middle.)

For a casual contributor, sending a patch via email is quite easier than doing it in the web. There are of course downsides to both approaches, but please don't pretend that there are no reasonable objections to web UIs.

ufmace9 tahun yang lalu

Exactly how does it know how to send email from the command line? I'm using gmail. Am I supposed to figure out how to configure gmail for SMTP, put the server and creds in a config file somewhere, and hope I don't bump up against any ISP firewalls or Google security tricks?

Or see Manishearth's comment above.

Meanwhile, you may have to create a Github account and fork the repo for PRs, but I don't see any way for that to not be trivial. Yeah, you gotta know Git, but at least Github has nice easy buttons to guide you through doing things.

carussell9 tahun yang lalu

> Meanwhile, you may have to create a Github account and fork the repo for PRs, but I don't see any way for that to not be trivial

It's been said. You do it with a service built upon the traditional currency of open source: patches. GitHub-style pull requests are not an intrinsic requirement even for the kind of shiny web UI that GitHub wanted to build. It was, however, an important part of GitHub's lock-out strategy.

If you build your startup so that the way that person B has to get their changes to person A is through a pull request, then you can make sure that not only is person A active in the market for Git hosting, but person B is, too. They'll need to throw their changes up on some Git hosting service, because it has to live somewhere. And if your startup happens to be a Git hosting service, that's good for you. And, hey! since it's a pull request, you can do more than strongly suggest that person B hosts their stuff with you, you can force it, by making it impossible for the pull request to come from off-site.

You can't do that kind of underhanded "growth hacking" if you allow contributors to submit patches, because while pull requests are indirect, patches are self-contained. They are a unit of change.

(I've referred to this in the past as using a strategy of dark patterns inspired by social networks.)

I want to emphasize: "patches vs pull requests" is one matter, and "email vs web UI" is an entirely different matter. It's a 2×2 matrix, not a dichotomy. But this conversation has (annoyingly) run on as if it is "patches (which must be done through email) vs pull requests (which are done through point and click)". There's nothing that precludes GitHub from having built a web UI where today's "pull request" button ended with a "submit patch" button in its place. Nothing.

> I don't see any way for that to not be trivial

Yes, this is clear every time the conversation comes up. Something has happened wrt GitHub that causes people to a) forget how things looked before GitHub, b) have extreme difficulty imagining that things could work any other way—even when the other way is more straightforward and less convoluted than the way GitHub actually works. It's kind of nuts.

mememachine9 tahun yang lalu

It does leave a bad taste in my mouth that github is required, and they could easily do something about it. If they were open about it i probably wouldnt care, but this seems deceptive.

hueving9 tahun yang lalu

Have we really reached the point where developers don't understand how to setup email? If so, then you're probably right and developing via email is going to be harder for them.

u801e9 tahun yang lalu

> Am I supposed to figure out how to configure gmail for SMTP,

Not to be condescending, but you can get the necessary information for doing that by using your favorite search engine.

> put the server and creds in a config file somewhere, and hope I don't bump up against any ISP firewalls or Google security tricks?

You could test that by trying to telnet to the SMTP server on the ports they claim to accept connections on. ISPs may block port 25, but they usually don't block ports for secure SMTP connections (like 465 or 587).

As for security tricks, you can always try sending an email to yourself or another email account for testing.

ufmace9 tahun yang lalu

Knowledge is about how to do things. I think we both have enough to figure out how to get a task like that done.

Wisdom is knowing how to choose the simplest possible way to get a job done, i.e. knowing what not to do. I have enough to know which solution I'd rather spend my time on. Do you?

u801e9 tahun yang lalu

I think it really comes down to the conventions of the project that you wish to contribute to. Anyone is welcome to suggest improvements to the established workflow, but it really isn't productive to rant about something that really should be a non issue.

justinclift9 tahun yang lalu

Just to point out, for drive by commits (eg typo fixes, etc), GitHub is super simple:

  1. Go to the file in GitHub you want to change
  2. Click the "Edit" icon
  3. Click the "Create Pull Request" button

There's no need to create a fork and branch manually any more, GitHub does it automatically behind the scenes. It's a useful optimisation. :)

tracker19 tahun yang lalu

Though I really wish that GH would cleanup the fork on your profile when the PR is closed, or offer an easy button to nuke those... Minor niggle.

justinclift9 tahun yang lalu

Yep, that would be useful. :)

ajdlinux9 tahun yang lalu

A casual contributor is more likely to already have a GitHub account than to have git-send-email configured correctly.

mi100hael9 tahun yang lalu

Most maintainers aren't looking for "casual contributors." It's a huge pain in the ass to have someone open a half-baked PR and then never respond to feedback or support questions.

tracker19 tahun yang lalu

Depends on the patch... if it's a typo fix on a readme, or updated url in a documentation file... you click the edit button on github, save, then create PR button after... easy peasy.

It really depends on what you are trying to do in terms of what the process is.. generally, if you aren't a contrib, you will fork, and work from a branch on your locally cloned fork.. you push to that branch, and then create a PR upstream. You may create a local ref to the upstream branch in order to facilitate updates to your fork, and for handling squash/rebase scenarios.

A lot of this is simply git... the "fork" on github creates a github hosted remote copy of the upstream project. The PR is a chance to review upstream patching. Yes, this can be done via email... but you can also do a lot of things in email, that email is a bad user experience for.

y2kenny9 tahun yang lalu

This is how you submit a patch to Gerrit: 1. Clone the repository locally 2. Make the fix 3. Run 'git push origin HEAD:refs/for/master'. Done (without needing to setup SMTP.)

kiallmacinnes9 tahun yang lalu

Better yet, install `git-review`, a project that came out of OpenStack's use of Gerrit.

1. Clone the repository locally 2. Make the fix 3. Run 'git review'. Done (without needing to remember that annoying refs/for/foo syntax.)

[deleted]9 tahun yang lalu

lmm9 tahun yang lalu

Compare like with like, don't count screens one way and count preconfigured command lines the other way. If you have $VCS set up nicely, it's a one-liner there. If you have GitHub set up nicely, it's a one-liner in GitHub too. If you don't have $VCS set up, it's a large number of obscure manpages. If you don't have GitHub set up, it's a couple of clicks in a friendly UI (and actually far fewer clicks than you list, these days).

mememachine9 tahun yang lalu

Thats actually a good point

ycmbntrthrwaway9 tahun yang lalu

I don't hate any and use both every day.

ycmbntrthrwaway9 tahun yang lalu

> First, you generally have to join a mailing list, which is regularly broken, or requires someone somewhere to manually acknowledge your membership.

You can usually just send your patch to mailing list without joining at all and you will be replied off the list.

> Then, you have to figure out how they want shit formatted, figure out how to generate a diff (I've been using SVN for 8+ years, git for ~3 years, and have never had to deal with diff files!)

Unbelievable. The only explanation I can find is that you avoided dealing with diffs and used SVN only on your workplace.

> Plus, just reading mailing lists is a fucking disaster. Literally no mailing list host I know of lets you just view a complete topic thread in simple chronological order on ONE PAGE.

Mailing lists are supposed to be read in your email client. If you want an archive, use NNTP archive like gmane.

fake-name9 tahun yang lalu

> You can usually just send your patch to mailing list without joining at all and you will be replied off the list.

News to me. The few times I've gone through the hoops, the ML's have said things like "you have to join to send mail". I think there's at least one ML I'm still waiting on the join confirmation mail.

> Unbelievable. The only explanation I can find is that you avoided dealing with diffs and used SVN only on your workplace.

No, you see there are other ways of interacting with shit like that. With tortoisesvn and tortoisegit, I maybe have to use the command-line git once or twice a month, and that's generally for unfucking coworkers merge-attempts. There are also other ways of dealing with merges, like actual tools for that (winmerge, meld, etc...). I don't see any reason to actually deal with the underlying diffs basically ever.

> Mailing lists are supposed to be read in your email client. If you want an archive, use NNTP archive like gmane.

I was specifically complaining about NNTP archives. I've yet to see a mailing list archive that's readable in a sane manner. And the point is, if I'm a new contributor, I'm not already subscribed to the mailing list, and therefore have no way to reading it in my client, which still doesn't provide a nice "forum-thread" like view which is the best way (in my opinion) of consuming that sort of discussion.

ajdlinux9 tahun yang lalu

In my experience, in communities that use mailing lists for patch submission as opposed to just discussion, it's the norm to keep posting open to non-subscribers. In the Linux kernel we use so many separate mailing lists that to subscribe to all of them when you just want to send a couple of patches would be a complete disaster. Protocol is to keep posting open to everyone and to ensure that you always use Reply To All to keep every list and individual in the loop on replies.

I don't disagree with you though that mailing lists are painful - and I particularly agree that the archive experience is sorely, sorely, sorely lacking.

mememachine9 tahun yang lalu

Why would anyone have to deal with diff files during regular usage?

username2239 tahun yang lalu

Let's say I found a bug in some software I use, and tweaked a few lines to fix it. Now what do I do?

(1) Mail a diff to the author.

(2) Get an account on some random website, "fork" the code, make the tweak again, and "submit a pull request."

I'll choose (1) every time, and will probably just shrug and move on if I'm forced to do (2). I've made a few throwaway GitHub accounts when I cared enough, but I usually don't bother.

vopi1819 tahun yang lalu

I don't like the centralization around a proprietary software, but saying GitHub is a random site isn't fair. A lot of F/OSS people use it. Out of curiosity what happens when you want to submit say a picture to a repo?

username2239 tahun yang lalu

I'm not a graphic designer, so I don't usually do that, but I'd probably email the author or development list. Projects with lots of binary files checked into version control are very different from source code, though, so I don't know how they normally operate.

gkya9 tahun yang lalu

That's what version control is about. Patches upon patches, since SCCS.

fake-name9 tahun yang lalu

Diffs are an internal part of how VC works. There is literally no reason you would ever have to deal with them in their raw format.

zeveb9 tahun yang lalu

> Mailing lists are supposed to be read in your email client. If you want an archive, use NNTP archive like gmane.

Of course, GMANE went down, and when it came back old GMANE URLs are now broken.

I do read all my email in gnus, though, precisely because newsgroup-style mailing lists are so awesome. It's another one of those things: I'm amazed by the lengths people go to in order to justify using inferior solutions like web browsers and web mail when emacs & decades-old software is so much better.

mathgeek9 tahun yang lalu

> Still, being able to submit patches via email is an absolutely necessary skill for everyone who considers himself a hacker.

While I agree it's a good skill, this statement implies that anyone who doesn't use it it somehow arbitrarily "less important" than someone who does, when it comes to contributing to open source.

cx10009 tahun yang lalu

I commented on this in another thread, but I'll repeat it here.

The guy in charge of making the decision weighed the fact that it's closed source, and it still won.

> But to me, the development process is more important than worrying whether a cloud-based service publishes its source code... This is especially not a worry as GitHub is not a walled garden; its extensive SDK allows for downloading any and all data that goes into the platform.

In summary, his reasons were: github has become a social network of open source devs; gitlab has no killer features github doesn't; and Guido prefers github

https://snarky.ca/the-history-behind-the-decision-to-move-py...

My personal feeing on the matter is that proprietary software can harness a lot of talent and usually delivers a better end user experience. For example, the creator of Twitter Bootstrap works for github full time. How else will you get talented people thinking about how to make a product better all day?

Tharre9 tahun yang lalu

If you're worried about losing issues, then just backup them using Github's API and some script[0].

[0] https://gist.github.com/Tharre/706b0d8c3567c1f5346a

forrestthewoods9 tahun yang lalu

I agree relying on proprietary platforms which may shutdown is a good thing. I'd go so far as to say all platforms inevitably WILL shutdown.

But GitHub issues can be exported pretty easily. Exported and saved in the distributed Git repository even.

I think relying on a platform is perfectly fine if you have an exit strategy. I've moved my blog through multiple platforms. I even maintain the domain so old URLs continue to work. Will Medium shut down? Yes. And when it does I'll move my blog again. It won't be the first time and it won't be the last.

manigandham9 tahun yang lalu

> 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

What? That sounds like a problem with the projects, not the people. Why make it so much harder to get contributions?

ghostly_s9 tahun yang lalu

> Python does not use "issues" feature for good.

Interesting, I didn't even know you could disable 'Issues' for a Github repo. Why do I come across so many projects where the dev lets random issues pile up which they clearly have no intention of responding to, then?

komali29 tahun yang lalu

I mean, I want to consider myself a hacker, but I have no interest in OS programming, and everything I am interested in is on Github.

mayneack9 tahun yang lalu

If you subscribe to a github repo you get issue emails by default. So issues could still be "backed up" by email on github.

theamk9 tahun yang lalu

> 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 "issues" feature for good.

um, no? PEP-512 ( https://www.python.org/dev/peps/pep-0512/ ) is pretty clear about it:

"The code review history does not have the same implicit backup mechanism as the repository itself. That means a daily backup of code review history should be done so that it is not lost in case of any issues with GitHub."

corndoge9 tahun yang lalu

The emailed patch model is still incredibly popular and combined with an application such as Patchwork remains efficient.

good luck not messing up the formatting with a modern client

$ git send-email

GitHub is easier to get started with but both methods have their benefits. I personally prefer GitHub but don't have problems contributing to projects that use the emailed patch model.

laurentdc9 tahun yang lalu

> $ git send-email

Ah, thanks. If I only had known! :)

Maybe someone at OpenWrt (with edit access to the Wiki and such) could write a simple script for git send-email with a wrapper for the [PATCH] [architecture] what subject and Signed-off-by thing. Would speed things up quite a bit imho, especially for newcomers. I see quite a few "not formatted properly" rejections.

ycmbntrthrwaway9 tahun yang lalu

It is up to you to put "[architecture] what" into your commit message. Signed-off-by is a legal procedure, it should not be automated, you should do "git commit --signoff" yourself. "[PATCH]" is added by "git send-email".

If you don't want to setup your client properly and keep using some GUI or Web client, you can format your patch with "git format-patch" and submit whatever files it produces.

OpenWrt rightfully expects you to read at least "man giteveryday", which is titled "A useful minimum set of commands for Everyday Git" and includes "format-patch" and "send-email" in "INDIVIDUAL DEVELOPER (PARTICIPANT)" section.

cyphar9 tahun yang lalu

Signed-off-by is automatically added to commits if you add "-s" to the git commit command. In addition, git format-patch (and thus git send-email) already adds [PATCH X/Y] to the subject line (prepended to the short commit message).

Which part of this needs to be better scripted?

jwilk9 tahun yang lalu

Adding -s every time is too much work, so I added this to my git config instead:

  [format]
          signOff = true

ycmbntrthrwaway9 tahun yang lalu

Just don't add it to global config

fake-name9 tahun yang lalu

The entire part where this shit happens using email.

cyphar9 tahun yang lalu

% git send-email

Wow. So hard. So many characters.

LeanderK9 tahun yang lalu

i don't like centralising development on github, but i welcome the competition for more user-friendly systems. I think the pressure is increasing for other service to provide an equal experience both for exploring an contributing to a project.

tyteen4a039 tahun yang lalu

The closest competition to GitHub seems to be GitLab at the moment, but I heard it's slow to some users. The UI also felt a bit "off" to me (primarily because I'm used to having code, not the README, as the index page of a repo)

I have my private projects on GitLab because it's free. (BitBucket before that; good riddance)

cderwin9 tahun yang lalu

I definitely wouldn't say gitlab is slow in the empirical sense, but browsing repos is definitely a bit more sluggish than github. Maybe it's just more noticeable since it's an SPA.

I say that as a someone who uses gitlab for all of my personal projects.

gulaschbrot9 tahun yang lalu

My university uses gitlab and it feels very slow. Pushing changes takes 5-10x longer than anywhere else, even from the university network. (compared to github or even my server sitting at home on a normal home DSL connection)

ycmbntrthrwaway9 tahun yang lalu

https://gitea.io/

newman3149 tahun yang lalu

It's even worse with ddwrt. =(

I've pretty much given up hope that any of these *-wrt devs take security or dev seriously.

zeveb9 tahun yang lalu

> good luck not messing up the formatting with a modern client

I wonder how 'modern' a client can be if it can't even post source code properly.

[deleted]9 tahun yang lalu

aljones9 tahun yang lalu

I agree, but there are risks in using a proprietary platform for this. See sourceforge.

di9 tahun yang lalu

More details on the decision:

https://snarky.ca/the-history-behind-the-decision-to-move-py...

fairpx9 tahun yang lalu

this just adds to the mystery

misnome9 tahun yang lalu

Why on earth have they done:

> Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017

Rather than just

> Copyright (c) 2001-2017

slizard9 tahun yang lalu

This is why: "For software with several releases over multiple years, it's okay to use a range (“2008-2010”) instead of listing individual years (“2008, 2009, 2010”) if and only if every year in the range, inclusive, really is a “copyrightable” year that would be listed individually; and you make an explicit statement in your documentation about this usage."

Source: https://www.gnu.org/licenses/gpl-howto.en.html

uiri9 tahun yang lalu

Every year from 2001 to 2017 inclusive is listed so this is not the reason.

slizard9 tahun yang lalu

Sure, in this particular file every year in the interval is listed, but in a large codebase that's not always the case. Always listing every year keeps things simple, consistent, avoids complications around extra statement and clauses, and makes auto-generating headers easier.

vortico9 tahun yang lalu

Can anyone point me to a resource of the advantages of including copyright dates? I've worked with IP lawyers who consider them to be legally useless. Copyright is applied to a work upon creation and expires n years after the death of the developer. The year of creation has nothing to do with copyright, unless you're trying to prove who created the work, but a year in the copyright notice is a poor way to do this.

eslaught9 tahun yang lalu

I believe if the work is a "work for hire" (i.e. you were paid by a company to do it instead of doing it for yourself) then the timer for copyright expiry starts on the date the work was put into a tangible medium (rather than after the author's death). So assuming some Python developers do that work on company time, then those copyrights are owned by the company and it is legally relevant to include the year.

vortico9 tahun yang lalu

Oh sorry, you're right. I had my mind in individual hobbyist software projects. For a project with as many contributors as Python, the copyright date should definitely be listed to avoid trying to contact the developers (most of which will be long gone) for the date of creation once you believe the copyright has expired.

makecheck9 tahun yang lalu

A couple of technical reasons might be: ensuring that you can "grep" for any 4-digit year and find applicable files; or, that a "diff" makes it more obvious what is being added.

I prefer ranges personally. Also, I believe only the year of first publication is technically required anyway.

jobigoud9 tahun yang lalu

> Also, I believe only the year of first publication is technically required anyway.

Surely adding later years must have the effect of pushing the copyright expiration date?

ponco9 tahun yang lalu

Not sure about US law, but in Australia, Copyright notices are not required at all, they're granted automatically under the law and only serve as a reminder -- so it's irrelevant.

ufo9 tahun yang lalu

Since 1989, you also don't need copyright notices in the US

https://en.wikipedia.org/wiki/Berne_Convention

sarreph9 tahun yang lalu

milesrout9 tahun yang lalu

You don't even have to put the dates at all. Copyright notices with dates are stupid, especially when they're in every file and require you to touch every file yearly to update them.

bbcbasic9 tahun yang lalu

You don't even have to have a copyright notice at all.

IANAL, TINLA

mrtbld9 tahun yang lalu

Perhaps because explicit is better than implicit.

Kiro9 tahun yang lalu

OT but why do you need to state any year at all?

ajdlinux9 tahun yang lalu

I'm not sure why, but I've seen this elsewhere - in particular I think it's FSF policy to number every year individually.

[deleted]9 tahun yang lalu

agentgt9 tahun yang lalu

This is a little disappointing for several reasons. I understand the merits of GitHub but I really wish Python at least stuck with Mercurial repository and some decentralization.

It's especially sad because Mercurial is just now starting to be incredibly powerful with evolutions.

I guess I'm an old fart but all the centralization has made me paranoid and I still absolutely prefer Mercurial (albeit with plugins) over git.

dbcurtis9 tahun yang lalu

Bah. Anybody can clone a git repo. It's trivial to move off of github with a git repo if they want, or possible to migrate to another database if they want to go through the disruption.

Going to git is about gaining developer mindshare. There are more people using git now. So being on git will bring in more "drive by pr's". I know for my part, life is too short to keep current on multiple source code control tools. I've done plenty in my time, but git is where I'm at now. I use git now at work, and until now, all of the hobby projects that interested me except for 1, were on git. Now all are on git.

At PyCon 2016 Guido told the story of how Mercurial was selected over git. It seemed like an even match at the time. Guido is very source-code-control-tool-agnostic. But git is the current best path to enabling more people to help with cpython development.

agentgt9 tahun yang lalu

It is hardly trivial to move off. Bugs would have to be migrated, links updated, documentation, automated build systems, workflow as well as user remapping.

While not being Mercurial is one thing it is really more about being on GitHub that is the problem. Kings will get complacent (remember how long it took to GitHub to add some features).

I also vaguely remember the github guys trashing Mercurial with arguabley a propaganda campaign (something "git is better than X"). All that content is missing now but I do remember (I'll have to look on way back machine later).

jsmeaton9 tahun yang lalu

You mention decentralization a lot, but nothing has really changed. All cpython devs still have a full clone on their machines. GitHub functions as a hub now rather than https://hg.python.org/cpython.

agentgt9 tahun yang lalu

I must have missed some things but they not only switched repository formats they moved the central to github [1]. All opensource projects on github is centralization in my book creates unfair leverage that github has and will have.

For people to work on Python they now have to share information with github which they may not want (they have to create an account and are probably tracked).

1: https://docs.python.org/devguide/setup.html

tracker19 tahun yang lalu

Two things, that's also an advantage... and the vast majority of programmers I know have a github account anyway. Github has made it very easy to access/port everything in and out if you choose to do so.

Git itself is decentralized. Some of github tools are centralized, but that has both advantages and disadvantages, and I and a lot of others feel the advantages outweight the latter.

agentgt9 tahun yang lalu

Like I said I don't argue with merits of github greatly widening the audience but I like said in other sibling threads github is more than just the source control itself: it is bugs, content, workflow, etc.

I guess I'm just becoming more Stallman in my age but I don't like my development life turning into Facebook. I can't even communicate with a large portion of family and friend with out resorting to using FB. A platform without doubt tracks the hell out of you. And you could argue the web is decentralized (aka your comment Git itself is decentralized) so Facebook is not that bad but is it? Does that really matter?

tracker19 tahun yang lalu

I can respect that... however, sometimes it's not worth fighting... you can export your bugs, content, etc from github, and import into self-hosted gitlab, or other options if so desired. Then you lose the community aspect, but it's not exactly hindered.

I just don't see GH turning into SourceForge. I know it can happen, doesn't mean it will, and if they (GH) ever head down that path, people will exodus.

agentgt9 tahun yang lalu

GitHub is far more intrusive than SourceForge (don't get me wrong on quality though... SF is a piece of crap). Remember GitHub has a lot of people's credit cards! Even Facebook doesn't have that.

GitHub could easily some day sell user information (if they are not already). The could sell it to recruiting companies (like my own company) or they could sell it even to ecommerce companies like Amazon.

Comparing GH to SF is not really even remotely useful because things have changed so much (in terms of technology, biz models, users ...etc ).

collinmanderson9 tahun yang lalu

Mercurial still doesn't have Python 3.x support. I imagine that's an extra encouragement for the Python devs to switch away from it.

16bytes9 tahun yang lalu

Why would it matter if mercurial has python 3.x support? For writing hooks and extensions?

The mercurial team prioritized end-user features, like evolve, over moving to Python 3, which would only affect a very small number of mercurial users (mostly devs).

I've personally moved to Python 3 for most development and not once have I encountered a case where I couldn't do something in mercurial that would have been possible if the core code was on python 3.

BuckRogers9 tahun yang lalu

That's how the CPython core devs think. They believe they're punishing Mercurial for not moving to Python3.

16bytes9 tahun yang lalu

That's a completely unsupported assertion.

Why would the CPython devs punish one of the largest and well known python projects by moving to a non-python DVCS? That would create an absolutely toxic effect in the python community.

They didn't move from mercurial because of python any more than they moved to Git because they like C.

jwilk9 tahun yang lalu

[citation needed]

glogla9 tahun yang lalu

Yes, this is disappointing on many levels. Github is proprietary, semi-monopolistic (in the way Microsoft holds semi-monopoly on desktops) and it's also nest of reactionary vipers [1].

Python community is full of cool and nice people. I guess I expected more from them.

[1]: https://news.ycombinator.com/item?id=9966118

tbrock9 tahun yang lalu

Wow if only we could get Gnome and Linux on there and give up this mailing list for patches nonsense we'd be golden.

Fice9 tahun yang lalu

This is scary. For increasingly many potential contributors a project effectively does not exist if it is not on GitHub. And, being a huge centralized service, GitHub is very susceptible to censorship (e.g. repos being taken down via DMCA or Russia blocking GitHub until they started to cooperate with the censors). I see this dependence as very bad and dangerous for the free software movement. Should we even consider convenience of a service that has serious ethical issues?

chaostheory9 tahun yang lalu

Why is it scary? Is it that hard to move to bitbucket, gitlab, or another alternative git host if needed?

Fice9 tahun yang lalu

This is not about how hard or easy it is to move from GitHub. What scares me is that it is increasingly hard to participate in the open source/free software community without using GitHub, and it is increasingly hard to find contributors for your own project if you are not willing to host it there.

chaostheory9 tahun yang lalu

Why is it scary to use Github? Is there some hidden cost that people aren't aware of?

Fice9 tahun yang lalu

The programming community became globally dependent on a single commercial company. Using GitHub would mean contributing to that dependence and monopolization even more.

chaostheory9 tahun yang lalu

Is anyone really dependent when the cost to switch to a different provider is low? You haven't given a good reason.

Fice9 tahun yang lalu

It's not just about moving data from one provider to another. GitHub is not simply a hosting service, it's a large centralized social network, and the cost of switching from it includes reduced project visibility and disconnection from the community.

chaostheory9 tahun yang lalu

These may be issues for smaller projects, but I don't feel that either visibility or community is a problem for a project like Python. They have the luxury of going wherever they want and people will follow.

wyldfire9 tahun yang lalu

It's not hard, IMO.

But it would be nice if these critical projects created gitlab or bitbucket mirrors.

bastawhiz9 tahun yang lalu

> repos being taken down via DMCA or Russia blocking GitHub until they started to cooperate with the censors

Is this not the case with other hosts? If Gitlab got a DMCA notice, would they not be forced to comply? I don't think this is a good argument against Github.

Fice9 tahun yang lalu

Being removed from one of many interchangeable hosting services is one thing. Being removed from the one central service that everyone around insists on using is another. GitHub, due to it's extreme popularity and centralized nature, is becoming the global gatekeeper for the programming community.

[deleted]9 tahun yang lalu

ianai9 tahun yang lalu

Bitbucket does exist though.

EvgeniyZh9 tahun yang lalu

I'd really like more big and important projects would move their development to GitHub-styled services. Maybe I'm just not hardcore enough, but I feel they make live easier, both for maintainers, contributors and newcomers.

But it's probably too hard to switch and core developers don't see point in it (since they're totally ok with working their way). Maybe when a new generation developers will take core positions...

hvidgaard9 tahun yang lalu

The idea of GitHub is great, and frightning at the same time. The development community as a whole would be crippled if GitHub went under. Same thing with StackOverflow.

I'm still dreaming of a decentralized GitHub based on something like ipfs.

EvgeniyZh9 tahun yang lalu

Well, local running copy GitLab (or something other GitHub-styled) with a couple of backups is pretty safe and still gives all the advantages of GitHub.

Decentralized GitHub is a nice idea. We gotta implement this)

anamoulous9 tahun yang lalu

Wow the black bar settled it for them, huh?

ambivalence9 tahun yang lalu

I know you're joking but just for the record: this process was started in late 2015, it's a surprisingly complicated endeavour to switch source control hosting.

[deleted]9 tahun yang lalu

hueving9 tahun yang lalu

Sad day. Don't forget that github is a closed source tool. This is equivalent to them announcing they are switching to Jira.

Karunamon9 tahun yang lalu

Both of those products allow for trivial data import/export. What exactly is the problem?

hueving9 tahun yang lalu

They are closed source. People that are really serious about open source software from top to bottom have issues with dependencies on closed source tooling because it promotes an ethos they don't support.

[deleted]9 tahun yang lalu

Karunamon9 tahun yang lalu

Ah.. I was hoping there was a substantial practical reason that I had overlooked.

hueving9 tahun yang lalu

Ah, the classic open source freerider. Only support it when convenient, ignore every other situation.

a3_nm9 tahun yang lalu

They are using pull requests on Github, and I don't think that these are trivial to import/export.

emidln9 tahun yang lalu

This is well-documented[1] in their API. You can list a repo's PRs and the associated metadata/links that make most of the github ui work (code reviews, linked comments, commit statuses, etc).

[1] https://developer.github.com/v3/pulls/

a3_nm9 tahun yang lalu

Having a documented API is nice, but I still wouldn't call it "trivial" to migrate out of.

Besides, we don't know if this API is going to stay around forever or whether it will be discontinued. (Unlike, e.g., the git repository itself, which will always be self-contained so easy to migrate away if needed.)

jwilk9 tahun yang lalu

https://news.ycombinator.com/item?id=13614253

jaimebuelta9 tahun yang lalu

Background info about why this migration and considered alternatives

https://snarky.ca/the-history-behind-the-decision-to-move-py...

dbalan9 tahun yang lalu

So python eventually moved to git from mercurial.

harry89 tahun yang lalu

I'm not sure that's correct.

https://hg.python.org/cpython/

kzrdude9 tahun yang lalu

It is, though

harry89 tahun yang lalu

Well that sure settles things. I'm totally sure now.

Guido's last commit, in both the github repo and the mercurial repo.

https://github.com/python/cpython/commit/934aba66ef09e94422b...

https://hg.python.org/cpython/rev/3db1959c2c53

Someone sensible may be able to shed some light on it. Presumably there's a bridge between the two somewhere.

detaro9 tahun yang lalu

Per PEP 512 (https://www.python.org/dev/peps/pep-0512/):

This PEP outlines the steps required to migrate Python's development process from Mercurial [3] as hosted at hg.python.org [1] to Git [4] on GitHub [2]

[...]

The fate of hg.python.org

With the code repositories moving over to Git [4] , there is no technical need to keep hg.python.org [1] running. Having said that, some in the community would like to have it stay functioning as a Mercurial [3] mirror of the Git repositories. Others have said that they still want a mirror, but one using Git.

As maintaining hg.python.org is not necessary, it will be up to the PSF infrastructure committee to decide if they want to spend the time and resources to keep it running. They may also choose whether they want to host a Git mirror on PSF infrastructure.

int_19h9 tahun yang lalu

https://snarky.ca/the-history-behind-the-decision-to-move-py...

[deleted]9 tahun yang lalu

xapata9 tahun yang lalu

It's less about the VCS than the GitHub community.

milesrout9 tahun yang lalu

I dislike Hg, but I'd much rather use Hg than have anything to do with the GitHub "community".

xapata9 tahun yang lalu

Okay. The time to express those sentiments was back when PEP 512 [0] was being discussed.

[0] https://www.python.org/dev/peps/pep-0512/

tedmiston9 tahun yang lalu

Is one a mirror of the other?

gigatexal9 tahun yang lalu

Python 3.7 already in the works. The effort to push python 3.x is picking up steam it seems.

akuchling9 tahun yang lalu

Nothing surprising there. The version bump for 3.7 would have been committed immediately after branching off the 3.6 release branch.

echelon9 tahun yang lalu

I can't help but think Gitlab would have been in contention for this move had they not had the recent outage. Can anyone from the Python org comment on what other choices were considered?

detaro9 tahun yang lalu

All this has been decided for months and the discussion about has been going on for more than a year, so no, no recent outage could have been a factor. PEP 512 mentions why GitHub was choosen over GitLab.

https://www.python.org/dev/peps/pep-0512/

tomcam9 tahun yang lalu

tl;dr -- Devs are more familiar with Github, and Python's creator also prefers it (he modestly agreed to go with whatever the team decided and it appears they very much wanted to grant him the courtesy).

rectangletangle9 tahun yang lalu

Where is the "issues" section? I wanna read about some gnarly low-level CPython bugs!

Other than that, this is a welcome change.

_ZeD_9 tahun yang lalu

http://bugs.python.org/

meneses9 tahun yang lalu

FYI, Python was on Github but it was the read-only version. You still had to go to mercurial to push the updates.

lucidguppy9 tahun yang lalu

I wish PR's on github could be checked off per commit like in bitbucket.

faraggi9 tahun yang lalu

Anbody know what happend to Guido's contributions between 2008-2012?

Maybe he had kids. :P

napolux9 tahun yang lalu

Still waiting for WordPress to move. ;)

hayd9 tahun yang lalu

and nearly 100k commits... time to start making some PRs!

imode9 tahun yang lalu

I'd question why it wasn't GitLab but after the recent outage it would somewhat be in bad taste. :P

what exactly was Python using before/where was it hosted? all I can find are the source archives on python.org. I'm assuming this wasn't a hard transition but I'm genuinely curious as to their development strategy regarding distribution of source.

grzm9 tahun yang lalu

There are at least two comments in this thread that address this issue:

- https://news.ycombinator.com/item?id=13633369

- https://news.ycombinator.com/item?id=13633271

bombless9 tahun yang lalu

dustinmoris9 tahun yang lalu

(1)

gkya9 tahun yang lalu

This is FUD. There are sensible responses to this comment, so I won't write a new one, but say one thing: You don't know how to use conventional tools, and and go on to blindly rant about them.

> Basically, e-mail is the death of any sort of low-effort contribution. If you're starting a new project, and chose a mailing list, you're probably excluding a huge quantity of potential contributors.

If those contributors are as incompetent to not be able to mail a patch, I'd rather be happy to have excluded them.

dang9 tahun yang lalu

> You don't know how to use conventional tools, and and go on to blindly rant

That crosses into personal attack and incivility, which breaks the HN guidelines regardless of how wrong someone else is. Please don't post like this here.

We detached this subthread from https://news.ycombinator.com/item?id=13631069 and marked it off-topic.

fake-name9 tahun yang lalu

I think the core issue with your response is, unless the project in question is the "conventional tools", why do you seem to think knowing those tools is even germane to the quality of someone's contributions?

I write python and some C++ stuff for fun in my free time. If your project interests me, but I have to spend said free time to learn esoteric tools to interact with it that aren't needed elsewhere in my life, how do you figure that's valid?

It's not that I couldn't learn to deal with that kind of shit, it's that I don't see why I should bother. If everything else works without e-mailed diffs, all that does is make anyone with more then one hobby project do is look elsewhere.

gkya9 tahun yang lalu

One way or another, one has to learn the conventional communication tools if they want to contribute to any open-source project, be it GitHub or GitLab, or a mailing list and debbugs. The maintainers get to decide and it's their way or the highway. The project is theirs.

Some skills only serve one purpose. Like shaving. I learnt how to shave when I was a teen, and that skill has only been useful to me in shaving my face, since ten years. And being able to use email and diffs is a transferable skill.

I won't respond to you anymore, as I dislike your language and your contributions are trollish.

Manishearth9 tahun yang lalu

See https://news.ycombinator.com/item?id=13632352 . It's not a simple matter of just sending an email. You can't send patches via gmail (because it autoconverts tabs to spaces), and setting up a client is involved, hard (impossible for some), and should be totally unnecessary.

I despise this "I'm happy to exclude people too incompetent to do X" attitude. I often mentor people into FOSS. They start off pretty incompetent with the tooling. With a bit of nudging they end up making high quality contributions. A person's usage of email has no bearing on their, say, Python skills. Nor does a person's usage of GitHub. These are tools to get the job done, they are not the job themselves. Tools should be easy to use. Github isn't exactly easy, but it's much easier than patch MLs.

PuercoPop9 tahun yang lalu

Can't say that matches my experience, I've never encountered any problems with sending patches as an attachment. And find the process simpler than github.

ajdlinux9 tahun yang lalu

If you send a patch as an attachment to a Linux kernel list, or most of the mailing-list-based projects I contribute to, it will almost certainly be insta-NACKed: maintainers are basically too busy to deal with anything that doesn't exactly match what git-send-email generates.

From a maintainer POV this is honestly perfectly fair - we have tooling like Patchwork that depends on patches being submitted inline. From a first-time contributor POV, this just puts the barrier to entry up even higher. :(

sametmax9 tahun yang lalu

It's not a matter of competence, it's a matter of effort. With github, most things are easily discoverable. With email workflow, you have to relearn a whole black boxed, badly documented custom workflow that you will get wrong several times.

When I spent 15 hours writing a high quality patch for free, I don't want to spend 5 hours more just to send it. I have a life.

mememachine9 tahun yang lalu

Its really obnoxious how many people hate doing things the easy, simple way, apparently just to feel superior.

sametmax9 tahun yang lalu

I once was giving a training getting bored, so I timed how long it took for the dev to write down some simple tasks. The guys using vim and emacs were consistently slower than the guys with the IDE with GUIs.

I get that you can like vim and emacs better, and it's perfectly alright. But don't pretend it's more efficient. There are very few people (I meet one maybe each year) actually efficient with them because they are tools putting the burden of many tasks (reminding states, doing transitions, making very specific selections) on the user instead of the machine.

fiddlerwoaroof9 tahun yang lalu

What language were you using? I wouldn't be too surprised about this if you were using Java or some other language with a lot of boilerplate but I'd be really surprised if this were true of python or a lisp: I'm pretty sure I can finish a simple script in vim in roughly the amount of time it takes to startup an IDE and start a new project. Also, were you letting people use their own vim setup or just a generic one?

sametmax9 tahun yang lalu

Python or JS depending of the training.

People used their laptop.

The others were using PyCharm, notepad++ or Sublime Text.

Users of notepad are the slowest of all though. They are usually beginners.

[deleted]9 tahun yang lalu

mememachine9 tahun yang lalu

hexa-9 tahun yang lalu

I was recently hit by an IPv4 routing outtage and had only IPv6 available to connect to the internet.

I was therefore unable to connect to github.com, as there is no IPv6 support available:

% host github.com github.com has address 192.30.253.112 github.com has address 192.30.253.113