Gitlab is a company, not FOSS itself. I use both gitlab and github but prefer github by far. And almost all my source is GPL v3.
1 Like
Nonsense. The things that I don’t want to be reliant on others for, mail server or web server, for instance, I host myself.
I also host darcs repos and my own fossil servers. But still find github to very useful in a global, collaborative context.
You should go find other ways of spending your time than attacking people for sharing their work.
3 Likes
I only have a gitlab account because of an old friend asking me to collaborate on a project.
I find gitlab less usable than github. I think gitlab sucks, but, that’s not the point.
The question is can we get https://git.sailfishos.org/groups/mer-core/-/activity created or re-created.
I don’t think this is sufficient but https://docs.github.com/en/github/setting-up-and-managing-your-github-profile/showing-an-overview-of-your-activity-on-your-profile
It would help to see the activity under the ‘profile’ but it’s not the same as the ‘group’ acitivty page at gitlab.What other ‘project’, ‘profile’ or other metaphor setting might get us to the global activity view.
I really like https://api.github.com/orgs/sailfishos/events maybe I should build an app for. that. now.
1 Like
@PureTryOut, I hope you were aware while ranting against Github.com, that the software stack used at Gitlab.com is not Free Software (“Open Source Software”), either!
Hence your antipathy should hit Gitlab.com, too.
Even more so, because in terms of recording and evaluating user interactions the company Gitlab.com has shown repeatedly to act with a worse (one may call it “evil”) mindset than Github.com.
So this is IMO a rather bad suggestion.
And running an own instance of the (feature reduced) Gitlab Free Edition is exactly what Jolla wants get away from.
Understandably so, as that generates quite some maintenance work, which ought to be rather directed into enhancing SailfishOS.
4 Likes
Not a fan of either Microsoft Github or Google Gitlab. There is little point in hosting a VCS yourself though.
Generally, I am concerned about Github being the central, mighty place for software. Apart of e.g. Iran which is cut off (on a different note, I order my favorite coffee via direct email, because it’s not available on the website for Paypal).
For the network effects Github is of course the best place to find contributors. That’s also why Nextcloud ended up there.
You see Microsoft’s EEE strategy in action. Just have a look at Github’s attempt to replace the CLI git utilities with their own flavour.
It’s just sad and disillusioning.
2 Likes
Dear @veskuh,
one issue I see, that the Issues and Merge Requests usually will not be migrated.
Hence it would make sense to either take care open issues and MRs at git.sailfishos.org (some of which are open for long) before migrating these source repos or to also migrate them to Github (which will need some scripts to perform this; AFAIK such scripts do not publicly exist, yet).
For an example, see https://git.sailfishos.org/mer-core/udisks2
P.S.: Before starting the next hosting migration, it IMO does make sense to finish the last one, first: I have not seen any action (but maybe I missed something) towards migrating the content at together.jolla.com (“TJC”) to forum.sailfishos.org (“FSO”), as announced / promised by Jolla multiple times.
Can you please point out the status of that migration.
6 Likes
I don’t think that they can realistically fix all before migration. So, probably issues will have to be reviewed and migrate accordingly. “Spring cleaning” style.
Otherwise, Github/Gitlab seems to rather divisive issue, way more heated than I expected. In the end of the day, it is good to consolidate on single platform and I see benefit in offloading this to some service provider. So, all in all, whatever destination you choose, looking forward to it.
4 Likes
Yes, thanks for pointing this out. This should have been mentioned in my original message. We do not plan to migrate open pull requests and would prefer to handle those before migration as much as possible. This is real issue and something where need to put more effort.
This would need a proper update on the related thread. To put it short: this has been on hold as it was more complicated than originally thought.
11 Likes
@veskuh, seriously a big “thank you” for this statement (although unfortunate)!
It is the first statement WRT this topic from an Jolla employee for almost a year (despite that being asked so many times).
And it was honest and authentic.
Thus please trigger your colleagues (i.e., Jolla’s sailors) to explain the situation a bit better and Jolla’s ideas how to proceed.
Thanks!
5 Likes
(just forwar to the relevant Product Manager)
Can Jolla please clarify which of the following you are planning to migrate (I’d like to know, I’m realistic that you will leave some history behind, but it would be good to know how much exactly)
- Issues, closed
- Issue, open
- tags
- releases
- current active branches
- commits in those branches
- (PRs is clear now and understandable)
I ask because well,… for one Jolla does not have the best track record when it comes to moving data from a deprecated system (forum, wiki, etc) to a new one.
Secondly, in other companies, I have seen a few version control system migrations, those ranged all the way from a super nice migration of all open and closed issues and all active branches and all commits in those branches all the way down to the horrifying only a shallow clone of depth 1 of the main branch being pushed to the new git server, nothing else
Also, please remember that if repo maintainers were to not plan to maintain issues and/or wikis, etc on one or more repos, to switch those off on a per repo base. Primarily so that it’s clear which your single source of truth for bugs for each repo is. Nothing is more frustrating to me than to notice I filed a bug in system A only to be told sorry, wrong bugtracker, please use X to file bugs against this repo.
pcfe
2 Likes
This is not a version control system change. It is still git, so commits and tags will follow, probably most branches too.
I’m guessing the rest will be left behind, and honestly that doesn’t seem so bad to me.
The relevant MRs/PRs can be reopened, and not that i think releases are used, but after a few months historical releases are quite useless. There appears to be a grand total of 21 issues across all projects in mer-core, 17 of which are open. I don’t think they were meant to be used, as there is some sort of internal Bugzilla or similar, and we users are relegated to the forum.
Hi, pcfe.
I own the hands performing the migration. What attah guessed is right.
My plan is to migrate only git repositories themselves, without any custom GitLab/GitHub added functionality. Thus what is going to be migrated are:
- all git branches
- git commits in all git branches
- git tags
As for:
- issues - not migrated. Sorry.
- relases - I don’t think we ever used those.
- PRs - not migrated. Sorry.
The major reason for not migrating the issues and PRs is that these differ between GitLab and GitHub and migrating them will require more effort, while the benefit of that is questionable.
As for PRs, these will be used in GitHub, so anyone who had a change proposal and submitted it as a PR to GitLab is encouraged to recreate the PR in GitHub. I know I could spend a (non-trivial) amount of time migrating the PRs, however, most PRs that I checked were either old-age, incomplete, or otherwise not worth it. I am pretty sure the PRs that are of worth will either be recreated by the people who submitted them originally, or by the team maintaining the repository.
We are planning to keep the current GitLab instance running in read-only mode for some time after the GitHub repositories are taken into use to allow interested parties to move anything from a current PR to the new repositories.
As for the bugtracker, I am sorry about the situation, but I am unable to do anything about it. The Jolla employees are using an internal bugtracker, and any issue/bug/PR reported elsewhere needs to be mapped to an internal bug anyway, thus it does not matter much if the bug is reported in any Bugzilla, GitLab or GitHub issues, on the Forum, on IRC, or a community beer event. The internal bugs created will not disappear, and will hopefully be resolved by the team.
I will check with the teams to see if they are planning to use the issues or wikis in GitHub, and will lock them otherwise. Thank you for the note about that.
7 Likes
We’ve made progress in migrating. We are soon ready to move to take github into use and then make projects at git.sailfishos.org read-only
We have tried to be active in reviewing, commenting and merging open pull requests for the past weeks. However, we can’t get the queue completely empty as there are always new ones incoming, and for many MRs review cycle takes long time. To get forward we need to set a timeline for the transition even though there are going to be open MRs. After the transition merge requests are no longer handled in git.sailfishos.org, but instead we encourage contributors open new ones in GitHub.
We target to take GitHub in use and make git.sailfishos.org projects read-only during the week starting 14.6. We will continue to review, comment and merge contributions at git.sailfishos.org until then.
Big thank you for the contributors for the patience and working with us to make this change and to make the software better.
BR,
Vesku
8 Likes
Does anyone know how do you list opened MRs for the SailfishOS organisation in Github ?
I was always under the impression it’s a pull request that the owner of the repo then moves to merge but there is no ‘merge request’ per se. I couldn’t find such a thing in the docs. But maybe your referring to something like Rebase and merge your pull request commits
Thanks Guys! I’m happy, but I know not everyone will be ;<
Ok, sorry wrong wording in the context of Github. I’m looking for a place that lists all opened PRs for a given organisation, here SailfishOS. That is a convenient way to baby-sit opened PRs, see what is still pending and need attention.
When you work with the full software stack, you end up with multiple PRs opened in many projects. For instance, to deal with calendar entries, it happens that I have PRs in kf5-calendarcore, mKCal, nemo-qml-plugin-calendar and buteo-sync-plugin-caldav at the same time. Having the possibility to list my opened PRs makes it easier to see how things are evolving.
But more generaly, that’s interesting also to see PRs opened by others. You can learn about new pieces of the code, or comment there if it happens that this is related to something you know or work on, but you’re not actively watching the repo. One example : the latest PR by @mal in cmake repo. I’m not watching this repo and I don’t plan to, but it happened that he submitted a PR that actually solve a problem we faced with @PureTryOut in the mkcal repository. I know this because I’ve seen it in the activity list in Gitlab before the migration. Now I would have missed it.
Would this help
https://github.com/pulls?q=is%3Aopen+is%3Apr+user%3Asailfishos
(Note, you need to be logged in on github to access that page)
7 Likes
Great, thanks. That is indeed what I was looking for. It will be helpful.
I just want to notice that actually both Github and gitlab’s Python ABI are pretty straightforward, basic issue transfer actually isn’t hard. It’s you decision where to spend your time, but even besides reimplementing this I highly doubt there is no foss tool for Gitlab to GH migration and counterwise.
About the benefecial part: Important things will get a new issue and MR/PR, that’s probably true. But what will eventually get lost is important side-info from Issues and MR, resulting in Bugfixes and Improvements introducing new bugs.
Just my 2 cents, fine with as it is.
Most of the bugs were reported into the jolla bug tracker. Gitlab was never used for issues, apart from some exceptions. But even then, most of that had a jolla bug tracker mirror, afaik. So at least according to the policy, there should have been nothing of value in the issues. Not sure, what the reality is though. 