Emacs discusses web-based development workflows
Discussions on ways to "modernize" the Emacs editor have come up in various guises over the past few years. Changes of that nature tend to be somewhat contentious in the Emacs community, pitting the "old guard" that values the existing features (and keybindings) against those who argue for changes to make Emacs more approachable (and aesthetically pleasing) to newcomers. Those discussions tend toward mega-thread status, so it should be no surprise that a query about possibly moving Emacs development to a "forge" (e.g. GitHub or GitLab) got similar treatment. As always in Emacs-land, there are multiple facets to the discussion, including the desirability of moving away from an email-based workflow, accommodating younger, forge-centric developers without forcing existing developers into that model, and—naturally—licensing.
As a newcomer to the emacs-devel mailing list, Daniel Fleischer may not
have expected the voluminous response he got to an August 26
post
asking about the status of a "move to a new VC [version control] system,
e.g. Gitlab
". The somewhat provocative subject of the email, "Gitlab
Migration
", probably helped draw eyes (and responses) as well.
There are no current plans to make a migration of that sort, of course, and
a two-year-old feature
request at GitLab shows a "pretty daunting
" level of work
needed, Dmitry Gutov said.
Richard Stallman had a different
concern:
We used to recommend GitLab as better than GitHub (though only barely acceptable). However, GitLab has got worse, and we should stop recommending it at all.
He suggested that sourcehut or NotABug.org might be a better match from a licensing and philosophy perspective. Other than a request from Emacs co-maintainer Eli Zaretskii for an evaluation of NotABug.org, not much was heard about that development-hosting site in the thread; sourcehut, on the other hand, came up multiple times. Stallman said that any potential solution would need to run on GNU infrastructure, rather than as a hosted service; he was also worried about the free-software status of any JavaScript needed.
In the original post, Fleischer noted two benefits that he saw with a switch to some kind of forge. Because younger developers are more familiar with the forge-style workflow, providing that will lower the barrier to entry for new developers, he said. In addition, not scattering the different portions of the project among multiple systems makes it easier to work with the project:
Having the code + issues + discussions in the same place as opposed to now, where the code and discussions (lists) are in 3 different places (Savannah, Gnu mailing lists and Gnu bug tracker). With a modern VC system, one can jump easily between issues, discussions, code commits back and forth easily as opposed to now, where if it's a bug you can use its number to search lists and commits messages but if it's a discussion, it's not "connected" to anything.
He also noted that an email-based workflow should still be supported, so
that developers can use Emacs for all of their project
interaction, as they do now. Emacs co-maintainer Lars Ingebrigtsen called that "the
biggest hurdle
", noting that it is important not to risk losing the
current contributors; "Can you interact with
Gitlab via a mail-only system?
" While that question was not
directly answered in response to that, the GitLab feature request and other
discussion makes it clear that the answer is "no", at least for now, and it
is not clear that there is any real work going on to change that.
Web advantages?
Philip Kaludercic objected to the idea
that using the web for development tasks was actually any easier, which is
a common response from those who are used to email style. Similarly, he
said that while the various parts of the development process were in
separate places, they share an important characteristic: all are
email messages. He suggested that the "biases against mailing list
development might be illegitimate
", but Ingebrigtsen said that there is a
different dynamic at play:
It seems like it should be easier to just send a patch, but feedback we're getting shows that it's not for a number of developers. Many don't use mail at all for development, and all they're used to is the GitLab/Hub way of doing it.So it's easier for them -- it feels safe and familiar for them to do development by clicking around in a web browser.
On the other hand, Jim Porter explained
that as relatively new contributor, the feeling of intimidation with using
an email-based workflow is real, but it turns out not to
actually be that hard to adapt to it. He said
that maintaining a project using the mailing list might be different, "but that's
not my job, so it's not a problem
for me
". He did suggest some places where the documentation might
be improved for those who are used to the pull-request-style workflow and
plans to propose some documentation patches. But Tim Cross thinks that email is a
dead-end for younger developers:
I think virtually all developers are forced to suffer email, but a [growing] number don't use it. Often, all the discussions, notifications, comments etc are actually consumed via a mobile 'app'. For these users, logging into their inbox is frustrating and inconvenient because their inbox is full of pointless and old messages/notifications/alerts they have already seen/received via other channels. For these users, the primary reason they have an email address is to have something to put into the 'login' box for web services they use. Telling these users to use email to submit a patch is very similar to me being told when I started using email that I had to send in a hard copy via snail mail.
Fleischer concurred, noting that he is in his 30s (half of Cross's self-reported 60s) but only uses email for identity purposes and for receiving official documents:
I don't talk to family, friends or coworkers via mail. Personally, I think it's old, not secure or private by default, very inconsistent (HTML rendering is arbitrary vs. text, multiple MUA [mail user agent]) and just can't imagine using it as a software engineering tool.
The security of email, at least versus the app-centric alternatives, was
hotly contested by some. Zaretskii said that the
"security issues with email have been solved
long time ago
" and that the email-based workflow used where he
works allows his company to "run circles around those of our partners and
competitors
" who do not use it. Cross pointedly disagreed
about email security, however:
Despite what others have claimed, the security problems with email have NOT been addressed. It is still one of the major vectors for compromising access via social engineering, major vector for infection from [ransomware], frequent source of privacy [breaches] and a common means used to get sensitive data out of an organisation. Even having encrypted messages is overly complex for most users and a nightmare to administer for large organisations.
Stefan Monnier thought that the problem was less about email per se, but that mailing lists are intimidating:
I think the issue is not use of email as such, but use of mailing-lists. In my experience the reluctance to use email is that they feel uncomfortable sending email to a potentially large number of persons. In contrast posting on a forum doesn't impose anything on anyone (in their mind) because those who read it have to actively go and look for it.
[ Of course, it doesn't make much sense, really, but this is about people's perceptions, not about anything rational. ]
There are a number of problems with the email-based workflow that
forge-style development alleviates, Clément Pit-Claudel said.
One of those is that mistakes can be edited on a web site, which is not the
case for mailing list; some state tracking and maintainer tasks may be
simplified as well. But Zaretskii was quick to point out various
deficiencies he sees with the web interfaces. He does not think that adding
GitLab (or similar) will provide much to maintainers, it would simply"be more welcoming
to casual contributors
", which is worth doing, but the advantages
for existing Emacs developers are far less clear.
Whatever choices are made, Stallman is adamant
that no "online dis-services
" be recommended for doing Emacs
development. It is fine to have adjunct mechanisms, but email must remain
viable:
It's fine if users have the _option_ of communicating with the maintainers and developers via some interface other than email. (Or ten different interfaces other than email.) But when some of them use it. that must not compel the maintainers and developers to use it too.
Multiple workflows
There is no way to objectively determine which development style is easier,
Fleischer said, so
it is fruitless to discuss it. "I can say objectively that one form
of workflow is more popular than
another so people would be more familiar with it.
" The conversation
soon turned to supporting multiple workflow styles; since there had been
little progress with GitLab, sourcehut was discussed.
Two threads from 2020 were noted; one where sourcehut creator Drew DeVault
self-evaluated
the hosted service under the GNU ethical
repository criteria and another
where Emacs development using sourcehut (either as a service or by hosting
the code on GNU systems) was discussed. At the time of the latter thread,
email-based workflows were supported well, "but what about the GitLab/Github-like
features?
", Zaretskii asked. DeVault pointed to a video
showing "the sourcehut equivalent of the github/lab
pull/merge-request flow
".
That led to further discussion of sourcehut's capabilities with respect to
the needs of Emacs development. Gutov noted
a few different things he saw as "frictions/downsides
"
compared to "the Git**b workflow
". That discussion proceeded
to hash out some of those areas, with DeVault participating and being quite
interested in trying to bridge the gap between sourcehut's current features
and the needs of the Emacs project. In another sub-thread, he summed up the
current status:
First, we would be very pleased to host emacs on our service, or with our software on your own infrastructure. It should more-or-less work with everyone's existing workflows, given that emacs is an email-oriented project, and over time we are developing an improved web-based experience which should allow more and more users access to emacs development over time without necessarily requiring the maintainers or those who prefer their email-oriented workflow to have to change their workflow to [accommodate] a platform like GitLab. We should also rate quite highly in terms of free-as-in-freedom, since the entire service is free software, mostly AGPL.
He did note that the sourcehut bug tracker works differently than the
existing bug
tracker, which is based on an older version of the Debian Bug Tracking System (BTS).
But there are plans to make the sourcehut bug tracker "more
email-oriented
". Though the philosophies of sourcehut and GNU are
similar, Stallman would prefer not
to host Emacs on the service:
I think Drew DeVault is right in saying that his philosophy is close to ours. If we had to use some outside hosting service, I might well say there is no better choice than his. (I don't want to criticize the other options without knowing what they are; they may be equally good.) But we'd rather have this on a GNU machine with GNU Project people managing it.
The sourcehut service is not the only option, as DeVault said in an earlier message:
You can run the sourcehut software on GNU servers, it is 100% free software, mostly AGPL. I would encourage you to do so.
Gutov said, that adopting sourcehut would be a net win, but that there are still things lacking in sourcehut that will be difficult to add in the email realm:
For example, those quality-of-life features that Gitlab has in the browser which I previously figured would be difficult to translate to email (the code review workflow, with inline comments and updates from the branch; automatically updated CI indicators and links to builds; editing of messages) are predictably absent.
Efforts are being made to describe the kinds of web-based features that Emacs would want in sourcehut (or any other forge it might adopt) so that users of the web-based workflow would feel at home. Fleischer listed some of those types of features. But some commenters are still not entirely convinced that adding support for a web-based workflow will lead to more and better contributions. João Távora posted some thoughts on what he has observed:
In recent $DAYJOBs I worked with these two GL/GH platforms fully, using them liberally and without restrictions. In these recent experiences the undeniable contemporarity and newcomer friendliness of these platforms does NOT seem to translate into quality of code, quality of discussion or any kind of benefic developer agility in any way. Again, just anecdotal evidence which you may take for what it's worth, but in fact I believe that the "slow", unfamiliar, peculiar, old-school whatever-you-want-to-call-them methods used in Emacs development may in fact be "aces up our sleeve", not just a means to appease those that have been using them for a number of years.
On the flipside, though, Pit-Claudel saw the opposite in a project that he works on which switched to GitHub, but also cautioned that it is easy to give these kinds of anecdotes too much weight:
What this doesn't say is whether any "modern" workflow would have helped, or whether it was specifically Github, because of network effects (the barrier for contribution is lower if you already have an account and you are already familiar with the UI).For Monnier, the choice of tools is obvious at this point. Rather than continuing to look at other options, he would just like to get on with an evaluation of sourcehut:In fact, it doesn't even say whether it was the move itself that helped, or whether the move was an irrelevant manifestation of a more welcoming approach and a general effort to attract contributions.
Reading this discussion made me realize why I'm rooting for SourceHut: it's the only such tool I've seen whose goals align exactly with ours. Both philosophically (most other tools just happen to be Free Software and but are more philosophically aligned with Open Source) and technically (it aims for first class email support while providing as much as possible of the shiny web features of other systems).So at this stage, I personally don't see much point looking for other tools. Instead I'm just wondering how to get us to use SourceHut (i.e. how to resolve the problems that might stand in the way, such as getting an instance up and running on GNU machines, starting to use it "on the side" to see in practice what issues we'll need fixed/improved/added before we can really switch, etc...).
It is clear that any change—if one is made—will need to support the email-based workflow unchanged (or nearly so) from today's methods, but that adding other workflow styles might be a "nice to have". Stallman noted that there are both practical and moral considerations at play for keeping email as a first-class option:
You also need to have an internet connection at the moment that you try to use the web forum. Not so for sending email.[...] To make an account on a web forum, you have to use that platform in the way it is set up to require. You have to accept its terms and conditions, which may be morally unacceptable.
When you send email, you use your own choice of tools and platforms -- the same ones you used to send mail to a different forum the day before.
Network effects
Though some are enthusiastic about sourcehut getting to a point where it can satisfy both old- and new-school developers, it may still be too far afield for many of today's younger developers. The network effects of GitHub (and, to a lesser extent, GitLab) far outstrip those of sourcehut, and it may well be that users of those other forges are put off by whatever differences there are at sourcehut. As Ingebrigtsen put it:
Emacs will change to a new system when we can find a system that's good enough, and offers both an email work flow (for those that prefer that) as well as a non-email work flow (for those that prefer that).We haven't found such a system yet. sr.ht [sourcehut] is perhaps an option, but my first impression is that it's too different from GitHub/Lab, really.
In the end, it will probably come down to whether or not the Emacs developer community finds the energy to start working with sourcehut (or some alternative, though that seems far less likely at this point). There is clearly work needed even to get it to a point where the email-based workflow is fully supported (e.g. bug tracking); enough web features to bring in users of Git**b needs even more. It is not at all clear that doing that work will change the situation all that much, either; drive-by contributors, or even those who are more serious about doing Emacs development, may not be all that interested in signing up for yet-another web site and learning its interface and quirks.
Emacs is not alone in feeling that workflow modernization is needed for the future, of course. Python has largely already made the switch to GitHub, for example, and the Linux kernel is dipping its toes into that world as well. Other projects are likely struggling with it as well. To the extent that the future can be predicted with any accuracy, at this point one would have to guess that 20—or 30—years from now email-based workflows will be dead or nearly so. Navigating from now until then is going to be somewhat messy for many, generally older, projects.
Posted Sep 1, 2021 23:22 UTC (Wed)
by dvdeug (guest, #10998)
[Link] (6 responses)
Welcome to the 21st century. On one hand, Internet access is ubiquitous; if you don't have it, it's likely you should put your phone down and look at what the world looks like far from a city. I'm more likely to have power problems than Internet problems. On the other, I got a lifetime POP3/IMAP address before college; it lasted about four years. I could pay for an email address I could use offline, instead of Gmail, but that's an ongoing expense for minimal gain right now.
It's just out of touch for most of us.
Posted Sep 2, 2021 10:03 UTC (Thu)
by rsidd (subscriber, #2582)
[Link] (1 responses)
The web version doesn't seem to allow this, but if gmail was already loaded on your browser before you went offline, you can type mail, read your most recent mails, etc. But "send" works only when you are online.
You can also use any other offline mail client with gmail: read/retrieve with imap, send with smtp.
I'm not sure how a web forum is better than this when you are offline.
Posted Sep 8, 2021 15:21 UTC (Wed)
by tbelaire (subscriber, #141140)
[Link]
There is a "Offline Mode" setting which will allow you to bookmark, then use gmail offline, including sending messages (which go into an outbox until they are sent)
https://support.google.com/mail/answer/1306849?hl=en
Posted Sep 2, 2021 11:48 UTC (Thu)
by aragilar (subscriber, #122569)
[Link] (3 responses)
As an aside, one of the features that sold me on git/hg (compared with SVN) was the ability to work without an internet connection. While it would be entirely possible to use the various forges offline (e.g. github wikis are git repositories, there's some ability to respond via email), I suspect the fact that most of the data are in non-standard formats (as opposed to e.g. mbox) means that you're basically duplicating the forge's web interface/data system locally, which doesn't scale across forges.
Posted Sep 4, 2021 18:34 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (2 responses)
It does depend on where you live, but maybe surprisingly, someone (Nix?) pointed out to me that often you get BETTER internet in the sticks than in the smoke! Living in a city of 10M, my internet was pretty naff. It's improved a bit since we've gone FTTP, but the problem is too little infrastructure for too many people ...
Cheers,
Posted Sep 8, 2021 7:09 UTC (Wed)
by RobertBrockway (guest, #48927)
[Link] (1 responses)
Posted Sep 8, 2021 7:47 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
Most of our ISPs buy "last mile" off of OpenReach. If I started my own ISP, I would have to do the same.
OpenReach just don't have the capacity. If the physical infrastructure is over-subscribed, then you're stuffed. Where do you turn? It's getting better with the move from copper to fibre, but that brings other problems ...
Cheers,
Posted Sep 2, 2021 4:12 UTC (Thu)
by halla (subscriber, #14185)
[Link] (19 responses)
Posted Sep 2, 2021 10:15 UTC (Thu)
by Karellen (subscriber, #67644)
[Link] (17 responses)
Posted Sep 2, 2021 10:25 UTC (Thu)
by jafd (subscriber, #129642)
[Link] (1 responses)
Posted Sep 2, 2021 15:58 UTC (Thu)
by Karellen (subscriber, #67644)
[Link]
But GIMP and Krita don't call themselves "photoshops", and technical articles comparing the features, advantages and drawbacks of similar programs won't call them "photoshops" either. They'll call them "graphics editors" or "photo manipulation" software. Gimp and Krita might be compared to Photoshop, or referred to as Photoshop replacements, referencing Photoshop as a specific branded product, but the generic class of software won't be called that by any technical publication.
And LWN is, if nothing else, a technical publication.
And, to the best of my knowledge, "forge" is still the best generic word we have for that particular class of software. I could see "hub" as a possible replacement - although I've not personally seen that in the wild. But using a specific brand name that is still in active use (unlike your "tapes" example) as a generic technical term doesn't seem right.
So if "forge" is, as the parent commenter suggests "out of touch" or (as another commenter has put it "archaic"), I'm still not clear on what the up-to-date correct industry replacement term is.
Posted Sep 2, 2021 15:19 UTC (Thu)
by halla (subscriber, #14185)
[Link] (14 responses)
Posted Sep 2, 2021 15:31 UTC (Thu)
by jake (editor, #205)
[Link] (13 responses)
sorry you didn't like the word choice that I (and others) used, but it was meant to be inclusive, not archaic.
also, you didn't answer the question asked above:
> So, bring me up to speed, what is the New Hotness terminology that "the kids"
so, if we don't want to be hopelessly archaic, what term do you suggest?
thanks,
jake
Posted Sep 2, 2021 16:02 UTC (Thu)
by samlh (subscriber, #56788)
[Link]
Posted Sep 2, 2021 17:13 UTC (Thu)
by halla (subscriber, #14185)
[Link] (10 responses)
Posted Sep 2, 2021 20:10 UTC (Thu)
by peniblec (subscriber, #111147)
[Link] (9 responses)
To me “collaboration platform” sounds more generic and can apply to much more than tools geared specifically toward managing code. “Forge” is used in the wild; cf. FSF’s forge evaluation, sourcehut describing themselves as a “software forge”, and the software forge performance index they publish. I find the term fine. Wikipedia does trace its usage back to SourceForge (et al.), but that does not make the word invalid; that just gives it some history.
Posted Sep 5, 2021 8:33 UTC (Sun)
by samlh (subscriber, #56788)
[Link] (8 responses)
> "... the largest and most advanced development platform in the world."
> "GitLab is The DevOps platform"
https://about.gitlab.com/solutions/devops-platform/
> "... It is a full software development lifecycle & DevOps tool in a single application. "
https://bitbucket.org/product/guides/getting-started/over...
> "Bitbucket Cloud is a Git based code hosting and collaboration tool, built for teams."
> "Launchpad is a software collaboration platform that provides:..."
> "Gogs is a painless self-hosted Git service"
https://docs.pagure.org/pagure/
> "Pagure is a light-weight git-centered forge based on pygit2."
> "Gitea is a community managed lightweight code hosting solution written in Go."
> "Welcome to sourcehut, the hacker's forge! ... This suite of open source tools is the software development platform you've been waiting for."
> "Phabricator is a set of tools for developing software. It includes applications for code review, repository hosting, bug tracking, project management, and more."
My conclusion:
There is no agreement on what this sort of service should be called, and calling it a "Forge" is relatively uncommon.
I personally first saw the term "Forge" be used to describe the concept as part of this article.
Based on this, I stand by my suggestion that a descriptive phrase be used instead.
Some relatively clear phrases from the descriptions above: "code hosting and collaboration tool", "software collaboration platform"
Posted Sep 5, 2021 9:55 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (2 responses)
IME it is the standard term. Did you know the collective noun for owls is a parliament? How many other collective nouns do you know? Just because you've never met a word doesn't mean you can say it is uncommon (the collators of The Complete Oxford Dictionary ended up with egg on their faces due to this mistake!)
> I personally first saw the term "Forge" be used to describe the concept as part of this article.
You live and learn. The average person uses about 20,000 in their normal vocabulary. They also have a complete vocabulary of over 50,000. I don't know how many English words there are in common use but it's probably at least two orders of magnitude higher - don't forget one of the reasons English is so hard to learn is it has far more words than almost any other language ...
Welcome to computer jargon - "forge" is a well-understood word.
(And don't forget. That's WHY English has so many words. We repurpose words from elsewhere. Like German creates massively long complex nouns. Don't start applying German habits to English ...)
Cheers,
Posted Sep 5, 2021 12:34 UTC (Sun)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
"BH", "U-Bahn", "S-Bahn", and "Handy" are all perfectly respectable words in German, and words like "Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz" or "Donaudampfschifffahrtsgesellschaftskapitän" don't see much daily use outside of their originating contexts.
Posted Sep 6, 2021 10:03 UTC (Mon)
by bosyber (guest, #84963)
[Link]
Posted Sep 7, 2021 14:52 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (4 responses)
> I personally first saw the term "Forge" be used to describe the concept as part of this article.
Yet you knew instantly what it meant, which is what matters.
There's also a lot of history behind it, I mean it has not just been made-up. It's not an acronym. So "forge" is really a winner.
> Some relatively clear phrases from the descriptions above: "code hosting and collaboration tool", "software collaboration platform"
You can keep using something longer and we'll likely understand you too, which matters too. Then we'll see what wins; that's just how language evolves.
Posted Sep 7, 2021 18:08 UTC (Tue)
by samlh (subscriber, #56788)
[Link] (3 responses)
Please don't make assumptions.
I was able to figure it out from context because I've been around long enough to have used SourceForge (towards the tail end of it's relevence), and I was astonished that anyone would want to call themselves something reminiscent of it.
> You can keep using something longer and we'll likely understand you too, which matters too. Then we'll see what wins; that's just how language evolves.
I'm aware that is how language works. However, I wanted to make it clear that I feel it would be a shame if the language goes that direction.
After all, I'm aware that peek, peak, and pique are turning into synonyms, but that doesn't mean I'm happy about it.
Posted Sep 7, 2021 19:10 UTC (Tue)
by marcH (subscriber, #57642)
[Link]
Yeah language is all about context.
> However, I wanted to make it clear that I feel it would be a shame if the language goes that direction.
But again zero single-word alternative to suggest.
"Software Collaboration Platform" embeds all the necessary context in the name which is redundant and why people tend to prefer shorter names.
The typical (and horrible) "solution" for this neologism issue is: SCP. Glad we can easily avoid it this time.
Posted Sep 7, 2021 20:17 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
SF was at one point THE place to go to get free software. Just because SF towards the tail end (not coincidentally) became undesirable doesn't mean "forge" as a word is somewhat permanently tainted. It is a perfectly reasonable thing to do.
Posted Sep 8, 2021 0:53 UTC (Wed)
by marcH (subscriber, #57642)
[Link]
That would be indeed a weird way to think, I hope they meant something else.
Moreover SourceForge was forked into GForge, TeamForge, FusionForge and maybe other forges (and Savannah), so it has not been specific to SF for a long time.
Posted Sep 3, 2021 6:40 UTC (Fri)
by ddevault (subscriber, #99589)
[Link]
Posted Sep 3, 2021 19:28 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
There are people out of touch with the present (not Jake who wrote this excellent summary).
On the other hand, people out of touch with the past are doomed to repeat its mistakes.
Posted Sep 2, 2021 4:46 UTC (Thu)
by pabs (subscriber, #43278)
[Link] (19 responses)
Posted Sep 2, 2021 8:12 UTC (Thu)
by ibukanov (subscriber, #3942)
[Link]
And before I stopped using Emacs a typical mode to use it was accessing its instance remotely via ssh using either a terminal window or a remote desktop client.
Posted Sep 2, 2021 16:19 UTC (Thu)
by Karellen (subscriber, #67644)
[Link] (15 responses)
The way you've phrased this reminds me of Zuckerberg's famous line "Privacy is Dead. Get over it."
Even if the statement is not true, Zuckerberg stands to gain a lot of money if he can convince people that it is, so that they give him their personal details, that he can then use for his personal enrichment.
Similarly, I suspect that there are a lot of companies out there who want to lock people into subscription services who would very much like to convince people that running local software is becoming obsolete and/or not relevant. Especially in the noophilic tech industry where chasing the latest shiny is seen as so important. Getting that message out there, having people repeat it, is good for their bottom line.
As such, I am highly skeptical of such a notion.
Posted Sep 2, 2021 16:39 UTC (Thu)
by smoogen (subscriber, #97)
[Link] (4 responses)
===
"You have zero privacy anyway," Scott McNealy told a group of reporters and analysts Monday night at an event to launch his company's new Jini technology.
"Get over it."
Posted Sep 2, 2021 17:41 UTC (Thu)
by Karellen (subscriber, #67644)
[Link] (3 responses)
McNeally may have said it (or something similar) first, or at least before Zuckerberg, but Zuckerberg has definitely repeated the statement, and I think he has more to gain from repeating it and trying to convince people that it is the case: -- Privacy is (not) dead | The Stanford Daily (2014). (I am unable to find a copy of the original Techcrunch article that doesn't require me to read, understand and agree to 3,500 words of legally binding cookie/privacy terms before being able to access it, and who has time for that kind of bullshit. So my apologies for the lack of a proper source for the quote.)
Posted Sep 2, 2021 19:15 UTC (Thu)
by excors (subscriber, #95769)
[Link] (1 responses)
I think you need better evidence for that claim. As far as I can see, the 2010 TechCrunch interview where he discussed privacy is https://youtu.be/LoWKGBloMsU?t=152 and he did not say that. (He said something much less pithy about how social norms around privacy are changing and people are willingly sharing more personal information than before, and Facebook is innovating to reflect those social norms.)
Maybe the Stanford Daily writer just read the headline of https://www.nbcnews.com/id/wbna34825225 ("Privacy is dead on Facebook. Get over it.
Posted Sep 3, 2021 1:12 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Sep 3, 2021 7:21 UTC (Fri)
by anselm (subscriber, #2796)
[Link]
Privacy may be dead but apparently it hasn't fallen over yet.
Posted Sep 3, 2021 1:12 UTC (Fri)
by pabs (subscriber, #43278)
[Link] (9 responses)
Posted Sep 3, 2021 10:39 UTC (Fri)
by pizza (subscriber, #46)
[Link] (8 responses)
So why aren't we all using Windows?
>That potential tradeoff; either stick to your principles or become relevant by embracing recent trends.
Sure, they can rewrite emacs in Javascript and have it run as a web service paid for by advertising and/or loot-box micro-transactions.
Posted Sep 3, 2021 10:54 UTC (Fri)
by ilammy (subscriber, #145312)
[Link]
That’s exactly the point: majority people *are* using Windows. Of course, some people use Linux, quite a few of them, and depending on your social circle most people you know could be using Linux. But that isn’t necessarily a representative sample of the entire population.
Posted Sep 3, 2021 11:11 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (6 responses)
This is an extreme strawman. Switching to a forge based model is more closer to switching to Git which Emacs did recently. It can help with attracting more developers but it isn't fundamentally changing the nature of what the software is, for users. There is a good reason why it shows up in discussions including for the Linux kernel.
Posted Sep 3, 2021 11:46 UTC (Fri)
by pizza (subscriber, #46)
[Link] (5 responses)
The overwhelming majority of software developers use entirely vendor-supplied (proprietary, or effectively so) integrated tooling (including editors!) to their software on top of pre-existing (again, typically proprietary) platforms.
Even back in the heady days of emacs' popularity, it was not the preferred choice of a majority of its potential userbase (too big, too complicated, too slow, not installed by default, etc etc) and had a tiny developer mindshare. As the general developer population has grown exponentially, the portion that builds and maintains the underlying platforms (and the tools used to maintian it) has shrunk to relatively infinitesimal size.
And now those developers are being told that their apples would be more appealing to folks that are used to oranges if they would only turn themselves into oranges first.
Posted Sep 3, 2021 15:52 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (4 responses)
Posted Sep 3, 2021 16:30 UTC (Fri)
by pizza (subscriber, #46)
[Link] (3 responses)
Changing everything about how you develop software is the _entire point_ of moving the the forge model.
If you want folks to change, you need to convince them that the results will be better *for them* instead of just for some nebulous group of folks that isn't likely to ever materialize.
Posted Sep 3, 2021 16:41 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
This is an incorrect assumption. You stated earlier: "Sure, they can rewrite emacs in Javascript and have it run as a web service paid for by advertising and/or loot-box micro-transactions". This level of changing everything is definitely not required. It is also possible for forges to be optional and not exclusive. This article itself covers Sourcehut and there are others like Pagure etc. Even if you limit yourself to GitHub, https://lwn.net/Articles/860607/ covers the usage of bots for example to bridge email based development to forges. It doesn't have to be all or nothing at all.
>If you want folks to change, you need to convince them that the results will be better *for them* instead of just for some nebulous group of folks that isn't likely to ever materialize.
I don't care if they change or not as long as we stick to a correct understanding of what the options are
Posted Sep 3, 2021 18:09 UTC (Fri)
by pizza (subscriber, #46)
[Link] (1 responses)
Sure, just like it's possible to get MS Outlook to sanely handle inline email replies.
(Remember, we're talking about _popularity_ as being the prime metric for measuring worthiness!)
> This article itself covers Sourcehut and there are others like Pagure etc.
Sourcehut (with less than 25K registered users) really shouldn't be lumped in with anything else, as it's very unlike all other forges in ways that _reduce_ its general appeal to non believers. I mean, who uses email any more? There isn't even a phone app or VSCode integration plugin!
(Just to be clear, I am quite impressed with Sourcehut's approach to things, and I will probably set up a private instance for my own use)
Posted Sep 3, 2021 18:44 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link]
Ok, so now you are conceding albeit grudgingly that is possible for forges to be optional and it doesn't have to be all or nothing. That's a start and you can move on to look at the actual spectrum of options and what is possible and how even traditional forges are used very differently among different projects.
> (Remember, we're talking about _popularity_ as being the prime metric for measuring worthiness!)
That's yet another strawman. I am certainly not using that as a metric and I doubt that anyone really is. Forges are popular but popularity itself isn't the prime metric. The benefits they may bring to a project are. My position can be more accurately summarized as: Multiple options are available today for forges and they are worthy of consideration for free software projects which have a more email based workflow to evaluate whether it fits into their needs because it may help them do some things in a better way.
> Sourcehut (with less than 25K registered users) really shouldn't be lumped in with anything else
This kind of special pleading doesn't negate the fact that it falls under the definition of a forge fundamentally although I agree it has some unique features. Pagure - covered at https://lwn.net/Articles/687821/ has some other interesting features as well. If you are evaluating forges, you can't stop at GitHub.
Posted Sep 2, 2021 18:44 UTC (Thu)
by jwarnica (subscriber, #27492)
[Link] (1 responses)
My observation from the last round was that the dozen or so people who understood the magic and had a chance of unmagicing it had little interest in doing so, apparently fully expecting to have to dust off their vt320s tomorrow. Or at least, retire..
Posted Sep 4, 2021 18:56 UTC (Sat)
by eliz (guest, #94829)
[Link]
I don't know what you are describing here, but it isn't Emacs.
Posted Sep 2, 2021 7:07 UTC (Thu)
by ddevault (subscriber, #99589)
[Link] (2 responses)
Posted Sep 2, 2021 9:22 UTC (Thu)
by tlamp (subscriber, #108540)
[Link] (1 responses)
1. any plans to support the "fork + push a few commits + press button to open a pull-request on the original repo" work flow the Git**b support? The clone part is already supported, but there's no concept of pull-requests FWICT, or did I just miss that?
2. Why are the links to switch between git/todo/... tools of a repo only shown if logged in? Would be less confusing if they would be always present. I mean, if I navigate manually to those I can still view them, so it's not like they'd be restricted to logged-in users.
3. Is there any migration guide, be it from Git**b instances or from more, well, traditional setups with a mailman list for development, a private git-daemon with a public read-only mirror + webgit and a BTS like Bugzilla? As ideally one would be able to merge all those old historic info into SourceHut, or at least my $dayjob would have that as hard requirement. Is it 'script that stuff your self', which can be fine, or is there a more integrated way (planned) for doing that?
Posted Sep 2, 2021 9:27 UTC (Thu)
by ddevault (subscriber, #99589)
[Link]
More or less, yes, though it will be facilitated by email. You can see a video of the process here:
https://spacepub.space/videos/watch/ad258d23-0ac6-488c-83...
The goal is to ultimately develop these web tools to make Git**b users feel comfortable with the email workflow from the web.
> 2. Why are the links to switch between git/todo/... tools of a repo only shown if logged in? Would be less confusing if they would be always present. I mean, if I navigate manually to those I can still view them, so it's not like they'd be restricted to logged-in users.
These are not links between different resources between a project, but between the top-level pages for each service. They are hidden because that's not usually what someone wants when they just show up on a random page. There are plans prioritized for the beta to make it easier to move around a project's various repos, bug trackers, mailing lists, etc. It's a known defect.
> 3. Is there any migration guide, be it from Git**b instances or from more, well, traditional setups with a mailman list for development, a private git-daemon with a public read-only mirror + webgit and a BTS like Bugzilla? As ideally one would be able to merge all those old historic info into SourceHut, or at least my $dayjob would have that as hard requirement. Is it 'script that stuff your self', which can be fine, or is there a more integrated way (planned) for doing that?
I don't think there's a particularly good guide for this per-se, as each of these situations is generally built ad-hoc out of a variety of tools/a unique subset of available tools, for which there is no universal hammer to provide a migration path. There is the ability to import mailing list archives from an mbox, however, which provides an easy upgrade path for Mailman users, but there is no such offering for Bugzilla => todo.sr.ht (yet - there are some API affordances made which should make new import scripts easier to write, project admins can forge dates and authorship and such via the API).
Posted Sep 2, 2021 7:28 UTC (Thu)
by beshr (guest, #133204)
[Link] (31 responses)
Git has a pretty good tutorial on how to contribute via mailing lists (docs/MyFirstContribution). If you'd like to find out if it's really that daunting of a task, try to find some typo in the documentation and submit a patch.
Posted Sep 2, 2021 11:31 UTC (Thu)
by khim (subscriber, #9252)
[Link] (28 responses)
Struggled a lot, actually. It's really hard for the beginner to grok GitHub. But they are doing it with the knowledge that they have hundreds (or thousands) projects hosted there and if they learn to use it they can ask about or contribute to all of them easily. If they would learn how to contribute to the Emacs… they would be able to contribute to Emacs. Not even other GNU projects use the same tools (some of them use similar ones, but they all are subtly different).
IOW: GitHub attracts people precisely and exactly for the very same reason Emacs developers don't like to use it — dependence on some central place which enforces uniformity. Compared to what? Compared to GitHub based project? Difficult. You need to learn a lot of lore which would only be applicable to that particular project. That's not something casual contributors can be bothered to learn. And while stance “we don't need these two-line patches, we need commitment” may sound reasonable in reality it doesn't work like that. Most developers start out as casual contributors, if you send them away then where would people with commitment come from?
Posted Sep 2, 2021 11:56 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
With the requirement to do paperwork first to assign copyright, they aren't really likely getting two line patches anyway. Commitment becomes an upfront requirement, not merely because of infrastructure.
Posted Sep 2, 2021 12:19 UTC (Thu)
by khim (subscriber, #9252)
[Link]
I have committed two-line patches in various GNU projects without any copyright assignments (not in Emacs, though). You only need assignment when you contribution is large enough to be copyrightable in the first place. Yes, actual patches were submitted by others and included tests, entries in ChangeLogs and so on… I, basically, only reported the problem and possible fix… precisely and exactly what you may expect from someone without commitment… Wrangling with bugzilla/mailing lists/etc was MUCH bigger hassle than spotting and fixing the actual problem.
Posted Sep 2, 2021 13:30 UTC (Thu)
by beshr (guest, #133204)
[Link] (25 responses)
That's not exactly true. Contributing via patches to mailing-lists, writing the cover-letter, setting up cli email sending or via emacs, will help to contribute to any other project that uses the same method. The knowledge gained is not specific to emacs dev, like contributing to Git for example. The specifics of each group's requirement might be different tho. There's value in variety.
> Compared to what? Compared to GitHub based project? Difficult.
I sort of disagree, sure if you're fixing a typo and you don't have any setup for mailing-list contribution, maybe that'd be true (not that that's not a valuable contrib). What I actually meant was in the rest of my original comment. I meant compared to learning how to get comfortable with Git, bash, navigating their way around gdb, etc... My point is that they're all difficult to the uninitiated, and altho may seem like skills don't transfer, in reality they do. The more you learn about similar things the easier it gets to learn about other similar things.
Posted Sep 2, 2021 14:04 UTC (Thu)
by khim (subscriber, #9252)
[Link] (5 responses)
True, but for the most contributors out there all these tools required to even start are significantly more complicated when mailing lists are involved. To report an issue in GitHub you don't need to know how to use git, you don't need to know how to generate patches, you don't need to even find out where to even send these patches! Imagine that I'm novice and want to just create an issue for, IDK, rust compiler (just since we talked so much about it recently). What should I do? Well… type “rust sources” in browser, look on the first link, navigate sources, click on the line which you find questionable, pick “reference in a new issue”, write something. Try to do the same with Emacs and see how many click would you need to achieve the same result. Not for the first-time contributor. For them every additional mouse click counts. I have tried to do the same exercise with Emacs. Not only I have to pick 3rd result in Google and few other non-trivial choices. But even when I arrive at the point where I can actually see the source… I'm stuck. I have no idea what to do… I can click as much as I want — noone would ask me to create an account, noone would offer me to create an issue. Dead end. What does that mean, ultimately? That means that if someone who is not yet a software developer would try to contribute into any project it would be GitHub or GitLab or something like that. They would initially fail to contribute to any project on any platform, of course. But the first success would be, undoubtedly there, where you don't need to learn anything and where the only skill required is to write some code and to know how to use mouse. They would engage in working with developers before they would learn how to use Git or Mail or any other “complicated” tool. And by the time they would be savvy enough to even contemplate to contribute to Emacs GitHub would be something they know and love and all these mailing lists would be a scary mystery.
Posted Sep 3, 2021 12:05 UTC (Fri)
by jkingweb (subscriber, #113039)
[Link] (4 responses)
This seems to be a bizarre way to go about reporting a bug. If I wanted to report a bug in Emacs I'd type "report a bug in emacs" into my search engine, and lo, detailed instructions are the first result.
Posted Sep 3, 2021 12:24 UTC (Fri)
by khim (subscriber, #9252)
[Link] (3 responses)
“Detailed instructions”? Like that one? Not “click here, type text there” actionable form? You have lost that [potential future] contributor then and there. I beg you. Visit any local college. Computer Science department. Talk to first-year students there. Try to ask how many of them would use e-mail for anything — and note what said “anything” is. You may be surprised. For the new generation e-mail is not something they use to communicate with “normal” humans. They receive confirmations from the web sites there and, sometimes, send official letters (which, for obvious reasons, teaches them not to do that often because consequences can be dire). You may lament it as much as you want but that's just the fact of life: for the “new generation” e-mail is not a tool which they use to communicate with humans. All these “pages with detailed instructions” which I can find ignore that completely. Again: I'm not saying it's wrong. If Emacs developers want to use that barrier to keep “uninitiated” away, then it may even be Ok. But then, why complain that there are not enough developers? You, themselves, made it impossible for them to find and join the emacs team (or, for that matter, start using Emacs at all). Note that “vim bug report” sends you not to the page with “detailed instructions” but to this page — with list of known issues (seachable) and helpful green “new issue” button.
Posted Sep 3, 2021 13:15 UTC (Fri)
by jkingweb (subscriber, #113039)
[Link] (2 responses)
I'm not saying the Emacs way is easy. I did only a cursory reading of the instructions I found <https://www.gnu.org/software/emacs/manual/html_node/efaq/...> and, finding that it involved using Emacs, concluded it would probably make sense to an Emacs user (which I am not).
My point is that if I'm a first-time contributor, looking for the line of source on the Web (if you're a programmer, you probably have the source locally; if not a programmer, you're not going to go looking through the source) is not the way I'd go about trying to report a bug, and I'd hazard few people would do it that way.
You were judging Emacs' process based on the back roads rather than the main thoroughfare, and that's a terrible way to make an argument.
Posted Sep 3, 2021 13:49 UTC (Fri)
by khim (subscriber, #9252)
[Link] (1 responses)
So… you have found the page and haven't actually bothered to actually read it? Let me do that for you: These instructions made perfect sense quarter-century ago. When most Unix systems had working e-mail setup and Windows was in it's infancy. Today most novice developers use Windows (even if they are WSL users) and even rare ones who actually use Linux mostly don't have functioning mail setup on their workstations thus there would most definitely no “reliable return address”, and, most likely, bug-report sent with the use of that instruction would be delivered straight to /dev/null. To realize how outdates and pointless these instructions are I want to point out that even LWN (and it's very old-fashioned web-site by today's standards) doesn't have any idea what to do with news: URL. Again. Please try to talk to first year students some time. This is exactly how they would try to do that. For them browser (and also mobile phone apps) is how they communicate. If they are emacs users then probably mobile phone apps are not that important, but e-mail is not something they use often and even if they use it they don have functioning MTA on their system, they use browser to receive and send emails. Yes, I may not be 100% correct in trying to imagine how they would try to reach emacs developers, but it's just the fact that all venues which are on official sites wouldn't make any sense for them. They include use of certain tools which they have no idea about. Worse: many of them assume certain things about local machine setup which are not true in today's world and weren't true for many years. Heck, I'm not first-year student and I don't have my system setup in way which would allow me to use an official way of reporting bugs! I could probably tune it but why bother? I was just trying to imitate what my 20-25 year friends did when they tried to report bugs in some software (not emacs, obviously, none of them use emacs and most of them even have any idea it exists). You have page which even worse. If that is “the main thoroughfare” then it's no wonder that emacs doesn't get many contributors.
Posted Sep 3, 2021 16:33 UTC (Fri)
by rgmoore (✭ supporter ✭, #75)
[Link]
I think a key thing that's going on here gets back to the idea that emacs is almost its own operating system. It has a mail client built in, and the hardcore developers use it as their way of accessing email. They naturally assume that anyone who cares enough about emacs to want to contribute to it will do likewise. It's a wrong assumption, but one can understand how they would make it. After all, every emacs developer they know works that way. They're so far outside the mainstream, they have no idea what the mainstream even looks like, and they are uninterested in finding out.
Posted Sep 2, 2021 17:11 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link] (18 responses)
Knowing how to drive a stick-shift car means you can drive any stick, not just the one your fuddy-duddy uncle happens to own. I'm sure you can find lots of other fuddy-duddy uncles who drive sticks, and borrow their cars, too!
(This is the American perspective, where to a first approximation, everyone drives an automatic, and many people have never driven a stick. In Europe, for reasons which are unclear to me, everyone drives a stick.)
Seriously: I know this probably does help people contribute to e.g. Linux and a couple of other projects. But ultimately, the developer gets to decide what is and is not worth their time. Increasingly, they are deciding that email is not worth their time. You can meet them where they are, or you can lose out on their potential contributions. In a voluntary project where nobody gets paid, that's the hard and harsh reality of the situation. Arguing about *why* developers don't want to use email is a completely non-sequitur, because the reasons don't actually matter. The question, instead, is which of those two choices the project is going to make: Meet developers where they are, or don't.
Posted Sep 2, 2021 17:27 UTC (Thu)
by khim (subscriber, #9252)
[Link] (2 responses)
That's actually very simple: in US you need to drive to be able to work and live independently. And when you have no choice then picking the easiest route is “obvious”. In Europe there are no need drive at all. You do that because you want to, not because you have to. It's cheaper to live without a car. And then it becomes a stance: yes, I can and want to own a car, see? Of course the ability to own and drive more complicated car with a stick sends even stronger message thus this is what you end up doing. I guess use of e-mail to drive development of Emacs sends similar message: we have no need or want to deal with these these pesky users of IDEs and browsers, only “real”, “hardcode” developers. And absolutely no compromises! Who may want to have an ersatz-emacs in VSCode or Eclipse? These are not pure enough! If that is what Emacs developers want to achieve then using e-mail driven development maybe be a good choice, actually.
Posted Sep 3, 2021 13:37 UTC (Fri)
by Sesse (subscriber, #53779)
[Link]
(I don't have one, and not even a driver's license, but I live in a city, and I occasionally miss having one.)
Posted Sep 3, 2021 17:20 UTC (Fri)
by JanC_ (guest, #34940)
[Link]
Larger/luxury cars always were much more commonly sold with an automatic, and of course hybrid & electrical cars (usually?) have them too…
Posted Sep 2, 2021 19:12 UTC (Thu)
by beshr (guest, #133204)
[Link] (1 responses)
That's not exactly the argument. My understanding is is that this is usually proposed as a change to "help attract others" by other members who may or may not be current contributors, so the proposition is not directly coming from people who: check out the source code, look at something they'd like to fix or change, think about contributing it back, and then get hit with the mailing-list while, but is actually from people who are thinking growth (which is not necessarily bad or wrong).
> Increasingly, they are deciding that email is not worth their time.
There's not much decision going on without trying. I'm not saying that everyone needs to be forced to do mailing-list contribution for a month or that choosing not to go that route is wrong. If some project decides to switch to Github to get more of that crowd then good for them, but compelling all projects to be uniform (in the name of the newcomers) is the thing that I'm against.
Posted Sep 2, 2021 22:15 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link]
* Whether those concerns are real or imagined, in the specific case of Emacs.
For example, I very much doubt they are going to move to GitHub given the FSF's stance towards its use of Javascript etc., and that probably does cost them a significant amount of developer visibility. But GitHub goes against their core philosophical values too strongly, so this reduced visibility is outweighed. Personally, I happen to disagree with both their philosophy and the relative importance they place on it, but it's their project and their values, not mine. What's important is that they make an informed decision based on the available evidence, rather than some ill-conceived notion that everyone "has to" use GitHub.
Posted Sep 2, 2021 20:10 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (9 responses)
Less so nowadays, but sticks are noticeably more efficient (greater mpg), and fuel is a *LOT* more expensive.
Cheers,
Posted Sep 2, 2021 22:30 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (4 responses)
In recent years, in the real world, automatics are more fuel efficient than the average people driving a stick (which itself is a tiny percentage in the US). If you do a comparison with hybrids, there is no competition at all. Fuel emission standards in US are why there is very little manuals even being sold in US and the market is increasingly gearing towards hybrids.
Posted Sep 3, 2021 7:13 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (3 responses)
Yes, I think the fuel efficiency argument is no longer true. However, it's a manual transmission is a lot simpler and cheaper to fix than an automatic transmission (where if something goes wrong, you pretty much just replace the whole thing.
I drive a stick and I'll be sad if/when stickshifts become unavailable here in Canada. Coincidentally, I also use emacs. And I'm in my 50s. I wonder if those things are correlated?
Posted Sep 3, 2021 9:18 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (2 responses)
Here in Germany, most people learn to drive stick in driving school – in fact it used to be the case that if you passed your driving test on an automatic, your license would be restricted so you could only ever drive automatics, which given that they're fairly rare hereabouts would be quite inconvenient.
Automatics, apart from being more expensive and less fuel-efficient, used to be seen mostly as cars for the elderly and/or medically impaired, but especially with electric cars and driver's assistance systems tied to automatics being on the rise, attitudes are changing. The law was recently changed to make it easier for holders of automatic-only licenses to transition to stick shift after all; presumably this is in preparation of a time when most cars will not have a manual transmission, driver's ed will take place mostly on such cars, and stick shift will become more of a curiosity for people with specialised or vintage vehicles.
Posted Sep 3, 2021 10:17 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
That's European regs. Class B is stick shift, or there's Class B (auto) for automatics only. Which one you get depends on what sort of vehicle you take your test in - upgrading is a simple matter of retaking your test in a stick. That said, retaking your test is probably "fun" for an experienced driver because of all the bad habits you'vve picked up ... :-)
Cheers,
Posted Sep 4, 2021 19:10 UTC (Sat)
by anselm (subscriber, #2796)
[Link]
As a matter of fact, here in Germany the law was recently changed to say that if you take your driving test on an automatic, you don't have to take another driving test (with an official examiner in the rear seat) in order to be allowed to drive stick. To get your license amended, all you need to do now is present a certificate from a driving school saying that you took a certain number of lessons in driving stick and managed it to the driving teacher's satisfaction.
Posted Sep 3, 2021 9:36 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (3 responses)
Not true of the last ten years or so - automatics are more fuel efficient nowadays. Two reasons:
Of course, electric cars resolve this by getting high fuel economy with a fixed gear train instead of using a gearbox - but that's a whole different story.
Posted Sep 3, 2021 17:28 UTC (Fri)
by JanC_ (guest, #34940)
[Link] (2 responses)
Posted Sep 3, 2021 22:48 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Sep 7, 2021 1:09 UTC (Tue)
by JanC_ (guest, #34940)
[Link]
I suppose something similar could also be useful for e.g. electric trucks.
Hybrids are more likely to use something like a CVT, from what I understand.
Posted Sep 3, 2021 2:23 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Nice naiveté! First, there are old cars without synchromeshes where you need to over-rev engine before switching the gears. Second, there are cars with nonstandard switching scheme.
Posted Sep 3, 2021 10:26 UTC (Fri)
by amacater (subscriber, #790)
[Link]
Posted Sep 3, 2021 16:35 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
Gas is several times more expensive in many European countries (taxes) and old, non-computerized automatic gearboxes are very inefficient. I think they are also more expensive to manufacture and maintain than a manual.
I'm sure there are cultural aspects too. After driving sticks for many years it was very hard for me to get used to the sluggish response of "slushboxes": when the car _slows down_ first when you press hard on the gas because it downshifts first. In general it really feels like losing control - because it is.
I don't think slushboxes will ever sell much in Europe but newer, computer-control "automated manuals" are gaining ground.
(totally off-topic sorry)
Posted Sep 2, 2021 22:03 UTC (Thu)
by rodgerd (guest, #58896)
[Link] (1 responses)
No-one is asking you to. But don't whine about it when no-one shows up to work on your project.
Posted Sep 2, 2021 22:58 UTC (Thu)
by pizza (subscriber, #46)
[Link]
What makes you think I expect anyone to "show up to work on my project" ?
Similarly, why should I care what other folks choose to spend their time on?
This isn't a zero-sum popularity contest; it's about software that has never held anything other than niche appeal, even during its supposed heydey.
Posted Sep 2, 2021 9:08 UTC (Thu)
by anton (subscriber, #25547)
[Link] (7 responses)
It seems to me that if you change to follow the latest trend, that trend has a good chance to turn out to be a fad. You will then have to follow the next trend, imposing repeated strain on your main developers. Admittedly, there are changes that stick for a longer period (RCS->CVS, CVS->git), but it tends to be hard to predict whether some tool will be stable or will soon be superseeded by the next great thing, or become unattractive for some other reason (e.g., being bought by a big corporation with a dubious reputation).
Posted Sep 2, 2021 9:57 UTC (Thu)
by mfuzzey (subscriber, #57966)
[Link] (2 responses)
Of course git changes the paradigm and offers a huge advantage over svn but I donr't think that means people in the early 2000s should have stuck to cvs just because something better could possibly come along later. If you wait long enough something better will always come along, the question is how much better is the new tool than the current tool and how much disruption will changing cause.
As to VHDL/Verilog that seems to be a geographical thing Verilog may dominate in the US but not in Europe. This is probably because Europe was later to the party so adopted the newer language whereas the US had already heavilly invested in Verilog and VHDL wasn't enough of an improvement to justify switching for many US companies.
Posted Sep 2, 2021 10:28 UTC (Thu)
by geert (subscriber, #98403)
[Link]
Posted Sep 2, 2021 11:20 UTC (Thu)
by anton (subscriber, #25547)
[Link]
Concerning Verilog/VHDL, my understanding (based on the possibly biased HOPL-IV presentation on Verilog) is that at one point (maybe around 2000) VHDL was so fashionable that the Verilog people were believing themselves that they were on a sinking ship. However, Verilog was designed to be efficiently simulated, and VHDL was designed for other goals, and for large projects simulation speed is king, so VHDL could not win in large projects, and so failed to conquer the world, and eventually could not maintain the cachet of being the inevitable future.
Posted Sep 3, 2021 2:31 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Sep 3, 2021 6:38 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link]
Posted Sep 3, 2021 13:53 UTC (Fri)
by anton (subscriber, #25547)
[Link]
Sourceforge has been around since 1999, but at some point (probably when github ate its lunch) it turned ugly.
If some other forge becomes more popular than github, how will github react? I expect that they will become much more focussed on monetizing their existing user base, in whatever ways they can get away with. And many users won't be pleased.
Posted Sep 3, 2021 17:19 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
Sourceforge is dead but forges are absolutely everywhere. Sourceforge is to forges what BitKeeper is to source control: the revolutionary pioneer that showed the way.
The keyword that everyone seems to miss is INTEGRATION = having a single database where everything is automatically connected to everything else: bugs, patches, commits, comments and of course the ability to make a typo-fix and many other things with just a few keyboard shortcuts.
Integration, not "web-based". Integration as in "do anything in fewer actions". Like getting notified only by some specific code reviews/discussions. Another comment mentioned the ability to open VS Code from github with a single keystroke.
There are of course some other very valid concerns with forges: software freedom, backward compatibility with the email interface and all the home-grown automation developed on top of it, having some deliberate hurdles to push back noisy noobs,... but it's amazing to see how strong emotions and attachment to email can get the better of otherwise very smart people and get them to write ignorant comments like "There is no way to objectively determine which development style is easier". Of course integration makes things faster and easier, that's the entire purpose of it. Otherwise why would people use INTEGRATED Development Environments like... Emacs!! The irony.
Another very ironic thing is the existence of multiple Emacs packages to interact with forges without a web browser. Hard-code Emacs developers probably don't even know these packages exist because "software freedom", "copyright assignment", and last but not least "employer disclaimer" = the biggest hurdle for drive-by contributions IMHO.
Posted Sep 2, 2021 12:58 UTC (Thu)
by daenzer (subscriber, #7050)
[Link] (2 responses)
Posted Sep 2, 2021 13:14 UTC (Thu)
by ddevault (subscriber, #99589)
[Link]
Posted Sep 4, 2021 20:44 UTC (Sat)
by abartlet (subscriber, #3928)
[Link]
We already had pre-commit CI, a system we called autobuild, however if a dud patch was posted, the price paid for a CI failure was paid by the reviewer/commiter (particularly if the patch was not by a Samba Team Member.
We first encouraged pushing to a Shared development repository hooked up to enough runners to do a full Samba test, and then natrually folks started proposing merge requests. Pretty soon this became the standard workflow (even as the official Samba git repo remained elsewhere.
So, oddly, Samba doesn't actually merge any Samba merge requests, but applies them to a developer local machine and pushes them into the old process, but new developers don't see this, they just see a mostly new process that makes sense to them.
The big saving is that a developer, new or otherwise, who submits a not-yet-passing patch is given feedback by the computer, and not by a now-grumpy maintainer who spent time reviewing and pushing a patch that doesn't have a hope of passing CI.
I gave a Samba XP Talk on the transition.
Posted Sep 2, 2021 15:09 UTC (Thu)
by smoogen (subscriber, #97)
[Link] (11 responses)
Moving workflows, arguing about email versus web, etc ends up as window dressing versus dealing with the harder problem of 'Why LISP in 2021?' and then 'This is how you do more stuff than that hello world tutorial you found on WebArchive from 1993'
Important Notes:
Posted Sep 2, 2021 17:25 UTC (Thu)
by karim (subscriber, #114)
[Link] (6 responses)
The fact of the matter is that emacs will likely continue existing as-is (with its present dev model) until a sufficiently good replacement is found. Personally, I've been shopping around. I haven't found something just yet. Eventually, however, something with a more modern dev model, look and feel, and extensions language that can functionally replace emacs will come along. In the mean time, I'll continue using emacs. But I can't say I care what its developers do at this point, so long as I can continue having the feature set I currently have.
Posted Sep 2, 2021 17:47 UTC (Thu)
by smoogen (subscriber, #97)
[Link] (5 responses)
Posted Sep 2, 2021 17:52 UTC (Thu)
by karim (subscriber, #114)
[Link]
Posted Sep 3, 2021 6:49 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (3 responses)
Posted Sep 3, 2021 12:58 UTC (Fri)
by smoogen (subscriber, #97)
[Link] (2 responses)
Posted Sep 3, 2021 13:36 UTC (Fri)
by pizza (subscriber, #46)
[Link] (1 responses)
Because by any objective standard, VSCode is really good! It provides a very nice comprehensive, integrated, highly-customizable environment for what a substantial (possibly even a majority) of software developers these days are working on.
VSCode is the all-dancing everything that emacs was once derided for, with the significant advantage that it is implemented in a language that has a substantial developer mindshare (javascript) vs something that was a niche even in its heydey (ie lisp).
But making something so well integrated and polished takes a _lot_ of work. It's probably fair to say that between Google (ie the Chrome/Electron underpinnings) and Microsoft, more money has been invested into VS Code in the past 6 months than emacs has seen in four decades. Heck, the office supply budget for the VS Code team is probably larger than the FSF's annual spend.
Posted Sep 3, 2021 14:41 UTC (Fri)
by zdzichu (subscriber, #17118)
[Link]
Posted Sep 4, 2021 0:28 UTC (Sat)
by dvdeug (guest, #10998)
[Link] (3 responses)
I am far, far more scared of the Emacs API than the language. No matter what the language, there's still going to be window-pane-half-shadedp stuff that takes 1 or 3 as the first argument (2 was used on Motif for VAX, and 4 on an uncompleted port to Windows 3.1), and if you pass the left window pane handle to the third argument, there will be hell to pay, but it will be far away from this function. Knowledge is not transferable in or or out; this isn't built like any program besides Emacs, not a standard GTK program or KDE or Java/Swing or JavasScript browser program. I don't know anything about Emacs internals; this is just my fears.
Maybe I'm wrong--I think I do like programming languages more than most programmers--but Emacs Lisp shouldn't be scary to anyone who can hack on Emacs, and I don't think it is; it's just Emacs itself is large, ancient, and comes with a reputation.
Posted Sep 4, 2021 16:57 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
What I found the most painful was the debugger. I forgot which one(s) I tried but they were horrible. I hope it's not a inherent problem with the language? Any recommendation?
Debuggers are absolutely, totally essential for "drive-by" contributions because they save you from reading a gazillions of lines of code irrelevant to your particular issue. I'm surprised they're mentioned so rarely in discussions like these.
Even with a good debugger I would still not submit patches because employer waiver paperwork etc. but at least I can produce suggestions as close to a patch as possible.
The lack of integration / a "forge" definitely plays a role because of the additional time it takes but if something really really annoys me then I make the effort and send email; I contribute much less but not zero.
Posted Sep 5, 2021 15:26 UTC (Sun)
by smoogen (subscriber, #97)
[Link] (1 responses)
The language is a problem in that the API you are worried about is very tied into the way that Emacs LISP differs from Common LISP. One of the ways that breaks a lot of new programmers is that they go find out about LISP, read Common Lisp, try to get their LISP working with Emacs and run into exactly the perils you are talking about. Unless you really know Emacs LISP, you don't know why they do X or Y or Z.. and a bit of vice versa.. unless you know why the API does X, Y, or Z you can't really understand Emacs LISP.
The issue is that if I were a new programmer and I was told that I could code a mountain of javascript which I can find lots of tutorials, modern howtos, etc for VScode, or a small amount of Emacs LISP to do the same thing.. I would probably start on Emacs LISP and then find out that the mountain I needed to climb was not the amount of code needed to do something, but the twists in my brain which I only needed for this one tool. Then I look around and see everyone else is using VScode and just use that.
I want to say I am not saying that Emacs shouldn't move to some sort of open git repository. Just don't measure the success or failure of it by the number of new people coming into it after a year. Moving to 'git***' isn't going to fix the fundamental issues which make the emacs programmer community small.
Posted Sep 5, 2021 18:40 UTC (Sun)
by jem (subscriber, #24231)
[Link]
That's hogwash. New Emacs Lisp programmers can't just try their Common Lisp code on Emacs without first learning the Emacs API. Programming Emacs is all about interacting with Emacs functionality, either with the built-in API or interfacing with other Emacs Lisp packages. This requires learning about Emacs's buffers, windows, text search and manipulation, and the functions available for performing these tasks. Emacs can not be used as a drop-in replacement for any other Lisp system because the environment is so different. There is no point in using Emacs as a replacement for a general purpose Lisp programming environment. The difficulties posed by learning the differences between the core language features of Emacs Lisp and Common Lisp are minuscule in comparison.
Posted Sep 2, 2021 15:19 UTC (Thu)
by pj (subscriber, #4506)
[Link] (2 responses)
I wish one of the open source forges (gitlab, sourcehut, whatever) would figure out a way to handle distributed servers. Then we could have self-hosting *and* network effects. The commercial efforts of course have every reason *not* to add this capability. OTOH, if it was up to the commercial sector, we'd still be using perforce.
Posted Sep 3, 2021 6:29 UTC (Fri)
by flussence (guest, #85566)
[Link]
Posted Sep 4, 2021 15:04 UTC (Sat)
by Conan_Kudo (subscriber, #103240)
[Link]
Pagure is capable of this. Out of the box, it supports pull requests from arbitrary Git servers (it calls them "remote pull requests"). Issues and pull request metadata are all stored as git repos using JSON files as data, making it easy and portable to other Pagure instances and easy to convert for any other system. Additionally, there's a ForgeFed plugin that enables truly distributed/federated project hosting through the ForgeFed protocol across any Git forge that supports the protocol. Pagure is available in most Linux major Linux distributions, too: Fedora, openSUSE, Debian, Ubuntu, and (of course) it's in the AUR.
Posted Sep 2, 2021 18:14 UTC (Thu)
by iabervon (subscriber, #722)
[Link] (1 responses)
Posted Sep 3, 2021 19:38 UTC (Fri)
by IanKelling (subscriber, #89418)
[Link]
Posted Sep 6, 2021 10:16 UTC (Mon)
by taladar (subscriber, #68407)
[Link] (18 responses)
There might also be some issues related to the use of different mail clients. If you already have a local MTA with sendmail configured the email based workflow might seem much more viable than it is for the majority of users.
Posted Sep 6, 2021 20:15 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (3 responses)
Does that even work in 2021? I thought these days, you have to have DKIM and SPF and all the other silly things set up, or else everyone just quietly blackholes your emails. Good luck doing that on a "normal" workstation...
Posted Sep 6, 2021 21:27 UTC (Mon)
by rodgerd (guest, #58896)
[Link] (1 responses)
It's still only a policy change from gmail away from not working any more, and it's a huge hassle that I wouldn't expect most people to bother with.
Posted Sep 7, 2021 14:28 UTC (Tue)
by marcH (subscriber, #57642)
[Link]
I'm pretty sure these hoops are what kept spam at a manageable level and email barely usable. I'm also pretty sure all the standards for these hoops have been kept open and free by the "mail monopolies". Compare that to the Instant messaging solutions everyone uses today. And to spam on phone lines.
Like many other Internet protocols, The SpaM Transfer Protocol was incredibly naive wrt. security. I'm sure it worked very well in the original la-la land where it was created.
BTW https://arstechnica.com/gadgets/2021/08/a-decade-and-a-ha...
Posted Sep 20, 2021 19:07 UTC (Mon)
by flussence (guest, #85566)
[Link]
Posted Sep 6, 2021 21:30 UTC (Mon)
by rodgerd (guest, #58896)
[Link] (13 responses)
This really gets to the crux of the problem: there are a number of people in the GNU emacs community who seem very unhappy that everyone isn't using and contributing to their editor. They *claim* to want to understand why that is. And then when people try to tell them, it becomes clear that they aren't actually interested in changing anything, or responding with anything other, bluntly, than scorn and contempt for people who want to use anything developed in computing since - well, I was going to say "in the last forty years", but given that ideas like GUI-first computing environments have been around since Englebart, it's more like the last 50.
Posted Sep 6, 2021 22:05 UTC (Mon)
by pizza (subscriber, #46)
[Link] (12 responses)
If you were berated and attacked for years (and years) for being out of touch dinosaurs for not embracing [fad of the year] you'd express a fair amount of contempt too. It's no coincidence that those supposed dinosaurs are still responsible for maintaining most of the low-level infrastructure that all of these new fads are built on.
In every skilled field it is there is a concept of mastering of the tools of the trade.
You wouldn't tell a chef that their nicely-equipped commercial kitchen is a just a pile of completely unnecessary out-of-touch-with-modern-times wankery because you can do everything you need with a microwave oven.
Suffice it to say I don't place much stock in folks pissing all over email because they can't be bothered to learn to be effective with it.
Posted Sep 7, 2021 14:42 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (11 responses)
Totally understand. Except this time, email is really dead. No crying wolf this time, sorry about that.
This time, integrating code reviews, CI and everything else in the same place is really not the "fad of the year", it's the present and it has been for years (and years).
> You wouldn't tell a chef that their nicely-equipped commercial kitchen is a just a pile of completely unnecessary out-of-touch-with-modern-times wankery because you can do everything you need with a microwave oven.
Not sure whom exactly you're referring to but there are many open source projects and "chefs" using a forge too. Even (parts of) Debian are using gitlab and I believe Debian is pretty serious with software freedom.
Posted Sep 7, 2021 16:20 UTC (Tue)
by pizza (subscriber, #46)
[Link] (10 responses)
Except _every_ _single_ _service_ implementing all of that stuff (and everything else) is still backstopped by email, because email remains the communication channel that can be assumed to be available.
Granted, increasingly those services just send an email that just says little more than "something happened" and "log in to see details", as each individual service tries to increasingly lock folks into their particular walled garden.
That's great if your life revolves around that single service/garden, but as every service(and their dog) tries to create their own proprietary platform/ecosystem whose sole purpose is to monopolize and data mine your attention, a different approach is needed if your priorities don't align with those platforms'.
...which brings us full circle to email, the universal inbox.
Anyway.
Posted Sep 7, 2021 16:41 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
I'd been using Github for a decade with an incorrect email on my account before I noticed that.
> Granted, increasingly those services just send an email that just says little more than "something happened" and "log in to see details", as each individual service tries to increasingly lock folks into their particular walled garden.
That's because email actually sucks for anything but notifications and password resets.
Posted Sep 7, 2021 16:43 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
On the contributor side, there is no insight into the status of a patchset. I have 3 sent to Git recently. One got review and needs some work. I know that is in my court. However, that work led me to make 2 other patchsets as a base. One has received no response and it's not in the "What's cooking" summary either. The other went through some iterations before another (more regular) contributor took it over. These are in some state between contribution and accepted, but I don't know anymore because that state is sitting in someone's inbox somewhere. Has CI been run? Is it pending merging? As for the ignored patchset, how long before a friendly ping? Should the ping be a new thread with a resend of all the patches? The state machine is completely hidden from view and it discourages these kinds of "hey, wouldn't this be nice?" contributions with hidden bureaucracy.
On the maintainer side, collaboration between maintainers is visible. I don't have to fight different threading styles if there are two topics about different parts of the code (replying to both on each reply versus new subthreads for each topic). I can also see CI state (has it started? finished?), who is "in charge" of reviewing it, etc. Giving a patchset to a fellow maintainer for review is a state change (which turns into an email) rather than a crafted one handing it over. It's also visible to everyone.
Additionally, when joining a project, one is (usually) lacking the email archives to be able to contribute to in-progress threads at the right place versus able to just dive in on existing discussions seamlessly. For example, if I have the same problem as someone else and there's a thread I'd like to contribute to, I'd better have *already* been a subscriber to the list or I have to wait to receive a point to latch onto it. Hope it's a relevant subthread. Of course, one could trawl the archives for Message-Id headers and craft a reply yourself, but who wants to learn how to do that in their preferred email client?
I respect that email may be more comfortable for many, but its process opacity is just maddening to me. Do I wish things worked like debbugs with email able to control things *and* have a web interface into the current state? Sure. Has anyone built one yet? No. But *my* preferences are more towards facilitating the "paperwork" for the project as a whole rather than asking everyone to come up with their own inbox-based TODO list manager.
Posted Sep 7, 2021 17:00 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (7 responses)
Indeed email is sadly one of the extremely few "universal" media which is why it has always been a supported for notifications. It's far from the only way to get notified though and many people turn off email notifications. Not everyone enjoys configuring email filters.
> but as every service(and their dog) tries to create their own proprietary platform/ecosystem whose sole purpose is to monopolize and data mine your attention..
_This_ is probably the only serious, valid and informed concern in this entire discussion. Maybe I'm too optimistic but I hope gitlab is not too bad here and best if luck to sourcehut and maybe others.
Posted Sep 7, 2021 18:13 UTC (Tue)
by pizza (subscriber, #46)
[Link] (6 responses)
Sure, nobody enjoys configuring email filters. But at least email _has_ filters!
Many people turn off app/service-specific notifications because they all follow the "PAY ATTENTION TO ME RIGHT NOW!!!!" interruption-driven paradigm where the sender thinks it's the most important thing ever, but the recipient probably doesn't agree but still suffers anyway. Email is _still_ unique in that you have the ability to configure how frequently/often/etc it polls and what sorts of stuff takes priority.
> _This_ is probably the only serious, valid and informed concern in this entire discussion. Maybe I'm too optimistic but I hope gitlab is not too bad here and best if luck to sourcehut and maybe others.
Gitlab (in of itself) is fine. So is Github. So is any individual site. But approaches that are optimal for a single service don't scale beyond more than a handful of services. It's the same thinking behind RSS aggregators/readers; instead of hitting dozens (or hundreds) of sites every day to see if something is new, it's all aggregated into a single interface. Of course sites are slowly killing off RSS in favor of more "modern" special-snowflake-site approaches, because advertising and data mining gets a lot harder to enforce.
Posted Sep 7, 2021 19:22 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (5 responses)
It's extremely funny you wrote that because this is probably the reason why I hate email the most: email gets "pushed" to me all mixed up and I have to configure something manually to separate it again. Everything else gives me some level of control on quantity and quality at the source instead and best of all: the ability not to "pull" / read it at all and ignore it completely with zero effort, by just not going there and doing nothing. Also, no other medium makes the stupid, email-like assumption that I have read it - or much worse: that I will act on it - because they just pushed it to me. This is especially obvious coming back from vacation right now...
(NNTP achieved some of this decades ago)
> Many people turn off app/service-specific notifications because they all follow the "PAY ATTENTION TO ME RIGHT NOW!!!!" interruption-driven paradigm where the sender thinks it's the most important thing ever,
I'm sure you could prove that "github is evil" in dozens of different ways but certainly not this one.
BTW no one is forced to receive all pull requests on git**b
Posted Sep 7, 2021 19:52 UTC (Tue)
by pizza (subscriber, #46)
[Link] (4 responses)
Sure, that's what happens when you aggregate lots of different things into a single place.
(The alternative is having to gather it up manually. Which works great at smaller scales)
> Everything else gives me some level of control on quantity and quality at the source instead and best of all: the ability not to "pull" / read it at all and ignore it completely with zero effort, by just not going there and doing nothing.
Pretending something doesn't exist doesn't make it go away.
> Also, no other medium makes the stupid, email-like assumption that I have read it - or much worse: that I will act on it - because they just pushed it to me.
Very few general communication systems provide a mechanism for the _sender_ to know if the message has been read (much less acted upon), and any assumptions along those lines are _social_ problems that have nothing to do with email. Heck, if anything email has a _lower_ expectation of immediate response than most other channels.
(And meanwhile, what exactly is the point of notifications, if not an expectation of follow-up actions)
> I'm sure you could prove that "github is evil" in dozens of different ways but certainly not this one.
Funny, no matter what I do I can't get github to stop sending me notifications _every single time_ something happens in my employer's organization. every new repository, every new ticket, every new discussion. Sure, that's technically not github's fault (vs my organization's boneheaded policies) but the net result is that github's official notification system is completely useless as I get drowned in the deluge of noise. Fortunately I've been able to use (gasp) email filters to redirect most of the dreck to /dev/null, and only let through stuff for the specfic projects I care about.
Much like democracy, email is the worst system around, except for all of the others.
Posted Sep 8, 2021 0:48 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (3 responses)
You missed this point. It was about not receiving things I do not care about. Like for instance most (but not all) messages on a mailing list.
> Very few general communication systems provide a mechanism for the _sender_ to know if the message has been read (much less acted upon), and any assumptions along those lines are _social_ problems that have nothing to do with email. Heck, if anything email has a _lower_ expectation of immediate response than most other channels.
I'm afraid you missed that point too, it was about shared-TODO-lists-by-email. Like the TODOs from your manager and from everyone else who thinks it's your job to do something they want. This problem has been solved a long time ago and - tada - all forges have one: it's a bug/task tracker. Forges merely added the integration with everything else.
People who keep complaining that they don't get attention when they file bugs/request miss the point: a bug tracker is by design where you can politely "file and ignore" things from unimportant people to minimize distractions. Until they pull some strings or something bad happens of course, then you just clock on the link and you don't have to run Google Search on your inbox to gather disparate threads.
In these two particular cases email is IMHO a very good example of your "PAY ATTENTION TO ME RIGHT NOW!!!!"
Posted Sep 8, 2021 2:15 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
That's a fair criticism, and for individual groups it works well. The problems come from scaling up to multiple indepdent sites, each with their own credentials and user interface notions that again aim at user lock-in and maximizing data mining opportunities vs providing tools to keep the signal:noise ratio at manageable levels.
(FWIW, I get most of my low-caring mailing list and forum stuff via gmane's nntp gateway. Superior tools for the task at hand, and all that..)
> I'm afraid you missed that point too, it was about shared-TODO-lists-by-email. Like the TODOs from your manager and from everyone else who thinks it's your job to do something they want. This problem has been solved a long time ago and - tada - all forges have one: it's a bug/task tracker. Forges merely added the integration with everything else.
Yeah, as you said this has long been a solved problem, and today you have a wide variety of solutions to choose from with various degrees of integration. Some even work well completely via email.
> In these two particular cases email is IMHO a very good example of your "PAY ATTENTION TO ME RIGHT NOW!!!!"
I'm sorry, I don't understand how this is a problem somehow unique to (or particularly exacerbated by) email? A notification is a notification is a notification, and while it's intended to get your attention, you're free to ignore it [1] no matter what channel it takes before it lands in front of your eyeballs. (Since we're talking about interacting with external services that presumably maintain their own state independent of whatever client you use to access them.)
Email provides capabilities to manage that stuff (at the individual level) that other channels usually lack, especially in aggregate, albeit with the disadvantage of requiring a more advanced client setup than what (eg) the android gmail (or worse, outlook) clients provide. But setting that up takes upfront, inconveniencing effort, so hardly anyone bothers to try any more.
Look, forges offer a _lot_ of advantages for software development; I'm not disputing that! If something like sourcehut was available fifteen years ago I'd not have bothered with my current mis-mash of gitolite+cgit, flyspray, dokuwiki, mailman, and whatnot, used nearly entirely for my own stuff. But it wasn't, and I needed the on-premise capabilities each of those tools provided, so here I am, with a couple decades' worth of legacy baggage (ie data) that heavily weighs down one side of the cost/benefit curve.
[1] You may face social or employment consequences for ignoring certain notifications, but that's an entirely different matter.
Posted Sep 8, 2021 6:38 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (1 responses)
The problem with pure email "workflows" is the notification is the data and the data is the notification.
Posted Sep 8, 2021 11:42 UTC (Wed)
by pizza (subscriber, #46)
[Link]
> The problem with pure email "workflows" is the notification is the data and the data is the notification.
Well, yeah, but I thought we weren't talking about "pure email workflows" -- As opposed to using email for notifications by external services. (vs sms, special snowflake per-application mechanisms, manual polling, a colleague throwing something at you, etc)
Even debbugs' and emacs' email-based bug trackers are centralized and don't rely on the client to maintain any state.
Posted Sep 9, 2021 18:19 UTC (Thu)
by debacle (subscriber, #7114)
[Link] (7 responses)
As someone who does not have a mobile phone (mainly because I don't have a use case for being permanently tracked), I find that bizarre. Why would I want to get discussions on a probably small screen, maybe while cycling to work or dining at a friends place?
Posted Sep 10, 2021 0:10 UTC (Fri)
by pabs (subscriber, #43278)
[Link] (3 responses)
Posted Sep 10, 2021 0:37 UTC (Fri)
by debacle (subscriber, #7114)
[Link] (2 responses)
Posted Sep 10, 2021 0:52 UTC (Fri)
by pabs (subscriber, #43278)
[Link] (1 responses)
https://www.bbc.com/news/world-australia-47072023
Posted Sep 10, 2021 1:55 UTC (Fri)
by debacle (subscriber, #7114)
[Link]
Posted Sep 14, 2021 13:33 UTC (Tue)
by jezuch (subscriber, #52988)
[Link] (1 responses)
Posted Sep 15, 2021 12:47 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Sep 14, 2021 14:52 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
I commute further than you do, and find it useful to get notified on the move. I don't want to get the laptop out while travelling at 70 MPH on the motorway (it's inconvenient for the people around me), but I do have my phone in use as a television or eReader while travelling.
If I get a notification, I can read it on the phone and decide whether I'm going to get the laptop out and work, or leave it until I'm in the office/at home.
The exact point at which I'll switch from phone to laptop depends on how busy it is; when I've got people on all sides, getting the laptop out to work is very antisocial, whereas when the coach is under 1/4th full, it's barely a problem to have it out for the entire journey.
Posted Sep 13, 2021 8:41 UTC (Mon)
by grothesque (guest, #130832)
[Link] (6 responses)
The way it currently is, notifications arrive as a stream of opaque messages that are impossible to digest other than by looking at each body. Their utility could be greatly improved by simply making better use of basic headers (Subject, To, Cc, In-Reply-To) in a way that mimics a real mailing list.
Unfortunately, not many people seem to experience this as a problem or the following issue would have received more attention:
Posted Sep 14, 2021 5:12 UTC (Tue)
by pabs (subscriber, #43278)
[Link] (5 responses)
Posted Sep 14, 2021 10:31 UTC (Tue)
by grothesque (guest, #130832)
[Link] (4 responses)
The subjects could be still more useful... For example instead of simply using the same subject for all messages in the thread (e.g. "Backport blabla fixes from master (!395)"), the action that triggers the notification could be included, e.g. "merged: Backport blabla fixes from master (!395)".
Same for the use of To/Cc (see the issue).
Posted Sep 14, 2021 11:38 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Granted, there may be ways to make these clients behave sensibly, but it's not the default AFAIK.
Posted Sep 14, 2021 22:07 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (1 responses)
Or, in the not uncommon case that a change of subject in a long-running discussion really did herald a shift in what was being discussed, I could break so that the new subject was visible at the top level and thus easier to find.
Oh for intelligent clients that follow the rules BY DEFAULT, but allow you to break them where appropriate.
Cheers,
Posted Sep 15, 2021 17:05 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
Mutt allows this too (I just delete `In-Reply-To` in the message editor). I think there's a "break thread" command as well, but I almost never use it. I can even stitch together broken threads (though it seems that offlineimap doesn't sync that around, so it is fixed per client).
Posted Sep 14, 2021 11:56 UTC (Tue)
by pabs (subscriber, #43278)
[Link]
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Wol
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Wol
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
> being deliberatly archaic.
> are using these days for the generic/collective form of GitHub/GitLab/Gitea/Bitbucket/Sourcehut
> style collaborative development and code hosting services?
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Forges
Forges
Forges
Wol
Forges
Forges
Forges
Forges
Forges
Forges
Forges
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
The concept of running local software is becoming obsolete,
Emacs discusses web-based development workflows
The chief executive officer of Sun Microsystems said Monday that consumer privacy issues are a "red herring."
===
Emacs discusses web-based development workflows
“Privacy is dead. Get over it.” proclaimed Mark Zuckerberg in a TechCrunch Interview in 2010
Emacs discusses web-based development workflows
Facebook founder and CEO Mark Zuckerberg recently went on record speaking the same sentiments [...]"), and didn't read down to where it's actually a quote from McNealy.
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
I am unable to find a copy of the original Techcrunch article that doesn't require me to read, understand and agree to 3,500 words of legally binding cookie/privacy terms before being able to access it
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
> So why aren't we all using Windows?
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
> Surely they had to struggle a bit when they first started to use Git for example, but they persevered and now they know more than they knew then.
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
> The more you learn about similar things the easier it gets to learn about other similar things.
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
> I'd type "report a bug in emacs" into my search engine, and lo, detailed instructions are the first result.
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
> I did only a cursory reading of the instructions I found <https://www.gnu.org/software/emacs/manual/html_node/efaq/...> and, finding that it involved using Emacs, concluded it would probably make sense to an Emacs user (which I am not).
Emacs discusses web-based development workflows
M-x report-emacs-bug. It sets up a mail buffer with the essential information and the correct e-mail address, bug-gnu-emacs@gnu.org. Anything sent there also appears in the newsgroup news:gnu.emacs.bug, but please use e-mail instead of news to submit the bug report. This ensures a reliable return address so you can be contacted for further details.
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
> This is the American perspective, where to a first approximation, everyone drives an automatic, and many people have never driven a stick. In Europe, for reasons which are unclear to me, everyone drives a stick.
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
* To the extent they are real, the likely consequences of sticking with email.
* The likely consequences of switching to a forge-based workflow, including the negative consequences.
* How to weigh those consequences against one another.
Emacs discusses web-based development workflows
Wol
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Wol
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows - Offtopic on gear changes
From Emacs to automatic gearboxes
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
To the extent that the future can be predicted with any accuracy, at this point one would have to guess that 20—or 30—years from now email-based workflows will be dead or nearly so.
This kind of prediction has been made often. Sometimes it has turned out to be true, often not. I remember that we all should switch from cvs to svn, because it's the future (and then arch and then bzr). Or, in hardware design, maybe 20 years ago Verilog was supposed to have no future, because VHDL would be taking over. Some decades later svn, arch, and bzr are at least as marginal as cvs, and Verilog dominates over VHDL (at least for large projects). Concerning "forges", Sourceforge, from which the name is derived, is marginal, while email is still used widely.
Emacs discusses web-based development workflows
git then came along in 2005 but I think it took a few years before it was widely known and used outside of the Linux kernel community.
Emacs discusses web-based development workflows
I only got exposed to svn (work moved from clearcase to svn) when I was already using git, so that felt backwards. Fortunately I never really had to use svn, as git-svn came to the rescue.
If svn was a significant improvement over cvs for you, that was a good reason to change. OTOH, it would not have been for us, and we would only have done it because it was the thing to do at the time. And that's not a sufficient reason to do it, because the change has a significant cost to the existing maintainers. And likewise, just because putting the project on the forge of the year is the thing to do this year is not a sufficient reason to change an existing project in this way.
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Github has existed since 2008, that's almost 14 years. It's quite clear that this model of development is not going away.
Emacs discusses web-based development workflows
Is github even in the running for the Emacs forge? My impression is that it is not.
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
For Samba, which I led on the transition from e-mail based workflow to GitLab it was CI that was sufficient carrot that we moved.
CI is the killer, followed by patch tracking (for Samba)
Emacs discusses web-based development workflows
* I do realize there are always going to be people who look at ancient Beowulf text and go 'dang that is so clear and I believe we should go back to talking and writing like that'. However if they aren't able to get a chair at some academy, they end up reading mostly 'modern' fiction like Chaucer or older Latin where there is a larger amount of 'code' written.
* I am not advocating rewriting emacs in some other language. I am trying to say that if you want emacs to be useful make LISP useful to a larger audience for people in 2031 versus 2021 or 2001.
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
http://gamma-level.com/iphoneos/ports/emacs
True, with an external keyboard it becomes less strange. In fact, only recently I compiled the experimental "mobile enabled" Debian package of dino-im on a Mobian PinePhone first. However, I was logged in via SSH from my huge, 32 cm screen X220 :-) But I'm probably too old to use such a device for anything serious.
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Email-based workflow does not seems to be much in demand nowadays
https://gitlab.com/gitlab-org/gitlab/-/issues/28974
Email-based workflow does not seems to be much in demand nowadays
Email-based workflow does not seems to be much in demand nowadays
Email-based workflow does not seems to be much in demand nowadays
Email-based workflow does not seems to be much in demand nowadays
Wol
Email-based workflow does not seems to be much in demand nowadays
Email-based workflow does not seems to be much in demand nowadays