Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Future of Exiv2? #1018

Open
D4N opened this issue Oct 5, 2019 · 24 comments

Comments

@D4N
Copy link
Member

commented Oct 5, 2019

Recently our main contributor Robin (@clanmills) decided to retire from the project effective immediately. We don't have to fool ourselves: Robin has been the driving force behind this project for roughly a decade now and invested a truly insane amount of time and effort into it. No one of the currently active contributors has either the time or the expertise to match him. This leaves us in a tough spot: how can we keep this project alive and going?

Current state

  • me and @piponazo are unfortunately currently rather busy in our offline lives and cannot invest a lot of time into exiv2. I was unable to keep up with all the bug reports & pull requests, which (as expected) resulted in a lot of frustration from the other contributors.
  • no one of the current contributors has the expertise and endurance matching that of @clanmills
  • without @clanmills we are badly understaffed (more than before) to even perform basic maintenance
  • the exiv2 webpage is run by Robin, as is the Jenkins build server which produces the release binaries

Short term steps

I propose the following to steps in the short term (until the end of 2019):

  • Move the project into (hard) maintenance mode: i.e. no new features, just bugfixes.
  • Ensure that we can produce a 0.27.3 release by the end of 2019: create releases on our current CI without Jenkins. A prerequisite for that is that we can build exiv2 in a reproducible fashion (which is possible, openSUSE is already doing that with one patch).
  • Move the exiv2 webpage to github or gitlab pages.
  • Migrate all existing svn repositories that are still out there to git under the Exiv2 org

Long term steps

I see the following options:

  • We find new contributors. Imho unfortunately rather unlikely, as the past showed. We can try to raise awareness about exiv2, but unfortunately I don't really know how to make this project appealing to new contributors.
  • We find a corporate sponsor, who will sponsor at least some development time. Due to the removal of the (imho) legally questionable commercial licenses, our usage of the GPL2+ and our place in a rather non-existent commercial market (Linux Desktop application dependency), we're in a pretty rough spot for this. We might try our luck with one of the big enterprise Linux vendors (RedHat, SUSE, Canonical, etc.), provided that we are in their enterprise support package.
  • We rewrite the whole thing? I know this sounds crazy (and probably is), but imho exiv2 shows its age and developers like to work on the new hot stuff™ and not maintain an old application. So we might attract a few people if we decide to rewrite in a new language using new features, etc. But, this is going to alienate our current API consumers and it will take years before we achieve feature parity (if we even ever manage to do that). So not sure how realistic this is, probably not much.
  • Drastically reduce the scope of Exiv2 to match only what our API consumers require (cc @cgilles @phako)?
  • ???

What can we do to improve our processes?

The past showed that our current contribution process became rather complicated, which already drove away contributors. This is bad.

