Earlier quoted context omitted.
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…
I get a fair bit of top posted mail that has been sent from Apple Mail. Another thing that Apple Mail does is to pick Unicode characters that don't map to ascii for quote and other punctuation characters.
Why kernel development still uses email
131–140 of 152 posts
Re: Why kernel development still uses email
#132Earlier quoted context omitted.
Best workplace for creative work like programming is a room for yourself. The shared office concept was a mistake inspired by assembly lines. Sharing space with coworkers is good in factories because work is often dull and workers can talk to each other. For creative work, it's nothing but a hindrance.
I work in a team and find it very useful to easily speak with a coworker when necessary. The increased degree of communication has a very positive impact for me. And I don't feel the need to shit on factory work, which I have never done and suspect you never have, when discussing it.
My knowledge about this comes from a befriended work-psychologist who worked with both, offices and factories, since the 70ies.
Re: Why kernel development still uses email
#133Earlier quoted context omitted.
Our team of 10 thinks Gerrit is great. I don't know how these other people are using Gerrit, but I don't recognize their description at all. Gerrit is very convenient if you take code reviews seriously. I do agree that clicking through each file is a waste Well, firstly it is simply not true that you need to do that (you can accept/reject a review without having viewed any file at all), but secondly I'm totally fine…
> Article says: > Gerrit, he said, makes patch submission quite hard > But without any explanation for why. You need to add hooks to inject a Change-Id into every commit, and be careful that they're still "fresh" (e.g. you cannot reuse one from an abandoned branch if you want to re-submit it). And you must push a diff to the server so it can be submitted to Gerrit. If your feature branch is up-to-date (you just force…
If your feature branch is up-to-date (you just force-
pushed it), you cannot submit the same commit to Gerrit.
It sounds to me like this is where it's going wrong. If Gerrit is not also hosting your 'origin' git repositories and acting as a gatekeeper for any commit to be added to it, then you are working against the system.I don't see the problem with hooks and we rarely have problems with Change-Ids not being 'fresh' anymore (that sounds like the result of a suboptimal workflow).
Bugs in plugins are of course not a good reason to say Gerrit isn't very good. That's like saying git itself sucked when the IntelliJ plugin for git still had annoying bugs.
Re: Why kernel development still uses email
#134Earlier quoted context omitted.
I developed a series of patches for the RPi kernel fork. I use the Pi headless, and generally access it from a Windows machine. I never tried to send those patches upstream - and the Pi fork uses Github for such things - but I'm entirely confident that if I tried to paste those patches into an email client somewhere along the line, I'd get an upstream maintainer pointing out that magical line breaks blew something up…
What I read is "I am entirely confident about what would happen if I tried to do something I've never tried to do", which is useless speculation.
Re: Why kernel development still uses email
#135tl;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…
Re: Why kernel development still uses email
#136Earlier quoted context omitted.
Regarding 5. what's wrong with opt-in and mandatory email lists? If you want to reach a team, email team@example.com. When you join a team, email team-subscribe@example.org, or maybe your hr/sysadm will add you to team@example.com. If you want to reach person@example.com - if you're part of the same company, your client does an ldap lookup. Or you have a look at https://example.com/employees.html or contact.html. It…
I think the matter of lists is orthogonal to the issue of global directories . I have ... well, not quite nothing, but little against the concept of email lists. They're useful. I've used them extensively. They don't, of and by themselves, address numerous other problems with email. And they can and do insert a few of their own. Regards lists and directories, I'm not entirely sure what your argument is, but I can int…
Re: Why kernel development still uses email
#137Earlier quoted context omitted.
Email is tremendously complex, uses multiple protocols to accomplish different tasks (or even the same task), and is fundamentally vulnerable to spam and can only be patched with further complex hacks like SPF. Almost everyone now uses HTML email, an ill-defined and insecure idea, adding to the complexity of implementations. If you think that email is a good system, trying setting up postfix, dovecot, sendmail, and w…
My company provides my email access. As all companies do.
Re: Why kernel development still uses email
#138I find the idea that a technology should be replaced simply because it is old to be very irksome. Those developers out there blindly contributing to the trend of replacing "tried and true" with "new and shiny" really need to take a step back and gain some perspective. Email works great for the vast, vast majority of users.
Web development is the absolute worst at this. None of the technology is new, whatsoever (mostly stealing from Lisp, rebranding it, and doing it wrong or calling MVC by yet-another name). It's impossible to quantitatively state that the new tools we use today are any better than the tools we just tossed out yesterday. Because no one became a master at the tools of yesterday. There is no basis for comparison. No exper…
Re: Why kernel development still uses email
#139Earlier quoted context omitted.
I think the matter of lists is orthogonal to the issue of global directories . I have ... well, not quite nothing, but little against the concept of email lists. They're useful. I've used them extensively. They don't, of and by themselves, address numerous other problems with email. And they can and do insert a few of their own. Regards lists and directories, I'm not entirely sure what your argument is, but I can int…
Interesting points. I guess I need some clarification as to what your perceived problem is - it sounds like email is equivalent to the phone system - are you saying you prefer facebook etc as a global directory, as opposed to specialized directories run by organizations?
Re: Why kernel development still uses email
#140Earlier quoted context omitted.
I get a fair bit of top posted mail that has been sent from Apple Mail. Another thing that Apple Mail does is to pick Unicode characters that don't map to ascii for quote and other punctuation characters.
You mean rich text quotes?
If you view it in an ascii-only mail client you will see plenty of places where an ascii character could have been used but instead a visually similar code point has been chosen. Things like dashes, single and double quote characters.