Integrate exiv2 into the KDE or GNOME ecosystem?

[D4N]

In #1018 (comment) @ognarb suggested to integrate exiv2 into the KDE ecosystem. This would give us access to KDE's resources and potentially additional contributors. @phako suggested the same, but for freedesktop.org.

We should list potential pros and cons here and carefully evaluate the options. Also, what is the opinion of our API consumers?

[piponazo]

Definitely, I would go for one of these options. I took a look to the "Inkubator" process and everything seems pretty clear and I do not think we would have any problem meeting the requirements.

[D4N]

The only downside that I currently see is that we'd probably have to move away from GitHub and thus loose all of the infrastructure & exposure that we get from github.

[cgilles]

For the question about a plan to use a modern C++ framework in Exiv2 in case of migrating in a lead open source ecosystem, i vote for no. The code base work well, no need to pass time to re-write code and introduce bug. This is true for KDE with Qt or Gnome with GTK+.

[cgilles]

KDE infrastructure is based now to Gitlab. I will not to explain why this choice was done instead Github, you will found the information on the web history. Look here for details:

https://gitlab.com/gitlab-org/gitlab-foss/issues/53206

And if i'm not too wrong Gnome project do the same...
You must know that KDE has a mirror function with Github (read only).

With digiKam, following the KDE migration, we starting to use Gitlab infrastructure step by step since 2 months, and it's rock.

Gilles Caulier

[D4N]

For the question about a plan to use a modern C++ framework in Exiv2 in case of migrating in a lead open source ecosystem, i vote for no. The code base work well, no need to pass time to re-write code and introduce bug. This is true for KDE with Qt or Gnome with GTK+.

Agreed on this one, I would only go for an integration into KDE or Gnome if we can keep Qt and GTK/GLIB out of the code base (as both depend on us, we'd alienate the other, which I wouldn't want).

KDE infrastructure is based now to Gitlab. I will not to explain why this choice was done instead Github, you will found the information on the web history. Look here for details:

https://gitlab.com/gitlab-org/gitlab-foss/issues/53206

No need to explain that, imho it's a shame that a big chunk of the open source ecosystem lives on a proprietary platform.

And if i'm not too wrong Gnome project do the same...

Indeed: https://gitlab.gnome.org

You must know that KDE has a mirror function with Github (read only).

Can you use that to submit pull requests?

With digiKam, following the KDE migration, we starting to use Gitlab infrastructure step by step since 2 months, and it's rock.

Yes, GitLab CI is freaking awesome, although I must admit that GitHub actions are a very close contender too.

[piponazo]

@D4N yeah, I thought about that being something in which we would need to invest some time to adapt to other CI infrastructure. On the other hand, I think our CI scripts are pretty mature and probably it would not be much work.

In terms of Github hosting ... as far as we keep using a modern CVS (Git or Mercurial) I do not see it a drama. Although it is true, that platforms like Github or Bitbucket are the entry point for a big percentage of developers.

For me, the most interesting point about joining an ecosystem like KDE or Gnome, it is not about the technicalities but rather about the community. Probably we would get people contributing to Exiv2 from other projects using Exiv2 in their internals.

@cgilles I think I missed that point in the recent discussions about that "plan to use a modern C++ framework in Exiv2 in case of migrating in a lead open source ecosystem". I think you were involved in the discussions we had months ago about this, and basically we decided to make more obvious that Exiv2 0.27 would keep using C++98 and in master (Exiv2 0.28) we made the switch to c++11.

Since Exiv2 is actually used in quite some other projects, I think that we should not change that and stick to that version of the standard. There are many interesting things we could use from c++17, but honestly the biggest change was from c++03 to c++11.

[cgilles]

You must know that KDE has a mirror function with Github (read only).

Can you use that to submit pull requests?

I think no. In krita project for example which is the first major KDE family project to be migrated to gitlab, they set a README about this topic:

https://github.com/KDE/krita/blob/master/.github/CONTRIBUTING.md

Gilles Caulier

[phako]

Agreed on this one, I would only go for an integration into KDE or Gnome if we can keep Qt and GTK/GLIB out of the code base (as both depend on us, we'd alienate the other, which I wouldn't want).

Subjectively I think you'd profit more from KDE, since your consumers use you directly, and there's more C++ people there. With GNOME, I'm your proxy API, I get most of the tickets.

I mainly suggested fdo as a third option, but that's probably not anything more beneficial than staying on github

[jriddell]

Some of the benefits of joining KDE are listed here
https://manifesto.kde.org/benefits.html
While KDE is best known for its Plasma desktop there are many projects which are part of the community which are very diverse even as far as a textbook wiki https://en.wikitolearn.org/Main_Page
KDE projects get help from infrastructure hosting, CI, automated QA, promotion, translations, can release on their own or have that done by the KDE release service.

[D4N]

So as I currently see it:

• KDE would probably be mutually quite beneficial (we & KDE use cmake + C++ directly), but we loose the Github ecosystem & tooling
• GNOME might be mutually beneficial (faster feedback for gexiv2), but we loose Github too

I'm currently a little worried on the loosing Github part, as we rely on quite a few services that are integrated very well with Github (no idea how they are integrated with GitLab):

• LGTM
• Mergify
• Appveyor
• Codecov
• [planned to be used] GitHub actions

Also, how "independent" could we stay inside the KDE ecosystem, especially with respect to KDE specific adjustments (I don't want to alienate our GNOME users and the remaining dependent packages)?

[jriddell]

LGTM is called merge request approvals in Gitlab.
https://docs.gitlab.com/ee/workflow/gitlab_flow.html maybe be similar to Mergify
"Windows developers use AppVeyor to continuously run their tests and deploy apps to cloud or on-premise environments." We can do this on https://binary-factory.kde.org/

Projects can stay as indepdendent as they like within KDE, if they don't want community help in any aspect then there's no pressure to have it. It can use different download servers, website hosters, whatever if that works best.

[a17r]

You must know that KDE has a mirror function with Github (read only).

Can you use that to submit pull requests?

In Gentoo, we also use GitHub only as a mirror, but many projects still use PRs in their workflow as it is very easy to download and git am from there. We even have perl and shell script packages to do it in one go from your favorite terminal, and that's not specific to our repos. Of course a kde.org gitlab workflow should be adopted should you go there, this is just to say you do not have to lose the existing PRs in here or dismiss the rare GitHub PR even after such a project move.

[clanmills]

This matter is being considered for 2022. #1494.