How can we improve for one time contributors?

  • Offer patch submission via email? (WIP via sr.ht: https://git.sr.ht/~d4n/exiv2)
  • Don't require strict code review from early contributors, but instead fix contributed code ourselves to reach the desired quality standard.

How can we improve the process for long term contributors?

  • Pull requests don't get reviewed and cannot be merged 😞. => We could specify a ~2 week grace period for a review, where the PR author should send a weekly review reminder. If the PR author is a "proven contributor", then they can exercise their right to merge an unreviewed PR, provided that the CI is green.
  • CI is flaky and breaks, only one person can fix it (@D4N for GitLab, @piponazo for Appveyor). If the person is busy, PRs are red and cannot be merged 😞. => We could move the tests to github actions, so that everyone has access to them and can fix the issues.
  • PR reviews are merciless and annoying because a lot of minor stuff gets flagged. I am the culprit in this case. If this is a stop gap for many, then I will stop reviewing PRs in detail and instead amend them to fix issues that I find need fixing (provided I have time).

How can we attract more people to contribute?

  • Your idea here

Any further ideas/comments/suggestions?

@D4N

This comment has been minimized.

@D4N D4N pinned this issue Oct 5, 2019
@cgilles

This comment has been minimized.

Copy link
Collaborator

commented Oct 5, 2019

Hi all,

I'm always listening Exiv2 conversation, even if i'm not very active in the project.

As digiKam use Exiv2 API to handle all metadata excepted video, considerate me as present for some task. one where i'm interested is to support new image format. actually i finalize the HEIC/HEIF support in digiKam. I know that an entry exist to support this format in Exiv2, so i will be ready to check code and test new implementation for a quick move in production.

https://i.imgur.com/JmEgGNS.png
https://i.imgur.com/MlNxPLa.png

I plan also to integrate Webp, Jpegxr, FLIF, support as native loader in digiKam in the future. So All plan to support these file format in Exiv2 are in my mind.

As i practice cmake since 8 years actively in digiKam and in my office, i can help for CMake problems in Exiv2. Just ask me if necessary.

In digiKam, i implemented a lots of unit tests to check the large Qt / Exiv2 interface, with a huge collection of images. I already discovered plenty of non re-entrancy in Exiv2 API and i consolidate digiKam code with several lock, as we use multi-threading and multi-core everywhere.
In digiKam, Exiv2 API is only located in the core Qt interface. So the code in use is limited and not dispatched everywhere. Rememeber that digiKam code is more than 1.5 M of C++ code lines.

I'm also aware about the MinGW port, as we cross compile ALL the digiKam code + all dependencies for Windows under Linux using MXE. I'm in love with cross compiling, so if something do not work here, i'm ready to report a fix quickly.

digiKam has a large users base, and we publish weekly a new test version for Linux, Windows, and MacOS. If something is broken or do not work in Exiv2, we are able to report the dysfunction quickly.

Voilà, I'm here to help you if necessary if time permit.

Best

Gilles Caulier

@fgeek

This comment has been minimized.

Copy link
Collaborator

commented Oct 5, 2019

Thank you Robin Mills for all your efforts towards better open-source software. It was a pleasure to cooperate with you 👍

@phako

This comment has been minimized.

Copy link
Contributor

commented Oct 5, 2019

Mainly some random thoughts there, sorry

  • I'll probably also could check out cmake stuff, it's part of my daily work as well.

  • I can provide some web hosting if necessary

  • I could probably also provide some temporary infrastructure for Jenkins (would have to discuss that beforehand, though)

  • What exactly was the Jenkins doing for releases that cannot be replicated by other means of CI?

  • I'd suggest to drop old unmaintained code, which you've already started on master. Do only meta-data.

  • While the idea of just doing a rewrite sounds always great, especially if the codebase wasn't yours to begin with, the job of doing the rewrite or ever reaching feature parity with the old codebase might be a lost fight from the start

  • A rewrite does not relief you from bugfixing the old code, unfortunately

  • If there's a rewrite, it needs to be consumable by C/C++ which rules out most of the "sexy" languages anyway. The only way I can actually think of would be a gradual conversion to Rust.

  • I'd also be interested in getting HEIC/HEIF support as well; I was following the PR but lost track

  • Attracting contributors for old stuff is usually hard. Best guess would be to get your "downstream" abord contributing, which you are obviously trying ;)

  • Have you ever communicated the current lack of staffing? I wasn't really under the impression that there is any issue there

  • TBH, I found the setup of the exiv2 project a tad weird. It's missing some basic infrastructure I am used to from other projects, like a user's / developers discussion forum (whatever form). Things certainly got more obvious with the move to github, though.

  • Unfortunately for you, the initial decision for GPLv2, while encouraged by the FSF or rather RMS for libraries instead of going for its Lesser cousin limits corporate adoption. I suppose that this was done to encourage the use of the commercial license for those use-cases. Even more unfortunate is that this isn't something that can easily be changed without a massive headache

@tester0077

This comment has been minimized.

Copy link
Collaborator

commented Oct 6, 2019

@derselbst

This comment has been minimized.

Copy link
Collaborator

commented Oct 6, 2019

Hi,

I am mainly a user of exiv2 (coming from gwenview) and pretty new to the team; Robin invited me recently. I'm familiar with C++, Cmake, CI. However, I'm also part of two other organizations here at GitHub, which require most of my free time. But I'll try my best to help out where I can, just ping me.

Regarding how to attract new contributors, I would like to mention that the number of contributors is actually growing. So things don't look too bad to me. Simplifying the review process sounds good to me, @D4N has raised some good ideas. A rewrite IMO would be counterproductive for this project.

@phako

This comment has been minimized.

Copy link
Contributor

commented Oct 6, 2019

Btw, I need to release a new version of gexiv2 soonish. The document mirror on exiv2.dyndns.org is gone, I assume?

@clanmills

This comment has been minimized.

Copy link
Collaborator

commented Oct 6, 2019

