6 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. Dec 2020
    1. 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
  3. Nov 2020
  4. Jul 2020
  5. Apr 2020
    1. In particular, I, quite accidentally, became a maintainer of ActsAsTaggableOn, a Rails tagging engine, after bumping a long-stale, minor, pull-request I had written.
  6. Aug 2019