8 ms·

This is my thinking as well. Do I bail ship to gitlab and support more open software, or do I try to stay centralized?

Klathmon 8y ago
Personally, I'm not "bailing" from anywhere. I am however using this as an opportunity to rely on any one single place less. I'm in the process of mirroring my git repos on GitLab, and trying to think of a way to signify that both the GitHub and GitLab repos are "canonical", and that issues/PRs/contributions can happen at both.
- VectorLock 8y ago
  Sounds like that would be a pain having that kind of work done in two places.
  - mathgeek 8y ago
    Which is rather unfortunate for something that all revolves around git.
- chrisweekly 8y ago
  I do not think the word "canonical" means what you think it means.
  - Klathmon 8y ago
    > accepted as being accurate and authoritative. > synonyms: recognized, authoritative, authorized, accepted, sanctioned That's what I meant for it to mean anyway...
    - chrisweekly 8y ago
      In software the "authoritative" aspect of the definition is crucial. How can two different endpoints both be authoritative? What happens if they differ?
      - Klathmon 8y ago
        Then people will be confused, which is why I'm exploring options to ensure they stay in-sync.
        chrisweekly 8y ago
        I'd recommend simply designating one as master, one as slave. Why try to appoint two captains of one ship?
        Klathmon 8y ago
        Because having one as master and one as slave is exactly the problem i'm trying to solve here. I want both to be master, so that users who are comfortable on both platforms are willing to make contributions to the codebase, so that any one service/system going down won't stop development, and so that as the "community" migrates around different platforms they can always find the full version of the software. Recommending simplifying a process to the point that it no longer solves the problem it's trying to solve isn't helpful.
        chrisweekly 8y ago
        Sorry if my comments haven't been helpful. But I don't think the problem you're trying to solve is tractable. I'd be very interested to hear of a solution that doesn't rely on locking and is immune to conflicts. You might fake it (and meet your stated goals) by maintaining a true master behind the scenes and syncing to two public slaves... (ie, forks you treat as peers, each with a "master" branch) but that still leaves neither of them truly "canonical" -- a designation of authority that would apply to the place where you'd resolve conflicts given simultaneous commits.
aldanor 8y ago
... and when GitLab inevitably gets acquired by another ${megacorp}?..
- superflyguy 8y ago
  Then I'll change part of the URL I've soft coded from ...hub... to ...lab... to ... bucket...
  - bdcravens 8y ago
    Any reason why you implicitly trust Atlassian?
    - superflyguy 8y ago
      I don't. I use jira at work. It's shit.
    - pathseeker 8y ago
      You missed the point of that comment
    - notheguyouthink 8y ago
      Does s/he implicitly trust Atlassian? If anything, that comment makes it clear to me that they're staying mobile because they don't implicitly or explicitly trust any of the current providers. I think if they implicitly trusted someone, they'd just migrate to them immediately - why wouldn't you?
    - p2t2p 8y ago
      The reason you can trust Atlassian a bit more because they have more narrow focus on dev tools so less chances that they could become a competitor. Unless you’re developing another (git/bit)(hub/lab/bucket)
      - lioeters 8y ago
        Seeing potential in the unused combinations: GitBucket, BitHub, BitLab.

Personally, I'm not "bailing" from anywhere. I am however using this as an opportunity to rely on any one single place less. I'm in the process of mirroring my git repos on GitLab, and trying to think of a way to signify that both the GitHub and GitLab repos are "canonical", and that issues/PRs/contributions can happen at both.

VectorLock 8y ago
Sounds like that would be a pain having that kind of work done in two places.
- mathgeek 8y ago
  Which is rather unfortunate for something that all revolves around git.
chrisweekly 8y ago
I do not think the word "canonical" means what you think it means.
- Klathmon 8y ago
  > accepted as being accurate and authoritative. > synonyms: recognized, authoritative, authorized, accepted, sanctioned That's what I meant for it to mean anyway...
  - chrisweekly 8y ago
    In software the "authoritative" aspect of the definition is crucial. How can two different endpoints both be authoritative? What happens if they differ?
    - Klathmon 8y ago
      Then people will be confused, which is why I'm exploring options to ensure they stay in-sync.
      - chrisweekly 8y ago
        I'd recommend simply designating one as master, one as slave. Why try to appoint two captains of one ship?
        Klathmon 8y ago
        Because having one as master and one as slave is exactly the problem i'm trying to solve here. I want both to be master, so that users who are comfortable on both platforms are willing to make contributions to the codebase, so that any one service/system going down won't stop development, and so that as the "community" migrates around different platforms they can always find the full version of the software. Recommending simplifying a process to the point that it no longer solves the problem it's trying to solve isn't helpful.
        chrisweekly 8y ago
        Sorry if my comments haven't been helpful. But I don't think the problem you're trying to solve is tractable. I'd be very interested to hear of a solution that doesn't rely on locking and is immune to conflicts. You might fake it (and meet your stated goals) by maintaining a true master behind the scenes and syncing to two public slaves... (ie, forks you treat as peers, each with a "master" branch) but that still leaves neither of them truly "canonical" -- a designation of authority that would apply to the place where you'd resolve conflicts given simultaneous commits.

aldanor 8y ago

... and when GitLab inevitably gets acquired by another ${megacorp}?..

superflyguy 8y ago
Then I'll change part of the URL I've soft coded from ...hub... to ...lab... to ... bucket...
- bdcravens 8y ago
  Any reason why you implicitly trust Atlassian?
  - superflyguy 8y ago
    I don't. I use jira at work. It's shit.
  - pathseeker 8y ago
    You missed the point of that comment
  - notheguyouthink 8y ago
    Does s/he implicitly trust Atlassian? If anything, that comment makes it clear to me that they're staying mobile because they don't implicitly or explicitly trust any of the current providers. I think if they implicitly trusted someone, they'd just migrate to them immediately - why wouldn't you?
  - p2t2p 8y ago
    The reason you can trust Atlassian a bit more because they have more narrow focus on dev tools so less chances that they could become a competitor. Unless you’re developing another (git/bit)(hub/lab/bucket)
    - lioeters 8y ago
      Seeing potential in the unused combinations: GitBucket, BitHub, BitLab.