It's a fork of Memery gem. Original Memery uses prepend Module.new with memoized methods, not touching original ones. This approach has advantages, but also has problems, see discussion here: tycooon#1

(I grant that many of us contribute code to Gitlab, and would also like to participate as members of the development team in guiding the implementations, but clearly the core team has to have the final say in what direction that takes... unless someone wants to create and maintain their own fork of Gitlab ;) )

Such schemas cannot easily be refactored without removing the benefits of sharing. Refactoring would require forking a local copy, which for schemas intended to be treated as an opaque validation interface with internal details that may change, eliminates the benefit of referencing a separately maintained schema in the first place.

consider a situation where the branches of the oneOf are separate schemas owned by other entities (and therefore impossible to refactor without forking), which are intended to provide an opaque validation interface (and therefore may change internal details without warning, but without changing the desired validation outcome) and are included by $ref

Configuration style is exactly the same for env_bang and env_setting, only that there's no "ENV!" method... just the normal class: EnvSetting that is called and configured.

markdown-it is the result of the decision of the authors who contributed to 99% of the Remarkable code to move to a project with the same authorship but new leadership (Vitaly and Alex). It's not a fork.

Considering Canonical has pulled resources from this project, the path for continued third-party development of Unity will not be easy. It is my hope that they are successful and can become another shining example of the power of forking, like the MATE project.

This is open-source. You can always fork and maintain that fork yourself if you feel that's warranted. That's how this project started in the first place, so I know the feeling.

I’m not a dev either, so no Ubuntu fork, but I will perhaps be forced to look at Debian testing, without some advantages of Ubuntu - but now that Unity is gone (and I deeply regret it), gap would not be so huge anymore…

If folks want to get together and create a snap-free remix, you are welcome to do so. Ubuntu thrives on such contribution and leadership by community members. Do be aware that you will be retreading territory that Ubuntu developers trod in 2010-14, and that you will encounter some of the same issues that led them to embrace snap-based solutions. Perhaps your solutions will be different. .debs are not perfect, snaps are not perfect. Each have advantages and disadvantages. Ubuntu tries to use the strengths of both.

You can afford to make a proper PR to upstream.

The change would be useful to other people as-is.

The change is too consequential to be developed in situ.

Patches can be reviewed as part of your normal review process, forks probably can't

Get told in big red letters when the dependency changed and you need to check that your fix is still valid.

Keep your patches colocated with the code that depends on them.

Sometimes forks need extra build steps, e.g. with react-native for Android. Forget that noise.

No more waiting around for pull requests to be merged and published. No more forking repos just to fix that one tiny thing preventing your app from working.

All projects here are completely frozen, though feel free to fork and continue using them on your own.

You can also see this repo: default-passive-events.

@monkeythedev I am curious how do you "organize" your work - You forked https://github.com/hperrin/svelte-material-ui and https://github.com/hperrin/svelte-material-ui is not very active. Do you plan an independent project ? I hope the original author would return at some times, if not, i'll see

Don't think so; template strings solve the problem JSX tries to tackle without forking the language.

Over time Adam, Surplus' creator, had less and less time to spend on the project and I decided to take my own shot.

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.

There's no way to change style incapsulation method without patching the compiler, and this means maintaing a fork, which is not desirable.

In many ways Figma’s Communities are a reflection of Github’s philosophy and intent, but built with design in mind. Duplicate a shared design, and a copy is instantly saved to your workspace and ready to be edited.

I wish you would have contributed back to this project instead of forking or at picked a different name

Forking is the only way to contribute to the project, since I don't have commit access... That's why I posted here, to contribute. I picked the name "Page Translator Revised" since AMO has policies about duplicate add-on names, if you have a better name I'd be happy to use it.

Remove upper bound in our dependencies Doing this we are only asking people to fork our gem or open issues when they want to use a new version of the dependency and we still didn't tested with it.

Piwik PRO uses a fork of Piwik open-source software (similarly to RedHat using the Linux kernel and multiple open source tools), however we currently seamlessly integrate a part of open source Piwik in our proprietary platform via APIs. Moreover, Piwik PRO controls all the changes to the code used in its Analytics Suite and since 2016 has been maintaining and developing its own fork of “Piwik” alongside the proprietary modules of Analytics Suite.

the main reason we built a new multiprocess architecture is that Chromium's multiprocess support was never contributed to the WebKit project. It has always lived in the separate Chromium tree, making it pretty hard to use for non-Chrome purposes.Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute their multiprocess support back to WebKit, so that we could build on it. They said no.

With now more than 3000 modules, there are huge gaps in the quality of things you find in the npm registry. But more often than not, it's easy to find a module that is really close to what you need, except if it wasn't for that one bug or missing feature.

No more waiting around for pull requests to be merged and published. No more forking repos just to fix that one tiny thing preventing your app from working.

The problem occurs when the maintainer of the package is too busy to merge my PR, so I'm just stuck with my fork.

I often find myself in the situation where an npm package does exactly what I need, but has a bug or missing feature that blocks me from using it directly. So I fork it and make a pull request with what I need.