exiv2.dyndns.org is gone. The release is on https://exiv2.org and the pre-release on https://pre-release.exiv2.org

A couple of obvious points about v0.27.3 (and later v0.27 dots)

  1. You can publish source releases on GitHub without updating exiv2.org
  2. If you publish releases on GitHub, I'm willing to update exiv2.org and build the binaries with Jenkins on the MacMini, if (and only if) the web and release code is stored on SVN. I've retired because of frustration with review/git/github.

I wish I could make the fuzzing police disappear or get them to participate in fixing security issues. They appear to have more resources than Team Exiv2. I believe Kevin is the only "fuzzer" who both reported and fixed CVEs.

@phako

This comment has been minimized.

Copy link
Contributor

commented Oct 6, 2019

I ased regarding exvi2.dyndns.org because I received a patch to point all the docs to there. Which I will probably revert now.

Regarding the fuzzing: Unfortunately, fuzzing is quite use- and helpful. But, looking at eg. #1019 that ticket is basically useless.

  • You should take away reporter's abilites to classify tickets. Classifying tickets is the project's job
  • You should make fuzzing guidelines that embraces those people (I honestly have an issue with people who think writing in l33t is giving them some kind of credibility...) but also gives them a check-list of what to provide. Filing a fuzzing ticket with no reproduction material is basically use-less, it just leaves you the chance of catching such issues by code review. All fuzzers I know give you easy access to the input material that was causing an issue
@clanmills

This comment has been minimized.

Copy link
Collaborator

commented Oct 6, 2019

Jens: I seem to recall our conversation about dyndns.org in Exiv2 v0.27-RC days (about one year ago). Since then, thanks to @nehaljwani, we moved exiv2.org to a new AWS and have the pre-release web-site.

@clanmills

This comment has been minimized.

Copy link
Collaborator

commented Oct 6, 2019

I agree with you that fuzzing is useful. However the behaviour of the fuzzing police is very unhelpful and demotivating. That bug report today is a good example. I wouldn't be surprised if it's already fixed in v0.27.2 and is actually a waste of time.

@piponazo

This comment has been minimized.

Copy link
Collaborator

commented Oct 6, 2019

Hi all,

Thanks @D4N for the effort of creating this issue and giving details about the current state of the project and proposing some short/long terms actions to try to improve the situation. I find useful to have this open discussion in a github thread instead of having it in a chat.

Please find my feedback about each of the proposed steps:

Short term steps

Move the project into (hard) maintenance mode: i.e. no new features, just bugfixes.

I guess that here you are referring here about the support we can give to the project given our busy lives. I do not see myself contributing in new features during the next months, due to my personal situation, and I agree that if I find time to contribute to the project, I will do it fixing reported bugs in 0.27-maintenance.

Nonetheless, I would be more than happy to see people contributing new features to master and I will try to also dedicate time to review those PRs and guide contributors as much as possible.

Ensure that we can produce a 0.27.3 release by the end of 2019: create releases on our current CI without Jenkins. A prerequisite for that is that we can build exiv2 in a reproducible fashion (which is possible, openSUSE is already doing that with one patch).

I think it should be possible to generate the binary artifacts for 0.27.3 from travisCI and Appveyor. I could dedicate some to this topic in the next days/weeks. I remember that long ago we discussed about some security issue in travisCI regarding the deployment of binary artifacts and that's we discarded that option. Opinions about this ?

Move the exiv2 webpage to github or gitlab pages.

I like this idea. I think it is good to centralise as much as possible all the content/discussions about Exiv2 to a single place.

Migrate all existing svn repositories that are still out there to git under the Exiv2 org

I am not sure to what are you referring to here. Would you mind to develop a bit more this?

Long term steps

Drastically reduce the scope of Exiv2 to match only what our API consumers require

I think this is matching we some of the previous actions we have taken on master: i.e, to drop stuff not related with Image Metadata. Of course, any suggestions to keep improving the API would be welcomed.

We find new contributors. Imho unfortunately rather unlikely, as the past showed. We can try to raise awareness about exiv2, but unfortunately I don't really know how to make this project appealing to new contributors.

Not sure either about how to find new contributors. Exiv2 has been for me the first open source project in which I participate regularly. Somehow, after working on it for several months I felt responsible of addressing bugs and improving some specific areas ... I guess that newcomers would be interesting in addressing more interesting topics, such as adding support for new formats.

