Friendica: Use Gitlab instead of Github, or use both(?)

[snd1]

Imho Gitlab is better than github, especially because the GitLab Community Edition (CE) is licensed as MIT, a freesoftware license. Github doesn't have such as, means it is closed source.

Well this is not the only argument, read more: https://about.gitlab.com/better-than-github/

[fabrixxm]

Why not gitweb? or cgit? :-)

[annando]

Thing is: I would like to have full administrative access for the current "core developers". This we don't have.

[fabrixxm]

As redmatrix repo moved under new user ("redmatrix"), we could think to create an organization to keep friendica repos, instead under Mike's user "friendica".
That way is more easy to manage permissions, without involve Mike every time.

As per github/gitlab/whatever... Every solution could work. From a pure ideological point of view, anything else can be better than github, but I think this give us, (atm, could change in future) the lowest entry step for new contributions...

[annando]

So we should ask Mike if he would like to change the account "friendica" to an organization account? Then he could transfer administrative access to some of us.

[MrPetovan]

Is this still current? @friendica, did you change the type of your account? @zotlabs maybe?

[ghost]

I tried an organisation account several years ago (2011?) with a different account and there were problems which made it unworkable. I don't recall at the moment what the problems were. I've been hesitant to try it with a "production" account.

I should probably just give somebody on the Friendica project the login details and let you sort it out.

[MrPetovan]

I suggest you send them to @annando, he seems to be the one in charge at the moment.

[annando]

I would suggest @tobiasd :-)

[tobiasd]

one in charge

o.O? ;-)

I would think there are at least 4 in charge, which is a good thing, but I can take that hat and manage the account.

[annando]

I would prefer that you are doing this - but we should find a way to store the credentials somewhere where some more persons could have access to it as well. Saying this I think I should find a way to do the same with the domain administration credentials for friendi.ca as well :-)

[MrPetovan]

Following up: @zotlabs did you send the credentials to @tobiasd ?

[annando]

BTW: Concerning the credentials for the domain administration for friendi.ca and friendica.social my DNS provider promised me a solution for the next week. Then I will be able to create additional accounts that could work with these two domains but not with my personal ones.

[MrPetovan]

A year later, have the @friendica account credentials been passed on from @zotlabs to anyone active here?

[tobiasd]

A year later, have the friendica account credentials been passed on
from @zotlabs to anyone active here?

Yes. Otherwise you wont have write permissions to the repo ;-)

[MrPetovan]

So, can we actually start fresh and remove this absurd dependency to duthied/Free-Friendika?

[tobiasd]

So, can we actually start fresh and remove this absurd dependency to
duthied/Free-Friendika?

There is no dependency on that repository. It's a bug of github.

[MrPetovan]

I know the only way to get rid of it is to delete the repo and add it again in GitHub, but I thought it wasn't possible because we didn't have the @friendica credentials.

[tobiasd]

I know the only way to get rid of it is to delete the repo and add it
again in GitHub, but I thought it wasn't possible because we didn't
have the @friendica credentials.

I remember I tried last year on a test repo/account. Something went wrong (I don't remember what) and then the shit hit the fan and I almost lost two dear people so I stopped trying the unimportant thing of converting the repo. Recovery is a slow process but maybe I'll try again.

[ghost]

If you delete and re-create the repo on github, the "Forked from" link to the other repository will very likely return when it is re-created unless you destroy the git history and start/init it as a new project. This would destroy the early history of Mistpark (which the Friendica community does not own or control), but I'm certain most if not all the current devs would be glad to burn those bridges and completely sever any and all historical connections with me personally.

Go for it. I've got backups.

[tobiasd]

(which the Friendica community does not own or control), but I'm
certain most if not all the current devs would be glad to burn those
bridges and completely sever any and all historical connections with
me personally.

I think this is a wrong assumption. It is part of the projects history and I don't see any reason to cut it out!

[MrPetovan]

I'm certain most if not all the current devs would be glad to burn those bridges and completely sever any and all historical connections with me personally.

If it's true, then why would you waste your time here? If not, why would you write it?

[annando]

@zotlabs I don't think that the current devs want to "burn bridges". I guess we are now going in directions that weren't intended at the start. But that shouldn't be a problem, since that's just the way it goes.

AFAIK the repository currently is a personal account and not a project account (or however this is called). This is something I really would like to change - just for the cleanliness. But I wouldn't like to lose the history.

[MrPetovan]

The repository itself holds its own history, the fork of part is specific to GitHub. If I understand correctly, you can keep the repo locally while you delete it on GitHub and then resubmit it entirely.

The drawback is that it would disconnect all the current forks and lose all the stars, issues and PRs that are specific to GitHub as well.

[annando]

Isn't there some easier way to convert this repository to a regular project?

[MrPetovan]

I didn't research this, only how to sever the obsolete parent link with duthied/Free-Friendika. I'm not even sure what you mean, but in the case you're talking about Project Board, this is what I quickly found in the GitHub help: https://help.github.com/articles/creating-a-project-board/

[ghost]

The reason the project was parented to the duthied repository is precisely because the repo was deleted and re-created to change the name from friendika to friendica. When it was re-created, github's software searched for something with the same early commit history in its database and Devon's fork is the first one it found. If it is deleted and re-created again, it is highly likely that unless this github code has changed - nothing will be gained as the same logic will be followed once again.

If you want to ensure that it doesn't happen again you either need to delete some or all of the history, fork to a new location (but retain the current repo forever so it will be listed as the parent), or move the project to another git base like gitlab that doesn't have this bug. Alternatively you might be able to open a ticket and get the github folks to clear that pointer and maybe fix the bug. It never really bothered me other than the fact that the logic used was curious.

I'm granting permission to delete any of the history that predates (and where there are copyrights and trademarks which do not belong to) the Friendica project, if that path is chosen.

[MrPetovan]

Thank you for your permission. Since you already tried it and it didn't go as planned, I don't think we should move forward with this move. I thought it was relatively easy and only blocked by the lack of credentials, but it appears we would lose more than just the GitHub-related information, and while it would be nice to have a clean slate, I'd still prefer to keep the code history.

[annando]

We could however ask the github guys.

[MrPetovan]

As a project admin, do you have a specific support channel?

[annando]

Don't know.

[tobiasd]

As a project admin, do you have a specific support channel?

In the early phase of snarl.de we created an organisation for it. The settings are almost the same, but you can assign default values for members of the organisation. But as far as I see there is no special support channel.

[MrPetovan]

What else do we need to move forward with the move? (cf https://friendica.mrpetovan.com/display/735a2029735b119a589accd577980993)

[tobiasd]

We just need to finish the mail setup.

[MrPetovan]

Public announcement: There's a mirror of this repo hosted on Gitea at https://git.friendi.ca

[MrPetovan]

There are additional mirrors of Friendica repositories:

• https://zen.uber.space/team-friendica (thanks to Olivier [email protected])
• https://git.hubup.pro/friendica (thanks to @AndyHee [email protected])
• https://git.jb-net.us/explore/repos (thanks to JB Carrol [email protected])
• https://gitea.libranet.de/friendica (thanks to @AlfredSK [email protected])

[hoergen]

Will there be a big announcement when we switch over to git.friendi.ca?

There is a typo in https://git.friendi.ca/ ... the green "Friendica" link https://fridni.ca/
or .. hope you have a veeery good explanation who this fridni.ca is! ;))

