81–90 of 152 posts
tl;dr: my wish is a code review convention for git-notes and a friendly UI on top. If only Git would allow storing reviews and issues in the repo proper. Something like Git notes with conventions to refer to files/lines in a file/different revisions etc. Something similar to Fossil. This would solve half of the problem. The other half would be the UI layer. Now the reviews live in a database, outside of the repo, and…
Earlier quoted context omitted.
Outlook loves messing with messages. "Detecting and removing" extra line breaks is one of its features
Outlook it probably the worst email client currently on the market and has been for the all of it's existence. It is my belief of the issue at lot of people have with email stems from Outlook. One example is the weird instance of top posting has made it hard to read many conversations and fostered a mentality of firing of quick response, reducing Outlook/email to a poor mans IM client. There's a ton of improvements t…
Is Gerrit really that terrible? I do agree that clicking through each file is a waste, but I love the ability to work on several different reviews and keep track of their different build statuses. Also, where I use it we have different levels of requirements for different branches (more people usually need to approve reviews on soon-to-be-released point branches). We use it for a large project in MLOCs but relatively…
I do agree that clicking through each file is a waste
Article says:
Gerrit, he said, makes patch submission quite hard
It is hard to do local testing of patches in Gerrit,
All discussions are done through a web interface.
So I get and agree with what he's saying about how GitHub duplicated email, but as a millennial who uses Vim, I find GitHub much more intuitive and useful than sending patches via email. In general, I disagree with the issues he has with GitHub - most of them are wishy washy disagreements that could easily be solved by adding things to GitHub or using a chrome extension. IMO the only real, logical reason they need to…
Just try to use GitHub Enterprise for 400 or more users. You get a bare metal image of the virtual machine with no replication, load balancing, etc. Nothing more for a huge price. I don't know how they scaling public version.
Are there any good references online about how to switch from Github-based collaboration to one based on email and patches? I'd like to give it a try and see how it feels.
So I get and agree with what he's saying about how GitHub duplicated email, but as a millennial who uses Vim, I find GitHub much more intuitive and useful than sending patches via email. In general, I disagree with the issues he has with GitHub - most of them are wishy washy disagreements that could easily be solved by adding things to GitHub or using a chrome extension. IMO the only real, logical reason they need to…
Earlier quoted context omitted.
Outlook loves messing with messages. "Detecting and removing" extra line breaks is one of its features
Outlook it probably the worst email client currently on the market and has been for the all of it's existence. It is my belief of the issue at lot of people have with email stems from Outlook. One example is the weird instance of top posting has made it hard to read many conversations and fostered a mentality of firing of quick response, reducing Outlook/email to a poor mans IM client. There's a ton of improvements t…
Another thing that Apple Mail does is to pick Unicode characters that don't map to ascii for quote and other punctuation characters.
As always, it's worth pointing out that this is just about the Linux kernel. Different scale, different developer community, different code structure, different testing/CI methodology (i.e. practically none) than just about every other project out there. Email works for them - great. Other things work for other people - also great. Theirs is one interesting data point, but that's all it is.
>As always, it's worth pointing out that this is just about the Linux kernel. Different scale, different developer community, different code structure, different testing/CI methodology (i.e. practically none) than just about every other project out there. Eh? Patches on mailing lists is the "traditional" way for open source projects to operate. Many projects "still" do things this way - indeed I wish more projects di…