We rewrite the whole thing?

I do not think it is realistic.

Improve processes

Pull requests don't get reviewed and cannot be merged

When I had lot of spare time to work on Exiv2 (in a period in which I was switching jobs) this is what I found more annoying about our process. For big changes, I think it is fine to establish some "grace period" for a review. But most of the times we are fixing small bugs or making small improvements here and there which should not be blocked for so long. From my point of view, anyone with admin rights in the Exiv2 group, should have freedom and the good judgement to merge something quickly when the changes are mostly cosmetic or when we are dealing with fixing something in CI (just the first examples that came to my mind). In case one of these persons abuse this power, we could analyse the behaviour and decide what to do.

CI is flaky and breaks, only one person can fix it (@D4N for GitLab, @piponazo for Appveyor). If the person is busy, PRs are red and cannot be merged disappointed. => We could move the tests to github actions, so that everyone has access to them and can fix the issues.

Would it not be possible to move the permissions of Gitlab, TravisCI and Appveyor to the Exiv2 team instead of being me and @D4N the owners of these services? I will investigate with TravisCI and Appveyor (I was the one adding those services to Exiv2).

PR reviews are merciless and annoying because a lot of minor stuff gets flagged. I am the culprit in this case. If this is a stop gap for many, then I will stop reviewing PRs in detail and instead amend them to fix issues that I find need fixing (provided I have time).

I do not think this is something bad per se. I particularly always appreciate the time people dedicate to review the code I am submitting, and if the suggestions made are good, I always try to address the challenges. I also know by experience that this is not the most common way to react to the code reviews, and some people gets are less open to change things (for whatever reason).

Something that I proposed in few companies where I have worked is to tag the comments with labels indicating the importance of the comment. Something like:

  • [minor] : Something that could be improved, but that is really a minor thing. Nothing would happen if it is not changed.
  • [style, naming] : Cosmetic things. [naming] is normally about improving code readability. [style] is about following the project guidelines / style. Not considered as blocking issues, but it would be nice to address.
  • [bug/leak] : Problems detected in the new code. Need to be addressed before accepting.
  • [important / blocker] : Not a bug or leak, but something it is extremely important from the point of view of the reviewer, and it should be addressed before the PR is accepted.

I would say that we could try to be a bit more indulgent in some cases (contributors do not have much spare time or have difficulties with Git), and approve PRs unless there are open comments tagged with [bug/leak/blocker]. Then, for the project maintainers it would take probably few minutes to address the other less important comments.

@phako

This comment has been minimized.

Copy link
Contributor

commented Oct 6, 2019

btw... The Coverity page needs some love. It has been last updated with v0.25 https://scan.coverity.com/projects/exiv2

@phako

This comment has been minimized.

Copy link
Contributor

commented Oct 6, 2019

For attracting new contributors, I recently learned about https://up-for-grabs.net/#/ - maybe that helps to get people interested?

@TrechNex

This comment has been minimized.

Copy link

commented Oct 8, 2019

Just sent out a link to this issue across the Glimpse project communication & social media channels. Hopefully some of the hype we've drummed up will do you some good as well. :)

@cryptomilk

This comment has been minimized.

Copy link
Collaborator

commented Oct 9, 2019

Code review is important to keep a high standard of code quality. It is important to ensure that there are no new bugs introduced and things don't break. Yes, it is not a task any developers wants to spent most of if times on. When I request a review for a new merge request I also have to review the code from someone else.

For fuzzing and also security related fixes it is important to have the process documented. You can use: https://www.libssh.org/development/security-process/

Write down which versions you support and communicate that. Example: https://wiki.samba.org/index.php/Samba_Release_Planning

This way you can always point people to your processes. The smaller the team the less versions you should have in maintenance mode.

I hope that helps.

@ognarb

This comment has been minimized.

Copy link

commented Oct 9, 2019

Disclaimer: KDE dev and indirect user of Exiv2 ;)

Hello, another possibility for Exiv2 would be to be integrated into a bigger community (KDE, GNOME or Free Desktop) and use the infrastructure provided by this community.

In the case of KDE, this would allow the Exiv2 developers to use the server infrastructure (Jenkyll CI or gitlab CI, site hosting, release team, promo team, translations, sysadmin, ...). Joining a bigger community could also help because devs from other projects can help with reviewing merge request.

