|
|
Log in / Subscribe / Register

Emacs discusses web-based development workflows

By Jake Edge
September 1, 2021

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).

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.

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:
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.


to post comments

Emacs discusses web-based development workflows

Posted Sep 1, 2021 23:22 UTC (Wed) by dvdeug (subscriber, #10998) [Link] (6 responses)

> You also need to have an internet connection at the moment that you try to use the web forum. Not so for sending email.

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.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 10:03 UTC (Thu) by rsidd (subscriber, #2582) [Link] (1 responses)

You can use gmail (mobile app) to send mail offline. It will queue the mail and send when you get back online.

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.

Emacs discusses web-based development workflows

Posted Sep 8, 2021 15:21 UTC (Wed) by tbelaire (subscriber, #141140) [Link]

(Disclosure: I work on Gmail, my teammates worked on this)

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

Emacs discusses web-based development workflows

Posted Sep 2, 2021 11:48 UTC (Thu) by aragilar (subscriber, #122569) [Link] (3 responses)

Maybe it depend where you live, but I'd say internet is less reliable here than power (rain seems to take out the former, not the latter). Especially around travel (assuming we all get back to doing that...), it usually easier to find somewhere to charge a laptop, rather than getting internet (especially reliable internet).

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.

Emacs discusses web-based development workflows

Posted Sep 4, 2021 18:34 UTC (Sat) by Wol (subscriber, #4433) [Link] (2 responses)

> Maybe it depend where you live, but I'd say internet is less reliable here than power (rain seems to take out the former, not the latter). Especially around travel (assuming we all get back to doing that...), it usually easier to find somewhere to charge a laptop, rather than getting internet (especially reliable internet).

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,
Wol

Emacs discusses web-based development workflows

Posted Sep 8, 2021 7:09 UTC (Wed) by RobertBrockway (guest, #48927) [Link] (1 responses)

That just sounds like your ISP has over-subscribed for their available capacity. Consider changing ISP. If they are all doing it in your area consider (a) leaving or (b) starting an ISP that doesn't over-subscribe.

Emacs discusses web-based development workflows

Posted Sep 8, 2021 7:47 UTC (Wed) by Wol (subscriber, #4433) [Link]

Nah. WHICH other ISP?

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,
Wol

Emacs discusses web-based development workflows

Posted Sep 2, 2021 4:12 UTC (Thu) by halla (subscriber, #14185) [Link] (19 responses)

Just using the word "forge" already signals a huge amount of out-of-touchness...

Emacs discusses web-based development workflows

Posted Sep 2, 2021 10:15 UTC (Thu) by Karellen (subscriber, #67644) [Link] (17 responses)

Really? Darn it. So, bring me up to speed, what is the New Hotness terminology that "the kids" 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

Posted Sep 2, 2021 10:25 UTC (Thu) by jafd (subscriber, #129642) [Link] (1 responses)

I think it's github. Like all graphical manipulation is "photoshop" even if gimp is used. Or like your mp4's and mp3's all become "tapes" if there is sex or damning evidence on them.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 15:58 UTC (Thu) by Karellen (subscriber, #67644) [Link]

In informal usage, maybe.

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.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 15:19 UTC (Thu) by halla (subscriber, #14185) [Link] (14 responses)

"Forge" goes back to SourceForge, and that's ancient history. Using that word to describe current collaboration platforms is, of course, being deliberatly archaic.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 15:31 UTC (Thu) by jake (editor, #205) [Link] (13 responses)

> Using that word to describe current collaboration platforms is, of course,
> being deliberatly archaic.

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"
> are using these days for the generic/collective form of GitHub/GitLab/Gitea/Bitbucket/Sourcehut
> style collaborative development and code hosting services?

so, if we don't want to be hopelessly archaic, what term do you suggest?

thanks,

jake

Emacs discusses web-based development workflows

Posted Sep 2, 2021 16:02 UTC (Thu) by samlh (subscriber, #56788) [Link]

I don't think there is a short term in common use, so I recommend using a descriptive phrase like web-based code collaboration platform and/or listing examples. (My younger coworkers have never heard of SourceForge.)

Emacs discusses web-based development workflows

Posted Sep 2, 2021 17:13 UTC (Thu) by halla (subscriber, #14185) [Link] (10 responses)

"collaboration platform" -- and I was under the impression that "forge" was a quote from the actual discussion, not an editorial term.

Forges

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.

Forges

Posted Sep 5, 2021 8:33 UTC (Sun) by samlh (subscriber, #56788) [Link] (8 responses)

Well, let's see what everyone calls themselves, shall we?

https://github.com/about

> "... the largest and most advanced development platform in the world."

https://about.gitlab.com/

> "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."

https://launchpad.net/

> "Launchpad is a software collaboration platform that provides:..."

https://gogs.io/

> "Gogs is a painless self-hosted Git service"

https://docs.pagure.org/pagure/

> "Pagure is a light-weight git-centered forge based on pygit2."

https://gitea.io/en-us/

> "Gitea is a community managed lightweight code hosting solution written in Go."

https://sourcehut.org/

> "Welcome to sourcehut, the hacker's forge! ... This suite of open source tools is the software development platform you've been waiting for."

https://www.phacility.com/

> "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"

Forges

Posted Sep 5, 2021 9:55 UTC (Sun) by Wol (subscriber, #4433) [Link] (2 responses)

> There is no agreement on what this sort of service should be called, and calling it a "Forge" is relatively uncommon.

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,
Wol

Forges

Posted Sep 5, 2021 12:34 UTC (Sun) by mpr22 (subscriber, #60784) [Link] (1 responses)

> Like German creates massively long complex nouns.

"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.

Forges

Posted Sep 6, 2021 10:03 UTC (Mon) by bosyber (guest, #84963) [Link]

both of those latter would probably quickly become something like RiFEwAUG and DDSGK; yes long words are fun at times, but shortening them for daily use definitely is part of the fun!

Forges

Posted Sep 7, 2021 14:52 UTC (Tue) by marcH (subscriber, #57642) [Link] (4 responses)

Thanks for putting this list together, very useful. My conclusion: "forge" is the only _single-word_ used. All the other names are made of multiple words with adjectives on top of some placeholder like "service" or "application".

> 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.

Forges

Posted Sep 7, 2021 18:08 UTC (Tue) by samlh (subscriber, #56788) [Link] (3 responses)

> Yet you knew instantly what it meant, which is what matters.

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.

Forges

Posted Sep 7, 2021 19:10 UTC (Tue) by marcH (subscriber, #57642) [Link]

> I was able to figure it out from context

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.

Forges

Posted Sep 7, 2021 20:17 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

> 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

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.

Forges

Posted Sep 8, 2021 0:53 UTC (Wed) by marcH (subscriber, #57642) [Link]

> Just because SF towards the tail end (not coincidentally) became undesirable doesn't mean "forge" as a word is somewhat permanently tainted.

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.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 6:40 UTC (Fri) by ddevault (subscriber, #99589) [Link]

Forge is the generally accepted industry term. Your use here is correct.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 19:28 UTC (Fri) by marcH (subscriber, #57642) [Link]

> Just using the word "forge" already signals a huge amount of out-of-touchness...

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.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 4:46 UTC (Thu) by pabs (subscriber, #43278) [Link] (19 responses)

The concept of running local software is becoming obsolete, I suspect there are already lots of people using web based editors and IDEs (like Atom and VS Code) than using Emacs and I wouldn't be surprised if the git based forges plan to make that the main if not only way to publish to them. Personally I find this horrifying, but probably Emacs should start looking at becoming a web based platform if it wants to remain relevant to the latest trends in software development. Or just leave people following trends to never use or contribute to Emacs.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 8:12 UTC (Thu) by ibukanov (subscriber, #3942) [Link]

Atom and VS Code do not require on-line connectivity. And the only web-basedness in them is that they use Chromium rendering engine. Surely there are features and extensions in them that depends in essential way on online connectivity like remote editing or settings sync across devices, but these are optional.

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.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 16:19 UTC (Thu) by Karellen (subscriber, #67644) [Link] (15 responses)

The concept of running local software is becoming obsolete,

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.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 16:39 UTC (Thu) by smoogen (subscriber, #97) [Link] (4 responses)

That was Scott McNeally in 1998/1999. https://www.wired.com/1999/01/sun-on-privacy-get-over-it/

===
The chief executive officer of Sun Microsystems said Monday that consumer privacy issues are a "red herring."

"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."
===

Emacs discusses web-based development workflows

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 dead. Get over it.” proclaimed Mark Zuckerberg in a TechCrunch Interview in 2010

-- 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.)

Emacs discusses web-based development workflows

Posted Sep 2, 2021 19:15 UTC (Thu) by excors (subscriber, #95769) [Link] (1 responses)

> McNeally may have said it (or something similar) first, or at least before Zuckerberg, but Zuckerberg has definitely repeated the statement

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.
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

Posted Sep 3, 2021 1:12 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

I have definitely used this phrase personally before 2010 (in my email archive). I remember reading about it around early 2000-s.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 7:21 UTC (Fri) by anselm (subscriber, #2796) [Link]

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

Privacy may be dead but apparently it hasn't fallen over yet.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 1:12 UTC (Fri) by pabs (subscriber, #43278) [Link] (9 responses)

The problem is that Emacs/GNU/oldschool developers do not have significant influence on the world population, nor even of the world developer population. The people that do have influence are changing the way the majority of people/developers do things and think about things. So eventually, the software development style (or interaction style etc) chosen by the folks with influence will become dominant. This has already resulted in people wanting Emacs to switch away from email/patches and the same mechanism behind that can cause other changes to be demanded of Emacs, perhaps worse ones like moving to a web SaaSS, permissive licensing or telemetry. That potential tradeoff; either stick to your principles or become relevant by embracing recent trends.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 10:39 UTC (Fri) by pizza (subscriber, #46) [Link] (8 responses)

> The people that do have influence are changing the way the majority of people/developers do things and think about things.

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.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 10:54 UTC (Fri) by ilammy (subscriber, #145312) [Link]

> > The people that do have influence are changing the way the majority of people/developers do things and think about things.
> So why aren't we all using Windows?

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.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 11:11 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (6 responses)

> 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 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.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 11:46 UTC (Fri) by pizza (subscriber, #46) [Link] (5 responses)

Sure, it's a strawman, but hardly extreme in this context. It is a logical conclusion of appealing to the majority trends as a measure of validity and worth.

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.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 15:52 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

It’s still an extreme strawman to pretend that it has to be all or nothing. Plenty of old projects have migrated to forges without changing any other core aspects of the software.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 16:30 UTC (Fri) by pizza (subscriber, #46) [Link] (3 responses)

> It’s still an extreme strawman to pretend that it has to be all or nothing. Plenty of old projects have migrated to forges without changing any other core aspects of the software.

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.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 16:41 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

> Changing everything about how you develop software is the _entire point_ of moving the the forge model.

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

Emacs discusses web-based development workflows

Posted Sep 3, 2021 18:09 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> It is also possible for forges to be optional and not exclusive.

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)

Emacs discusses web-based development workflows

Posted Sep 3, 2021 18:44 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

> Sure, just like it's possible to get MS Outlook to sanely handle inline email replies.

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.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 18:44 UTC (Thu) by jwarnica (subscriber, #27492) [Link] (1 responses)

Per the last Emacs article here, the problem to become a web based environment is at as much as upgrading to GTK-whatever. Emacs is simply not written to modern software development standards. While it was quite magical in the early/mid 80's getting text on a screen in a responsive way, this magic is obsolete and is very messy. The deepest parts of the text processing engine are mixed with the text rendering engine in ways that make developers versed in modern paradigms consider transporter accidents.

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..

Emacs discusses web-based development workflows

Posted Sep 4, 2021 18:56 UTC (Sat) by eliz (guest, #94829) [Link]

> Emacs is simply not written to modern software development standards. While it was quite magical in the early/mid 80's getting text on a screen in a responsive way, this magic is obsolete and is very messy. The deepest parts of the text processing engine are mixed with the text rendering engine in ways that make developers versed in modern paradigms consider transporter accidents.

I don't know what you are describing here, but it isn't Emacs.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 7:07 UTC (Thu) by ddevault (subscriber, #99589) [Link] (2 responses)

SourceHut maintainer here, happy to answer any questions for the curious.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 9:22 UTC (Thu) by tlamp (subscriber, #108540) [Link] (1 responses)

SourceHut seems in general quite close to what I'd look for A few question/comments.

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?

Emacs discusses web-based development workflows

Posted Sep 2, 2021 9:27 UTC (Thu) by ddevault (subscriber, #99589) [Link]

> 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?

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).

Emacs discusses web-based development workflows

Posted Sep 2, 2021 7:28 UTC (Thu) by beshr (guest, #133204) [Link] (31 responses)

This is the same old "it's not exactly as user friendly as I expect to be at this exact moment" issue. I don't understand the reasoning behind why everything should be exactly as easy and comfortable to a person at first approach, or why some think it's not worth the effort to learn. 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. Why is this any different? You can list pros and cons for each method and they'd probably apply to some group or another, but the question is really how difficult is it to learn how to contribute to a mailing list driven project? The answer is really not that much more than learning how to get comfortable with the command line or navigating your way around a git repo, ie. doable with guidance and persistence. People who have long been using github-flow or the likes can vouch that it comes with it's own set of problems and learning curve. I think these x-flow methods all seem simple in mini to small projects, but larger projects have a similar-but-different set of hurdles that contributes need to learn how to maneuver.

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.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 11:31 UTC (Thu) by khim (subscriber, #9252) [Link] (28 responses)

> 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.

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.

> the question is really how difficult is it to learn how to contribute to a mailing list driven project?

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?

Emacs discusses web-based development workflows

Posted Sep 2, 2021 11:56 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

> 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

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.

Emacs discusses web-based development workflows

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.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 13:30 UTC (Thu) by beshr (guest, #133204) [Link] (25 responses)

> 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).

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.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 14:04 UTC (Thu) by khim (subscriber, #9252) [Link] (5 responses)

> The more you learn about similar things the easier it gets to learn about other similar things.

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.

> There's value in variety.

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.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 12:05 UTC (Fri) by jkingweb (subscriber, #113039) [Link] (4 responses)

> 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.

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.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 12:24 UTC (Fri) by khim (subscriber, #9252) [Link] (3 responses)

> I'd type "report a bug in emacs" into my search engine, and lo, detailed instructions are the first result.

“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.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 13:15 UTC (Fri) by jkingweb (subscriber, #113039) [Link] (2 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'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.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 13:49 UTC (Fri) by khim (subscriber, #9252) [Link] (1 responses)

> 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).

So… you have found the page and haven't actually bothered to actually read it? Let me do that for you:

The correct way to report Emacs bugs is to use the command 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.

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.

> 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.

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?

> 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.

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.

Emacs discusses web-based development workflows

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.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 17:11 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (18 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.

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.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 17:27 UTC (Thu) by khim (subscriber, #9252) [Link] (2 responses)

> 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.

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.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 13:37 UTC (Fri) by Sesse (subscriber, #53779) [Link]

In large parts of Europe, you really do need a car, just like in the US.

(I don't have one, and not even a driver's license, but I live in a city, and I occasionally miss having one.)

Emacs discusses web-based development workflows

Posted Sep 3, 2021 17:20 UTC (Fri) by JanC_ (guest, #34940) [Link]

The real reason why stick shifts are more common in Europe is that we tend(ed) to use smaller/cheaper cars, and automatics used to be more expensive & heavier. In a small car, the extra power required would also have forced a more powerful engine, and in some cases the car would have become 20% more expensive or so.

Larger/luxury cars always were much more commonly sold with an automatic, and of course hybrid & electrical cars (usually?) have them too…

Emacs discusses web-based development workflows

Posted Sep 2, 2021 19:12 UTC (Thu) by beshr (guest, #133204) [Link] (1 responses)

> Arguing about *why* developers don't want to use email is a completely non-sequitur

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.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 22:15 UTC (Thu) by NYKevin (subscriber, #129325) [Link]

Nobody is compelling Emacs to do anything. If they are satisfied with their current situation, they have every right to stick with email. Every decision carries consequences, and in this case, there are legitimate concerns that they may be handicapping their long-term developer growth. They need to take responsibility for their project and determine:

* Whether those concerns are real or imagined, in the specific case of Emacs.
* 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.

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.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 20:10 UTC (Thu) by Wol (subscriber, #4433) [Link] (9 responses)

> (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.)

Less so nowadays, but sticks are noticeably more efficient (greater mpg), and fuel is a *LOT* more expensive.

Cheers,
Wol

Emacs discusses web-based development workflows

Posted Sep 2, 2021 22:30 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

> Less so nowadays, but sticks are noticeably more efficient (greater mpg), and fuel is a *LOT* more expensive.

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.

Emacs discusses web-based development workflows

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?

Emacs discusses web-based development workflows

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.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 10:17 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 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.

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,
Wol

Emacs discusses web-based development workflows

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.

Emacs discusses web-based development workflows

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:

  1. Some automatics are clutch-based transmissions instead of torque converter with lockup, which gets you the same mechanical efficiency through the gearbox, but with the computer control making better choices of gear than the human in the driver's seat.
  2. Torque converter style automatics now have more gears than a human can reasonably row through; 8 and 10 speed are not uncommon in the market. This means that the gearbox is able to keep the engine in the most efficient part of its rev range where a manual gearbox has to use a compromise gear - e.g. a 6 speed might be best in 4th at a given speed, where the 8 speed can use the equivalent of 4.4th and get better engine efficiency.

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.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 17:28 UTC (Fri) by JanC_ (guest, #34940) [Link] (2 responses)

Some electrical cars use a CVT gearbox (possibly built into the engine) and/or a separate gear set for riding uphill (or also in other situations maybe?), but it’s true that they don’t have clutch-based stick shifts.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 22:48 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Almost all purely electric cars have direct connection from the motor(s) to wheels, through a fixed-gear gearbox.

Emacs discusses web-based development workflows

Posted Sep 7, 2021 1:09 UTC (Tue) by JanC_ (guest, #34940) [Link]

I know most commercial electrical cars do right now, but I saw e.g. one Belgian solar race car which had a purposely built 2-gear gearbox built into the motor package (by the manufacturer/sponsor), which helped them win a solar race somewhere in South America because it allowed them to go up steep climbs more efficiently.

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.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 2:23 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 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.

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.

Emacs discusses web-based development workflows - Offtopic on gear changes

Posted Sep 3, 2021 10:26 UTC (Fri) by amacater (subscriber, #790) [Link]

Ah yes, double de-clutching to enable you to move easily through the gears - you don't need to over-rev the engine though ... the point being that if you're used to driving a manual gearbox, you can adjust to any manual gearbox. [I passed my driving in an automatic and drive on hand controls as a disabled driver - but the restriction on my licence has been removed. The best car I've driven was actually a Smart car which has electronic gear change on paddles on the steering column anyway].

From Emacs to automatic gearboxes

Posted Sep 3, 2021 16:35 UTC (Fri) by marcH (subscriber, #57642) [Link]

> (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.)

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)

Emacs discusses web-based development workflows

Posted Sep 2, 2021 22:03 UTC (Thu) by rodgerd (guest, #58896) [Link] (1 responses)

> I don't understand the reasoning behind why everything should be exactly as easy and comfortable to a person at first approach,

No-one is asking you to. But don't whine about it when no-one shows up to work on your project.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 22:58 UTC (Thu) by pizza (subscriber, #46) [Link]

> No-one is asking you to. But don't whine about it when no-one shows up to work on your project.

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.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 9:08 UTC (Thu) by anton (subscriber, #25547) [Link] (7 responses)

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.

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).

Emacs discusses web-based development workflows

Posted Sep 2, 2021 9:57 UTC (Thu) by mfuzzey (subscriber, #57966) [Link] (2 responses)

svn was released in 2000 and was a significant improvement over cvs which had been around since 1986 (and widely distributed since 1990)
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.

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.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 10:28 UTC (Thu) by geert (subscriber, #98403) [Link]

My personal timeline looks slightly different: between cvs and git, there was bk.
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.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 11:20 UTC (Thu) by anton (subscriber, #25547) [Link]

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.

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.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 2:31 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (2 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.
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

Posted Sep 3, 2021 6:38 UTC (Fri) by NYKevin (subscriber, #129325) [Link]

GitHub is so old, other forge sites are often simply described as "like GitHub but better/different/[other adjective]" or as "like GitHub for [noun]." The notion that it's a passing fad would be hilarious, if people did not actually believe it.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 13:53 UTC (Fri) by anton (subscriber, #25547) [Link]

Is github even in the running for the Emacs forge? My impression is that it is not.

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.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 17:19 UTC (Fri) by marcH (subscriber, #57642) [Link]

> . Concerning "forges", Sourceforge, from which the name is derived, is marginal, while email is still used widely.

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.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 12:58 UTC (Thu) by daenzer (subscriber, #7050) [Link] (2 responses)

To me, a killer feature of forges is integrated CI which allows catching (at least some) regressions before they even make it to the main development branch.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 13:14 UTC (Thu) by ddevault (subscriber, #99589) [Link]

SourceHut provides this.

CI is the killer, followed by patch tracking (for Samba)

Posted Sep 4, 2021 20:44 UTC (Sat) by abartlet (subscriber, #3928) [Link]

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.

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.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 15:09 UTC (Thu) by smoogen (subscriber, #97) [Link] (11 responses)

There is no one issue with getting contributors to Emacs but a series of 'small' ones starting with the fact that the language it is written in hasn't been taught in most computer science programs for over 20 years. Even in the early 1990's, it was usually only taught as a 'here is language that I got my Phd thesis in and I spent 2 weeks getting compiled on our 'variant' Unix box for this course'. By the 2000's, most students would get a 'here is what it looks like' but nothing beyond that. At this point, the language reads more like Beowulf than Shakespeare to most people who might be interested in coding it. And there is very little in the way of useful communication on how to read it for most people.

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:
* 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

Posted Sep 2, 2021 17:25 UTC (Thu) by karim (subscriber, #114) [Link] (6 responses)

I've been using emacs for as long as I can remember using *nix (25+ years). And you're right, I took a graduate Lisp class in the '90s, which made me realize how I hated that approach to programming (I had learned Forth before that and I actually liked that much more.) Despite having learned some Lisp and despite how long I've used emacs, I have *never* bothered to program anything for it, or try to understand any extensions written for it. Instead, I keep googling for snipets to copy-paste into my .emacs files, and trying to tweak them whenever I need.

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.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 17:47 UTC (Thu) by smoogen (subscriber, #97) [Link] (5 responses)

Understood.. that is how I have been using emacs. It is hard coded into my brain too much to find most other editors 'useful' to me, but I really 'hate' programming much in it. And yes emacs will probably last for more years in a slowly decaying state. However as all of us 1990's people reach our own 60's.. at some point the 30 year olds running the distros in 10 years or so will say 'why?' and tell us to use something they can support.. [sort of like we did in the 1990's to the people who had editors written in Algol68 or Fortran IV]

Emacs discusses web-based development workflows

Posted Sep 2, 2021 17:52 UTC (Thu) by karim (subscriber, #114) [Link]

We're on the same page.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 6:49 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (3 responses)

As a vim user who has never seriously touched Emacs... my 2¢ is that the language you program your editor in *should* suck (e.g. VimL is an awful language to program in). It discourages you from trying to do anything too ridiculous instead of running a separate program. vim is a tool I start when I want to edit a file. If I want to do something else, I run an appropriate command or write code in a language which is actually reasonable (usually zsh or Python). If I want to modify the contents of a buffer, I use vim's built-in filtering support (see https://vimhelp.org/change.txt.html#filter) and do all the hard parts outside of vim. If for some godforsaken reason I actually want IDE-like functionality, I (grumble and) fire up an IDE. But that is rare in my experience, possibly because SREs are doing a lot of systems orchestration and not a lot of "look at my gigantic Java monstrosity with 50k classes."

Emacs discusses web-based development workflows

Posted Sep 3, 2021 12:58 UTC (Fri) by smoogen (subscriber, #97) [Link] (2 responses)

To be honest, vim is so much closer to emacs that comparing them is more about which keys I press to get to an end of a line versus anything else. [Heck turn on all the bells and whistles and vim will out memory use than 'Eighty Megs And Constantly Swapping' (EMACS)]. But in the end, I have seen more Linux people (from 60 year olds to 20 year olds) use vscode than emacs or vi in the last several years to edit everything from conf files to coding new things. I would not have ever expected that 30 years ago.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 13:36 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> But in the end, I have seen more Linux people (from 60 year olds to 20 year olds) use vscode than emacs or vi in the last several years to edit everything from conf files to coding new things. I would not have ever expected that 30 years ago.

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.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 14:41 UTC (Fri) by zdzichu (subscriber, #17118) [Link]

Try this: go to Github, click on any source file and press '.' (dot). This is Microsoft integrating its product, Emacs can't possibly beat that.

Emacs discusses web-based development workflows

Posted Sep 4, 2021 0:28 UTC (Sat) by dvdeug (subscriber, #10998) [Link] (3 responses)

I don't believe the language is that much of a problem. Yes, it's not a language most people will have learned in school, but it's hardly APL, or even Awk or BLISS. Syntax is trivial, and if you've done some poking around in Scala or ML or Haskell, you've probably got the recursive list thing down. The only time I touched it in school was choosing Common Lisp to solve a problem in OS class, because hey, what better time then now?

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.

Emacs discusses web-based development workflows

Posted Sep 4, 2021 16:57 UTC (Sat) by marcH (subscriber, #57642) [Link]

Trying to learn the language to isolate a crash and understand some tramp issues was fun. OK, surely not everyone's taste of fun but if you're using Emacs you're not "anyone" anyway in the first place.

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.

Emacs discusses web-based development workflows

Posted Sep 5, 2021 15:26 UTC (Sun) by smoogen (subscriber, #97) [Link] (1 responses)

I should have been clearer about my concern about the language. Finding out about LISP is hard enough, but finding out about how Emacs LISP differs or does things is even harder.

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.

Emacs discusses web-based development workflows

Posted Sep 5, 2021 18:40 UTC (Sun) by jem (subscriber, #24231) [Link]

>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.

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.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 15:19 UTC (Thu) by pj (subscriber, #4506) [Link] (2 responses)

> Network effects

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.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 6:29 UTC (Fri) by flussence (guest, #85566) [Link]

Gitea appears to be making serious efforts to that end: https://github.com/go-gitea/gitea/issues/16518

Emacs discusses web-based development workflows

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.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 18:14 UTC (Thu) by iabervon (subscriber, #722) [Link] (1 responses)

What I'd like to see is a mailing list archive that knows about the version control system and can present emails containing patches like github presents PRs. There's really a lot that could be done to provide good web access to email-native content, and there are now good examples of presenting the content that we have in certain email messages in much more contextual detail than the message directly contains.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 19:38 UTC (Fri) by IanKelling (subscriber, #89418) [Link]

I think sourcehut tries to do that. I've just created a sourcehut.gnu.org vm, I hope people have time to volunteer and get it up and available for all gnu packages.

Emacs discusses web-based development workflows

Posted Sep 6, 2021 10:16 UTC (Mon) by taladar (subscriber, #68407) [Link] (18 responses)

I wonder if the issue might not be that existing, invested developers see no issue with reading every message on a mailing list while it seems quite overwhelming to a newcomer, even one comfortable with email.

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.

Emacs discusses web-based development workflows

Posted Sep 6, 2021 20:15 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (3 responses)

> 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.

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...

Emacs discusses web-based development workflows

Posted Sep 6, 2021 21:27 UTC (Mon) by rodgerd (guest, #58896) [Link] (1 responses)

I still run an MTA successfully, off a residential IP no less. However, I started doing that 20 years ago, and have generally been pretty religious about jumping through the ever-increasing hoops imposed by the mail monopolies.

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.

Emacs discusses web-based development workflows

Posted Sep 7, 2021 14:28 UTC (Tue) by marcH (subscriber, #57642) [Link]

> However, I started doing that 20 years ago, and have generally been pretty religious about jumping through the ever-increasing hoops imposed by the mail monopolies.

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...

Emacs discusses web-based development workflows

Posted Sep 20, 2021 19:07 UTC (Mon) by flussence (guest, #85566) [Link]

DKIM and SPF aren't that hard to do if you've got a decent DNS provider (SPF is one TXT record, DKIM is that plus a milter daemon). That precludes most of the crappy free dyndns services that only give you an A record, but given the state things are already in that seems like an acceptable barrier to entry.

Emacs discusses web-based development workflows

Posted Sep 6, 2021 21:30 UTC (Mon) by rodgerd (guest, #58896) [Link] (13 responses)

> I wonder if the issue might not be that existing, invested developers see no issue with reading every message on a mailing list while it seems quite overwhelming to a newcomer, even one comfortable with email.

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.

Emacs discusses web-based development workflows

Posted Sep 6, 2021 22:05 UTC (Mon) by pizza (subscriber, #46) [Link] (12 responses)

> 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 [...]

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.

Emacs discusses web-based development workflows

Posted Sep 7, 2021 14:42 UTC (Tue) by marcH (subscriber, #57642) [Link] (11 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.

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.

Emacs discusses web-based development workflows

Posted Sep 7, 2021 16:20 UTC (Tue) by pizza (subscriber, #46) [Link] (10 responses)

> 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).

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.

Emacs discusses web-based development workflows

Posted Sep 7, 2021 16:41 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

> 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.

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.

Emacs discusses web-based development workflows

Posted Sep 7, 2021 16:43 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Email is fine and all. I understand; I use email as my central clearing house for things going on in the projects I use too. However, the problems with patches-over-email is felt, by me at least, on both the maintainer and contributor sides.

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.

Emacs discusses web-based development workflows

Posted Sep 7, 2021 17:00 UTC (Tue) by marcH (subscriber, #57642) [Link] (7 responses)

> Granted, increasingly those services just send an email that just says little more than "something happened

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.

Emacs discusses web-based development workflows

Posted Sep 7, 2021 18:13 UTC (Tue) by pizza (subscriber, #46) [Link] (6 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.

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.

Emacs discusses web-based development workflows

Posted Sep 7, 2021 19:22 UTC (Tue) by marcH (subscriber, #57642) [Link] (5 responses)

> 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.

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

Emacs discusses web-based development workflows

Posted Sep 7, 2021 19:52 UTC (Tue) by pizza (subscriber, #46) [Link] (4 responses)

> I'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

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.

Emacs discusses web-based development workflows

Posted Sep 8, 2021 0:48 UTC (Wed) by marcH (subscriber, #57642) [Link] (3 responses)

> Pretending something doesn't exist doesn't make it go away.

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!!!!"

Emacs discusses web-based development workflows

Posted Sep 8, 2021 2:15 UTC (Wed) by pizza (subscriber, #46) [Link] (2 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.

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.

Emacs discusses web-based development workflows

Posted Sep 8, 2021 6:38 UTC (Wed) by marcH (subscriber, #57642) [Link] (1 responses)

> 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,

The problem with pure email "workflows" is the notification is the data and the data is the notification.

Emacs discusses web-based development workflows

Posted Sep 8, 2021 11:42 UTC (Wed) by pizza (subscriber, #46) [Link]

> > 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,

> 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.

Emacs discusses web-based development workflows

Posted Sep 9, 2021 18:19 UTC (Thu) by debacle (subscriber, #7114) [Link] (7 responses)

> Often, all the discussions, notifications, comments etc are actually consumed via a mobile 'app'.

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?

Emacs discusses web-based development workflows

Posted Sep 10, 2021 0:10 UTC (Fri) by pabs (subscriber, #43278) [Link] (3 responses)

To start with mobile is the main platform for computing these days, many people don't have access to anything else and some have experienced nothing else.

Emacs discusses web-based development workflows

Posted Sep 10, 2021 0:37 UTC (Fri) by debacle (subscriber, #7114) [Link] (2 responses)

Sure, but we are talking about software development here. I just cannot imagine a mobile phone as software development platform, or that somebody who uses only a mobile phone would participate in the development of Emacs.

Emacs discusses web-based development workflows

Posted Sep 10, 2021 0:52 UTC (Fri) by pabs (subscriber, #43278) [Link] (1 responses)

There are people who have written books on mobile phones (ISTR one even on a "feature phone", but can't find a reference), so software development on one doesn't seem surprising to me, especially with an external keyboard. I remember using the command-line on the OpenMoko, software development during idle moments while travelling doesn't seem unlikely. I've read blog posts about people doing software development on tablets with external keyboards. I note there is an iPhone port of Emacs already, so someone somewhere has probably done software development on an iPhone.

https://www.bbc.com/news/world-australia-47072023
http://gamma-level.com/iphoneos/ports/emacs

Emacs discusses web-based development workflows

Posted Sep 10, 2021 1:55 UTC (Fri) by debacle (subscriber, #7114) [Link]

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

Posted Sep 14, 2021 13:33 UTC (Tue) by jezuch (subscriber, #52988) [Link] (1 responses)

I personally have long ago stopped boggling about things that people do that I consider impossible or insane. Development on a mobile phone? Sure, I'm confident that for Kids These Days this is perfectly normal. It's fine. I already know I'm old :)

Emacs discusses web-based development workflows

Posted Sep 15, 2021 12:47 UTC (Wed) by nix (subscriber, #2304) [Link]

Development *in Emacs* on a mobile phone. Been there, done that -- it wasn't very pleasant, but it was doable.

Emacs discusses web-based development workflows

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.

Email-based workflow does not seems to be much in demand nowadays

Posted Sep 13, 2021 8:41 UTC (Mon) by grothesque (guest, #130832) [Link] (6 responses)

Gitlab is used for several projects that I am involved in, and while I do not insist on doing everything by mail, it would be nice to be able to follow discussions a bit like on a mailing list.

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:
https://gitlab.com/gitlab-org/gitlab/-/issues/28974

Email-based workflow does not seems to be much in demand nowadays

Posted Sep 14, 2021 5:12 UTC (Tue) by pabs (subscriber, #43278) [Link] (5 responses)

For me GitLab's email integration is fairly good, you can even file issues (and ISTR patches) via email. The messages have correct subjects, Reply-To, correct threading and various GitLab metadata in X-GitLab-* headers. The main difference to a mailing list that I can see is the author's email isn't used in From, but that could be due to DKIM/DMARC/etc or people's mails not being public.

Email-based workflow does not seems to be much in demand nowadays

Posted Sep 14, 2021 10:31 UTC (Tue) by grothesque (guest, #130832) [Link] (4 responses)

Indeed, since the above issue has been opened, the threading of discussions has been corrected!

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).

Email-based workflow does not seems to be much in demand nowadays

Posted Sep 14, 2021 11:38 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (2 responses)

Alas, we are now stuck with braindead email clients that ignore In-Reply-To and instead try to do "smart threading" purely based on the email subject. While I have little sympathy for such laziness (though it seems way harder to me, but whatever), GMail and Outlook are, unfortunately, quite common.

Granted, there may be ways to make these clients behave sensibly, but it's not the default AFAIK.

Email-based workflow does not seems to be much in demand nowadays

Posted Sep 14, 2021 22:07 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

And I miss Turnpike which, while it DID thread on in-reply-to, it also allowed the user to "break thread" so if somebody (as they often do on mailing lists) clicked "reply" then wiped everything and started a new topic, I could tell it to break on that email and make a new thread.

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,
Wol

Email-based workflow does not seems to be much in demand nowadays

Posted Sep 15, 2021 17:05 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> And I miss Turnpike which, while it DID thread on in-reply-to, it also allowed the user to "break thread" so if somebody (as they often do on mailing lists) clicked "reply" then wiped everything and started a new topic, I could tell it to break on that email and make a new thread.

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).

Email-based workflow does not seems to be much in demand nowadays

Posted Sep 14, 2021 11:56 UTC (Tue) by pabs (subscriber, #43278) [Link]

I see correct threading as far back as May 2020, when was the issue closed?


Copyright © 2021, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds