Shaarli: Remove fork dependency since original is no longer maintained

Created on 4 Jan 2017  路  8Comments  路  Source: shaarli/Shaarli

Hello, did you consider to contact GitHub support to ask for independency from parent repo?
It's strange to see how this fork has diverged from sebsauvage's.

(Good for mosaic work too: https://help.github.com/articles/why-are-my-contributions-not-showing-up-on-my-profile/)

feedback needed project-related question

Most helpful comment

Keeping upstream information does no harm in Shaarli's case:

  • it's pretty obvious from Git information that development on the original repository has been stale for a while
  • in case a user first stumbles upon https://github.com/sebsauvage/Shaarli, the community fork is the first to appear in the https://github.com/sebsauvage/Shaarli/network graph
  • the original repository and wiki point to this community-driven fork, so there is no ambiguity either regarding which project is active
  • I like to think of the community fork as a continuation of @sebsauvage's work on Shaarli :)

IMHO, it would only be worth removing the fork information in the following situations:

  • code divergence leading to an impossibility to upstream/rebase changes
  • community or project management conflicts

All 8 comments

What would be the benefits of doing so?

is not strange.. the author of the first version of the app is no longer available to code

@nodiscc
benefits for project readability, this fork is way more advanced than its parent, so the GitHub "fork state" is become useless and misleading.
Benefits for contributors and there mosaic, according to previous link.

@nicolasdanelon
i didn't mean to refute sebsauvage's paternity, but it's not necessary to keep this fork state, a credits paragraph is fine.

I agree that this repo no longer needs to be referenced as a fork, since it has became the reference, and the changes aren't going to be merged upstream. OK for me.

Keeping upstream information does no harm in Shaarli's case:

  • it's pretty obvious from Git information that development on the original repository has been stale for a while
  • in case a user first stumbles upon https://github.com/sebsauvage/Shaarli, the community fork is the first to appear in the https://github.com/sebsauvage/Shaarli/network graph
  • the original repository and wiki point to this community-driven fork, so there is no ambiguity either regarding which project is active
  • I like to think of the community fork as a continuation of @sebsauvage's work on Shaarli :)

IMHO, it would only be worth removing the fork information in the following situations:

  • code divergence leading to an impossibility to upstream/rebase changes
  • community or project management conflicts

I currently don't see good reasosn to ask for removal of the GH _fork_ status:

  • It allows us to stay part of the Shaarli forks network (provides valuable information on current project developments)
  • Previously, _searching_ in forked repositories did not work on github, now it does: https://github.com/shaarli/Shaarli/search?q=test
  • The github mosaic not updating when committing on a fork is a bit strange, @kstefanini have you asked them why it is the way it is? Bug? Feature? Limitation?
  • The community fork _is_ a fork, and a continuation of @sebsauvage's work on Shaarli

Alright, pertinent arguments! Let's close this.

The github mosaic not updating when committing on a fork is a bit strange

Not really, I think it's to differentiate local and ongoing work in forks and PR/commits in upstream repos (which are supposed to be the "official" repositories).

FYI it seems like Github has changed its policy, Shaarli repo's activity is now showing up in my profile.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

electricflock picture electricflock  路  10Comments

phil-dyer picture phil-dyer  路  10Comments

nicolasdanelon picture nicolasdanelon  路  7Comments

llune picture llune  路  7Comments

lolop-lj picture lolop-lj  路  7Comments