[MrPetovan]

Yes, we’ll need to update the documentation as well.

[tobiasd]

No, there will be no announcement... maybe a small hint ;-)

The explanation is a typo. Thanks for noticing it!

[fabrixxm]

[AlfredSK]

Before we move the repo to another service we should also think about the features of the alternative service. When I compare the feature list of Gitea and Github I see some differences. And I think some of the lacking features are a serious issue:
No Pull/Merge request approval
No Merge conflict resolution
No Revert specific commits or a merge request
No Related issues
No Cherry-picking changes
See: https://docs.gitea.io/en-us/comparison/

But you as developers know better what you need. I was just wondering if Gitea is really sufficient for our workflow.

[fabrixxm]

No Merge conflict resolution
No Revert specific commits or a merge request

this are thing you do in git, nothing a web interface should do, imho.

No Related issues

Is this link to other issues or some other functionality?

No Cherry-picking changes

I think, but I could be wrong, nobody here ever merged cherry-picking.
And again, it's something you can do with git anyway.

No Pull/Merge request approval

This could be an inconvenience, as it's working well...

[MrPetovan]

I don't think any of those items are serious limitations. Most of what GitHub those is make things nicer or more convenient, but these improvements aren’t required in the workflow:

• No Pull/Merge request approval: Can be replaced by explicit comments ("I approve this PR")
• No Merge conflict resolution: Can be done from the requester's end.
• No Revert specific commits or a merge request: Can be done from the command-line, although it was really convenient.
• No Related issues: Can be replaced by explicit links in both issues/PR pages
• No Cherry-picking changes: Unused so far in Friendica

On the other hand, the thing we'll really miss is the built-in CI integration as we started to add meaningful tests (thanks to @Rudloff) to the API. This would require a personal test setup on the contributor's end, and it will be a pain to require it from everyone as we hopefully extend the tests.

Also, I'm not sure how to create a cross-repo pull request yet, I forked the friendica repo in Gitea and tried to create a pull request from my forked repo to the main repo but I couldn't select the friendica/master branch. It may be because the repo is a GitHub mirror at the moment though.

[Rudloff]

A test CI tool would be really useful here because our tests are really slow so it's a pain to run them locally.
One solution would be to host a Jenkins or Drone instance.

[tobiasd]

Also, I'm not sure how to create a cross-repo pull request yet

I've just created a PR. So I'll try to write down the steps to reproduce it. Start from your fork and switch to the feature branch. Next to the pull-down list of the branches, there is a green button at the left side, hit that and you end in the compare dialog at the original repository. Then you can edit the information and hit the create PR button. Trying it again resulted in the hint, that there is already a PR for this changeset.

It looks like, PRs are not possible while the repository is a mirror. My test was with the customization repository adding the 1st files for the FI translation.

[MrPetovan]

Thanks, that's what I expected.

[AndyHee]

It's going to be great! Exciting times moving to a project hosted gitea repository.

One point that has not been covered yet is how to deal with open (and closed) issues on github. Is there a possible way to import them into gitea?

[tobiasd]

I'm working on that issue...

[AlfredSK]

The Hubzilla folks have moved to Gitlab and already archived their Github repos.

[tobiasd]

Congrats ;-)

[AndyHee]

The Hubzilla folks have moved to Gitlab and already archived their Github repos.

Hosted by Framasoft on framagit.org.

[AlfredSK]

@MrPetovan You may add this mirror too:
https://gitea.libranet.de/friendica
:confetti_ball: