39 Matching Annotations
  1. Jan 2024
    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 ;) )
  2. Sep 2022
    1. 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.
    2. 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
  3. Jun 2021
    1. 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.
  4. Mar 2021
  5. Feb 2021
    1. 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.
  6. Jan 2021
    1. 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.
    1. 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…
    2. 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.
  7. Dec 2020
    1. You can afford to make a proper PR to upstream.
    2. The change would be useful to other people as-is.
    3. The change is too consequential to be developed in situ.
    4. Patches can be reviewed as part of your normal review process, forks probably can't
    5. Get told in big red letters when the dependency changed and you need to check that your fix is still valid.
    6. Keep your patches colocated with the code that depends on them.
    7. Sometimes forks need extra build steps, e.g. with react-native for Android. Forget that noise.
    8. 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.

      This could be both good and bad.

      potential downside: If people only fix things locally, then they may be less inclined/likely to actually/also submit a merge request, and therefore it may be less likely that this actually (ever) gets fixed upstream. Which is kind of ironic, considering the stated goal "No more waiting around for pull requests to be merged and published." But if this obviates the need to create a pull request (does it), then this could backfire / work against that goal.

      Requiring someone to fork a repo and push up a fix commit -- although a little extra work compared to just fixing locally -- is actually a good thing overall, for the community/ecosystem.

      Ah, good, I see they touched on some of these points in the sections:

      • Benefits of patching over forking
      • When to fork instead
  8. Nov 2020
  9. Oct 2020
  10. Sep 2020
    1. 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.
    1. 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.

      The idea of a click-to-fork-repository was brought to Figma in the form of communities.

  11. May 2020
    1. I wish you would have contributed back to this project instead of forking or at picked a different name
    2. 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.
  12. Apr 2020
  13. Mar 2020
    1. 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.
  14. Nov 2019
    1. 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.
  15. Aug 2019
    1. 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.
    1. The problem occurs when the maintainer of the package is too busy to merge my PR, so I'm just stuck with my fork.
    2. 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.