For KDE we have an incubating process, documented here: https://community.kde.org/Incubator. I don't think Exiv2 will have problem passing the incubation, since we are already using Exiv2 in a lot of place: KFileMetadata, Baloo, Dolphin's information panel, Digikam, Gwenview, and probably more :D

CCing more people @jriddell @Pointedstick who can give more details

@Pointedstick

This comment has been minimized.

Copy link

commented Oct 9, 2019

I know that some KDE contributors have sent patches, so it seems that there's some overlap in skills already. It might be a good match. If you folks are interested, I would be more than happy to help with the incubation process!

@cgilles

This comment has been minimized.

Copy link
Collaborator

commented Oct 9, 2019

Hi KDE guys
I already proposed this kind of migration 10 years ago without success. The proposal was not addressed at right moment in the project life. Migrating is always time consuming, and where a project is growing quickly, this will introduce a time latency in release plan.
One big advantage to migrate to KDE infra is the big translators team which will internationalize well the library and the CLI tools.
This kind of migration will permit also to see the project maintained by a large community of developers from KDE family.
So, i vote for this idea.
Gilles Caulier

@phako

This comment has been minimized.

Copy link
Contributor

commented Oct 9, 2019

Since it is quite widespread indirectly in GNOME, if you can guarantee to keep Qt out of it, KDE might be a good place, otherwise maybe freedesktop is probably better.

Edit: That wasn't meant to bash on Qt. It's more of a practical thing relating to Gtk and Qt mixing together being a bit weird on a technical level

@D4N

This comment has been minimized.

Copy link
Member Author

commented Oct 11, 2019

Hi folks,

thanks for all these comments!

A few comments to some replies:

from @phako:

* What exactly was the Jenkins doing for releases that cannot be replicated by other means of CI?

Jenkins was/is building the releases of exiv2 that get published. It can surely be replicated with any other CI, we just haven't set this up yet.

* I'd suggest to drop old unmaintained code, which you've already started on master. Do only meta-data.

👍

* If there's a rewrite, it needs to be consumable by C/C++ which rules out most of the "sexy" languages anyway. The only way I can actually think of would be a gradual conversion to Rust.

That was my idea too, Rust is very tempting, but a rewrite is not realistic unless a bunch of experienced coders step up and drive this forward.

* I'd also be interested in getting HEIC/HEIF support as well; I was following the PR but lost track

Currently licensing is a blocking that PR (and that it had absolutely zero tests last time I checked).

* TBH, I found the setup of the exiv2 project a tad weird. It's missing some basic infrastructure I am used to from other projects, like a user's / developers discussion forum (whatever form). Things certainly got more obvious with the move to github, though.

As a reaction to this, I've created a public chatroom on matrix.org: #exiv2-chat:matrix.org, a discussion mailing list: ~d4n/exiv2-discussion@lists.sr.ht, an announcement mailing list https://lists.sr.ht/~d4n/exiv2-announce and a patches mailing list: ~d4n/exiv2-patches@lists.sr.ht.

* Unfortunately for you, the initial decision for GPLv2, while encouraged by the FSF or rather RMS for libraries instead of going for its Lesser cousin limits corporate adoption. I suppose that this was done to encourage the use of the commercial license for those use-cases. Even more unfortunate is that this isn't something that can easily be changed without a massive headache

Actually we are using GPLv2+, so that would make an integration with e.g. libheif a little simpler, but changing the license is completely off the table as we lack the necessary team of lawyers.

from @clanmills:

exiv2.dyndns.org is gone. The release is on https://exiv2.org and the pre-release on https://pre-release.exiv2.org

A couple of obvious points about v0.27.3 (and later v0.27 dots)

1. You can publish source releases on GitHub without updating exiv2.org

2. If you publish releases on GitHub, I'm willing to update exiv2.org and build the binaries with Jenkins on the MacMini, if (and only if) the web and release code is stored on SVN.  I've retired because of frustration with review/git/github.

Thanks for the offer, however that will only defer the inevitable: we must be able to create a release without Jenkins. So I'd like to give this a try without Jenkins first, but keep it as a plan B.

from @piponazo:

Ensure that we can produce a 0.27.3 release by the end of 2019: create releases on our current CI without Jenkins. A prerequisite for that is that we can build exiv2 in a reproducible fashion (which is possible, openSUSE is already doing that with one patch).

