As of right now the full build takes over an hour to run, and this makes cycling for PRs and quick iterative development very difficult.

This makes ongoing maintenance difficult, as it requires that RSpec Rails' maintainers be conscious of every Rails version that might be loaded.

Our need is therefore best characterised by cost of maintenance. Having to maintain several versions of Rails and Ruby costs us a lot. It makes our development slower, and forces us to write against Rails versions that most people no longer use.

We will also run into some issues when we consider adding new channels to Service Desk like an API. We should have a streamlined process of rendering notes (messages) etc. Having a base64 image (or even attachment) in mail but not in the API might be inconsistent and also adds a lot of code that needs to be maintained.

Also, the chances of breaking something are really high, because not even you remember how the code actually works.

We already have a very wide configuration API. The further we expand it the more unwieldy it becomes for users. At this point we generally require new features to be implemented first as extension gems, and then to see support, before considering including them in core.

we routinely choose not to add or expand features we think are a bad idea, or simply that aren't in popular demand, not because we're "saving the dummies' asses" but because adding new features creates a maintenance burden upon ourselves which cannot easily be undone. Once a version of RSpec supports something its there until a next major version which could be a long time away, we have several features already that we don't recommend extensive use of (expect_any_instance_of for example, we'd recommend not using it but we know there is popular demand for it so we maintain despite the extra burden it causes) so we're understandably not keen to increase that number.

Yes, precisely because I've been involved in maintaining codebases built without real full stack frameworks is why I say what I said.The problem we have in this industry, is that somebody reads these blog posts, and the next day at work they ditch the "legacy rails" and starts rewriting the monolith in sveltekit/nextjs/whatever because that's what he/she has been told is the modern way to do full stack.No need to say those engineers will quit 1 year later after they realize the mess they've created with their lightweight and simple modern framework.I've seen this too many times already.It is not about gatekeeping. It is about engineers being humble and assume it is very likely that their code is very unlikely to be better tested, documented, cohesive and maintained than what you're given in the real full stack frameworks.Of course you can build anything even in assembler if you want. The question is if that's the most useful thing to do with your company's money.

OpenFaaS® makes it easy for developers to deploy event-driven functions and microservices to Kubernetes without repetitive, boiler-plate coding.

I could find the time to maintain it despite being "boring"

Frankly, if the Ubuntu Desktop team “switch” from making a deb of Chromium to making a snap, I doubt they’d switch back. It’s a tremendous amount of work for developer(s) to maintain numerous debs across all supported releases. Maintaining a single snap is just practically and financially more sensible.

This example of the chromium really shows that unless snaps or other similar format was used, applications would have to be sometime very heavily patched to work on older versions of systems to the point that it generates so much work that it would not be worth do to it otherwise, or at least not worth when the snap option exists and doesn’t require that much more work.

Less developer maintenance burden: The existing (Kuma) platform is complex and hard to maintain. Adding new features is very difficult. The update will vastly simplify the platform code — we estimate that we can remove a significant chunk of the existing codebase, meaning easier maintenance and contributions.

Intercepting proxies are commonly used in businesses to enforce acceptable use policy, and to ease administrative overheads since no client browser configuration is required.

Looking at a few isolated examples doesn’t really represent the enormity of the maintenance problem when you modify objects that you shouldn’t. To understand this point of view, it’s helpful to take a step back and look at moral philosophy (aka ethics).

It also aims to support only modern browsers to keep things simple.

I can't add special props and keywords to every single component I have and will ever create for this to work.

Explicitly exposing any attributes that might get overridden by a parent seems impractical to me.

Svelte will not offer a generic way to support style customizing via contextual class overrides (as we'd do it in plain HTML). Instead we'll invent something new that is entirely different. If a child component is provided and does not anticipate some contextual usage scenario (style wise) you'd need to copy it or hack around that via :global hacks.

Explicit interfaces are preferable, even if it places greater demand on library authors to design both their components and their style interfaces with these things in mind.

You can help ensure your RFC is reviewed in a timely manner by putting in the time to think through the various details discussed in the template. It doesn't scale to push the thinking onto a small number of core contributors.

Even as machine-readable data begins to permeate the web, it is typically distributed in a separate file, with a separate format, and very limited correspondence between the human and machine versions.

The content should always be the same. For news articles, specify the “NewsArticle” type. The headline should match your article’s title. The image object refers to the hero image of the article.

If you can, use AMP like any other JavaScript library to build your site and forget about the canonical linking. Using AMP to build a whole website dramatically reduces your maintenance burden.

Not only do changes need to be tested against Ice Cream Sandwich's codebase, it is also often necessary to use workarounds due to API restrictions.

Despite our best efforts to deal with all of those issues, over the course of time we fall behind. When you look at an issue it's sometimes unclear whether or not we intent to provide the functionality you propose, whether or not we fix the bug, whether or not the issue is a duplicate of another one. In order to restore a reasonable level of clarity we annually perform a House Keeping Iteration in which we go through all open issues. We categorize, label, fix, and close issues. This results in a wave of notification which is hard to deal with (our apologies) but in the end there is better understanding of what will happen to your ideas.

Most traditional (monolithic) CMS systems are “coupled”, meaning that the content management application (CMA) and the content delivery application (CDA) come together in a single application, making back-end user tools, content editing and taxonomy, website design, and templates inseparable. Coupled systems are useful for blogs and basic websites as everything can be managed in one place. But this means that the CMS code is tightly connected to any custom code and templates, which means developers have to spend more time on installations, customizations, upgrades, hotfixes, etc. and they cannot easily move their code to another CMS.

But, I was no longer using the gem, the issue activity was overwhelming, and the codebase in serious need of reworking.

Yes, it’s been deprecated. Why? Because too few people were using it to make it worth the time, money, and energy to maintain. In truth, although I sometimes disagree with the operator changes, I happen to agree with this one. Maintaining ALL of the synonyms takes real time and costs us real money. Supporting this operator also increases the complexity of the code base. By dropping support for it we can free up a bunch of resources that can be used for other, more globally powerful changes.

Using versions is a maintenance burden on the preset, and we made this mistake with Neo. By specifying a version, we are forced to track with React when their version changes, possibly falling behind.

I second that and recommend the typings be moved to DefinitelyTyped. It’s an unreasonable burden for a library maintainer to manage them when they aren’t using TypeScript.