Emacs discusses web-based development workflows

Posted Sep 3, 2021 10:39 UTC (Fri) by pizza (subscriber, #46)
In reply to: Emacs discusses web-based development workflows by pabs
Parent article: Emacs discusses web-based development workflows

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