I think it should be possible to generate the binary artifacts for 0.27.3 from travisCI and Appveyor. I could dedicate some to this topic in the next days/weeks. I remember that long ago we discussed about some security issue in travisCI regarding the deployment of binary artifacts and that's we discarded that option. Opinions about this ?

Travis has had issues in the past with disabled package verification, meaning that adversaries could (in theory) manipulate your build environment.

Nevertheless, I would never trust a cloud provider as the only source of my binaries, unless they can be built reproducible and I can verify them locally. That's what I'd like to achieve: we built exiv2 inside a trusted container locally and on Travis/GitLab/Github and verify that the results are the same. Then Travis can host the artifacts and we are certain that they haven't been tampered with.

Migrate all existing svn repositories that are still out there to git under the Exiv2 org

I am not sure to what are you referring to here. Would you mind to develop a bit more this?

Afaik the website code and some additional tests still exist in svn repos somewhere.

Long term steps

Drastically reduce the scope of Exiv2 to match only what our API consumers require

I think this is matching we some of the previous actions we have taken on master: i.e, to drop stuff not related with Image Metadata. Of course, any suggestions to keep improving the API would be welcomed.

Definitely. Large parts of the API have not been designed with RAII in mind and the io system needs imho a rewrite.

We find new contributors. Imho unfortunately rather unlikely, as the past showed. We can try to raise awareness about exiv2, but unfortunately I don't really know how to make this project appealing to new contributors.

Not sure either about how to find new contributors. Exiv2 has been for me the first open source project in which I participate regularly. Somehow, after working on it for several months I felt responsible of addressing bugs and improving some specific areas ... I guess that newcomers would be interesting in addressing more interesting topics, such as adding support for new formats.

Newcommers like to work on easy bugs, on interesting topics and on clean and well documented code bases. I'm afraid we aren't really shining here.

Improve processes

Pull requests don't get reviewed and cannot be merged

When I had lot of spare time to work on Exiv2 (in a period in which I was switching jobs) this is what I found more annoying about our process. For big changes, I think it is fine to establish some "grace period" for a review.

I agree, if a pull request doesn't get reviewed for n-weeks, then a collaborator can merge it, provided there were no objections and they sent out a few reminders.

But most of the times we are fixing small bugs or making small improvements here and there which should not be blocked for so long. From my point of view, anyone with admin rights in the Exiv2 group, should have freedom and the good judgement to merge something quickly when the changes are mostly cosmetic or when we are dealing with fixing something in CI (just the first examples that came to my mind). In case one of these persons abuse this power, we could analyse the behaviour and decide what to do.

To be honest: I don't like this proposal. Merging a PR without a review should imho be the last resort and not something that you are allowed to do on a regular basis. If this is something really urgent (like a broken CI blocking 10 PRs), then so be it, but otherwise it just becomes too tempting to not wait for a review and just merge the PR "because I don't want to wait".

CI is flaky and breaks, only one person can fix it (@D4N for GitLab, @piponazo for Appveyor). If the person is busy, PRs are red and cannot be merged disappointed. => We could move the tests to github actions, so that everyone has access to them and can fix the issues.

Would it not be possible to move the permissions of Gitlab, TravisCI and Appveyor to the Exiv2 team instead of being me and @D4N the owners of these services? I will investigate with TravisCI and Appveyor (I was the one adding those services to Exiv2).

It's not really a problem of permissions (that's trivial to solve), but rather the general knowledge of the underlying platform. The CentOS CI for instance has been broken for a few weeks, because CentOS removed the python36 binary and replaced it with python3. The fix was simple, but still I've fixed it because I set this thing up and knew how it works. The same would happen with Appveyor: I have neither a testsystem nor the knowledge to fix issues on Windows (see #898, that one is blocked by some MSVC oddity that I do not understand).

So I'd rather like to simplify and unify our CI setup, so that more team members can actually fix the CI.

PR reviews are merciless and annoying because a lot of minor stuff gets flagged. I am the culprit in this case. If this is a stop gap for many, then I will stop reviewing PRs in detail and instead amend them to fix issues that I find need fixing (provided I have time).

I do not think this is something bad per se. I particularly always appreciate the time people dedicate to review the code I am submitting, and if the suggestions made are good, I always try to address the challenges. I also know by experience that this is not the most common way to react to the code reviews, and some people gets are less open to change things (for whatever reason).

Something that I proposed in few companies where I have worked is to tag the comments with labels indicating the importance of the comment. Something like:

* [minor] : Something that could be improved, but that is really a minor thing. Nothing would happen if it is not changed.

* [style, naming]  : Cosmetic things. [naming] is normally about improving code readability. [style] is about following the project guidelines / style. Not considered as blocking issues, but it would be nice to address.

* [bug/leak] : Problems detected in the new code. Need to be addressed before accepting.

* [important / blocker] : Not a bug or leak, but something it is extremely important from the point of view of the reviewer, and it should be addressed before the PR is accepted.

This sounds like a very good idea!

I would say that we could try to be a bit more indulgent in some cases (contributors do not have much spare time or have difficulties with Git), and approve PRs unless there are open comments tagged with [bug/leak/blocker]. Then, for the project maintainers it would take probably few minutes to address the other less important comments.

I'd suggest that we instead fix the issues directly in the PR (usually contributors keep the "allow edits from maintainers" option selected) to prevent a huge backlog of "fix this minor thing" issues.

from @phako

For attracting new contributors, I recently learned about https://up-for-grabs.net/#/ - maybe that helps to get people interested?

Sounds good, I'll add us there and to https://www.codetriage.com/ and will try to create a few more easy onboarding issues.

from @TrechNex

Just sent out a link to this issue across the Glimpse project communication & social media channels. Hopefully some of the hype we've drummed up will do you some good as well. :)

Thank you!

From @cryptomilk:

Code review is important to keep a high standard of code quality. It is important to ensure that there are no new bugs introduced and things don't break. Yes, it is not a task any developers wants to spent most of if times on. When I request a review for a new merge request I also have to review the code from someone else.

The issue at hand is that we often run into the situation that dev A has time to code but dev B has no time to review and so PRs are left rotting.

For fuzzing and also security related fixes it is important to have the process documented. You can use: https://www.libssh.org/development/security-process/

Write down which versions you support and communicate that. Example: https://wiki.samba.org/index.php/Samba_Release_Planning

This way you can always point people to your processes. The smaller the team the less versions you should have in maintenance mode.

I hope that helps.

I've created #1035 to track progress the progress for this.

from @ognarb:

Disclaimer: KDE dev and indirect user of Exiv2 ;)

Hello, another possibility for Exiv2 would be to be integrated into a bigger community (KDE, GNOME or Free Desktop) and use the infrastructure provided by this community.

In the case of KDE, this would allow the Exiv2 developers to use the server infrastructure (Jenkyll CI or gitlab CI, site hosting, release team, promo team, translations, sysadmin, ...). Joining a bigger community could also help because devs from other projects can help with reviewing merge request.

Yes, I was thinking about integrating exiv2 tighter into either the Gnome or KDE ecosystem. I've created #1036 to move the discussion there.

@cgilles

This comment has been minimized.

Copy link
Collaborator

commented Oct 12, 2019

About possible Rust port of the library : for me it's a non-sense ! The C++ code base is enough mature, become really stable and C++11 and later come with real improvement with will be enough for the future of the project.

For me Rust is not the future so far... Try to rewrite this project with this language and you will be sure that the project will be forked immediately.

Best

Gilles Caulier

@D4N

This comment has been minimized.

Copy link
Member Author

commented Oct 12, 2019

About possible Rust port of the library : for me it's a non-sense ! The C++ code base is enough mature, become really stable and C++11 and later come with real improvement with will be enough for the future of the project.

For me Rust is not the future so far... Try to rewrite this project with this language and you will be sure that the project will be forked immediately.

Well, GNOME did that for librsvg and the world didn't end for them. Also, I'd only start with the internals first, so that the API stays the same and you don't even realize that you are using Rust.

But let's not get into bikeshedding here, currently we completely lack the manpower for such an undertaking. On the other hand, I definitely wouldn't be opposed to introducing Rust into our code base.

@cgilles

This comment has been minimized.

Copy link
Collaborator

commented Oct 12, 2019

Maintaining 2 lead code code base will be the hell in time. This will require manpower, and it's not the case for a small open source team. It's already difficult with one lead language, so with 2 it's surrealist.

And i'm not interested by Rust stuff... why to reinvent the wheel again and again with new language. it's a waste of time. Concentrate the effort to fix the bugs and advance the project, this is the plan.

Gilles Caulier

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.