Should this project be explicitly considered as deprecated/not supported?

[yantonov]

Based on PR/issues activity it seems so.

In that case it will be nice to update readme and state it explicitly.

Because now there is an illusion that at least someone from time to time checks bug report, but it's not the fact.
In the discussions and chat typical answer: I don't know all details/context/didn't write anything using java for years.
That's why "Maintained by" block contains incorrect and outdated information.

Also some bugs are still here for years.

[mkurz]

Would it make sense if someone else takes over the project or at least give some other people "maintain" permissions?
I could help set up sbt-ci-release to at least make new releases easier.

[mkurz]

@havocp I think you are/were the main maintainer, any thoughts on this? I am watching the repo for quite a while and get the feeling it's not really moving forward anymore.

[yantonov]

Definitely, if the list of maintainers is updated, it won't be a problem anymore.
But right now this project is used in many places, and if it's not supported (and it looks so) the goal can be to remove all dependencies on it.

[ekrich]

My port ekrich/sconfig might be useful for Scala projects. Pretty much none of the fixes here since the initial port have been added however. Cross compiling and other things have been more of a focus.

[yantonov]

Is it possible for sconfig, that only gradle file can be changed to complete migration? (I mean do we have full compatibility in terms of interfaces, namespaces, signatures etc)? I suppose not.

I checked the readme - the answer is no, all code should be patched.

Another question: was it better to improve the current project or create a tiny wrapper around it than to create another project? (it's a rhetorical question).
I suppose we don't have the resources to migrate, also where are the guarantees that we won't have the same situation with sconfig?

Also in terms of the number of usages: here we have 5k+ stars, but only 102 for sconfig.
Definitely, it doesn't correlate exactly with the number of usages but ...

The question is not about the alternatives (at least now), the question is about updating a list of maintainers or specifying explicitly that this project is not supported anymore.

If we didn't have obvious bugs like this #786 it wouldn't be a problem.
It would be a feature-complete stable project, but now it's not the case.

[havocp]

Hi all, fair question, some thoughts:

• I agree that the project is not actively replying to PRs or adding features - I don't have time at the moment unfortunately, though I would love to. I haven't worked for Lightbend in many years.
• I do think Lightbend would make new releases if they were really mandatory for newer JVMs or for a vulnerability or something along those lines.
• Catching up on PRs here would take someone a few months full time though I think, and then the resulting "churn" would undoubtedly create additional fallout work due to new bugs etc.
• Lightbend owns the repo and the maven central publish creds and would have to give permissions to any potential new maintainers, unless someone forked those things.
• There's no showstopper bugs or issues for typical usage as far as I know.
• I do not know the plans for Akka or Play usage.
• For what it's worth I still think this file format is so much better than YAML for configuration.

Actively porting away from the library might be a bit of overkill; it isn't broken and no reason it would break, and any true showstoppers probably would be fixed because Akka/Play would need them fixed if nothing else.

If excited about new features, I think there is potential to create community ownership of the spec (possibly hosting it apart from the Java implementation and spanning all the various ports of the library), and potentially a community-owned branch of this project that keeps API and/or ABI compat. But that would be a lot of work needless to say.
Wish I had time to work on it!

[yantonov]

I disagree about the fact that it isn't broken.
I spent some time investigating why one of the projects was broken due to config changes (that looked valid and are actually valid), then I found that it's a well-known bug.
Definitely, it's not a showstopper but looks like many people faced it and therefore spent time (to find a workaround, which exists hopefully).

Also, is it possible to ping someone from Lightbend to clarify the status of the project?

[havocp]

To be clear, what I mean is that it works fine for lots of people, not that there are no bugs.
The bugs that are there now are well-known. Leaving things untouched probably is better than halfheartedly merging a few PRs, because right now it's a very known quantity. Once someone starts merging PRs it will fix some things and break some other surprise things, that's just how software is, right.

I do think it would be on balance better to actively move the project forward, but you'd want someone to stick around and not just merge a few PRs. We also need someone to fix any fallout from those merges, and generally be on top of things.

[yantonov]

But that's the definition of maintainer?
If we don't have them - let's mark this project as not supported \ read-only, that's the question.
in that case the intent: it's better not to change something will be clear even from the first glance.

So it would be better to spend time again and again when the proposed functionality doesn't work and you should find a workaround?
Even an error message doesn't provide the workaround explicitly by the way for well-known bugs like 'Substituting environment variables fails when merging objects'.

That's why the question is here: if well-known bugs hadn't been fixed for years, it means (by the definition) that the project is not supported.

The question here is not about someone that has to take care, the question is about a specific bug, especially when it's well-known.

[havocp]

It's really up to Lightbend how to describe it in the readme I guess.

[yantonov]

Sure, so the current conclusion:

1. there are no maintainers (information in the "Maintained by" section is outdated)
2. the status of the project is read-only: there is no active development, any sufficient activity in PRs, issues, etc.

[havocp]

I think that's accurate with the caveat that I do think someone would parachute in and address any true showstoppers for the large projects like Akka/Play

[yantonov]

By the way, if it's supposed to use this library only for akka\play internals (not for external usage) it's another point to highlight it.
Now, it's an open project, so many external consumers can depend on it.

[andreaTP]

I think that, at this point, the best possible outcome would be that someone steps up with a fork(possibly sponsored by an employer).
I agree with @havocp that this repository does have more to lose than gains from starting to update it.

It might be a long long shot but let's try to pull in this discussion @mdedetrich (config is a hard dependency for Pekko) and @raboof (the wise) 🙂 .

[mkurz]

For Play I did not experience any showstoppers in the last years, also didn't hear about any real complains about the library.

However, in case something comes up, I am not sure if someone would react in this repo if I would open an issue or a PR.
I might would have to reach out to Lightbend employees directly per email to get things fixed or released.

Regarding a fork: I am not sure if that makes sense. I would prefer to see this repo maintained. Makes much more sense IMHO.
I know new features could break things, but that's what testing is for 😉
Just my 2 cents.

[yantonov]

That's the point, how it's possible to get emails for Lightbend employees?

Completely agree about tests (if tests are green everything is nice, if not let's add new tests).

[mkurz]

I would prefer to see this repo maintained.

What I mean by that is that one or more people from the community should be added as maintainer to at least be sure if something comes up someone can push out at least a new bug fix release. PR's should maybe require 2 reviewers before they get merged. Even if that takes two months for a PR to get in, it's still faster than the current state where nothing gets fixed, since many years.

[mkurz]

one or more people from the community

By that I mean reliable people, that have some track record in the community. (Not talking about me since I am low on time anyway, I might can review some PR's but don't have time to work actively on the project)

[mdedetrich]

I think that, at this point, the best possible outcome would be that someone steps up with a fork(possibly sponsored by an employer). I agree with @havocp that this repository does have more to lose than gains from starting to update it.

It might be a long long shot but let's try to pull in this discussion @mdedetrich (config is a hard dependency for Pekko) and @raboof (the wise) 🙂 .

So the community would have to make a decision but for us in the short term its likely continue to use typesafe config. If its problematic for us in the medium/long term https://github.com/ekrich/sconfig looks like a good contender, especially if we end up integrating Akka.js into Pekko and/or support native.

Another thing I want to plan which is more Pekko specific is to reduce our dependence on typesafe config when it comes to constructing data structures (i.e. the primary way to construct a data type should be with a case class or a data final class rather than a typesafe config as it is now), this is also a big change though.

When it comes to the future of this project, if its unable to be maintained then it should go to the community similar to what happened with Play or Slick. My personal capacity is really stretched at the moment and I am not that familiar with the project but this can change since Pekko has a direct and significant stake in the usage of config

[yantonov]

Does anyone know how to ping someone from Lightbend?
My point is if we rely on 'community would have to make a decision' we will have the same situation for years.

One of the possible actions from Lightbend:

(because at least now there is a dependency on signing the corresponding statement on each PR, and GitHub actions are not started automatically, so it's not possible to do anything without confirmation from someone from Lightbend):

1. update the list of maintainers and start to fix bugs
2. specify that this project has read-only status \ is designed only for internal usage so any external activity is ignored because it's not aligned with the current Lightbend projects.

I don't understand the point: it's risky to change something, it's just a library that reads one file and constructs its own internal representation, why it's a problem to write tests?
By the way, basic functionality I suppose is already covered by them.

[yantonov]

Also if it's too risky to change anything: then the quality of the code is too low (it's complex, hard to test, etc) and it's definitely an argument to stop using the library as soon as possible and reduce the dependency on the Lightbend stack.

[mdedetrich]

Does anyone know how to ping someone from Lightbend? My point is if we rely on 'community would have to make a decision' we will have the same situation for years.

Your best to make a thread on their forums at https://discuss.lightbend.com/

[havocp]

The test coverage is actually quite good I believe, but it's certainly possible to break something without breaking tests.

It isn't a reason to avoid changes. It is a reason to avoid drive-by changes when there's nobody signed up to fix any fallout.

Just my opinion, I don't make the decisions though.

[yantonov]

For the record: https://discuss.lightbend.com/t/status-of-the-lightbend-config-project-bugs-are-not-fixed-for-years/10361

[johanandren]

Hi @yantonov, while the readme may be outdated, this library is an essential part of Akka and modules in the Akka umbrella. We have no plans to change that.

We do not see any critical shortcomings or issues that we think needs to be urgently addressed or obviously needs improvements. We do not have any interest in bigger changes in API or extending what the library supports much and the project will likely move along accordingly at a slow pace like any mature library.

If you or anyone else has some other more grand or fast paced vision, that will not be a priority for us, and a fork may be the best path.

[yantonov]

I'm talking about existing bugs for the functionality that's supposed to work according to the documentation, not about changing API \ extending the library, etc.
The scenario is pretty clear (some examples are mentioned here #786).

So, I've got the point: it's not supported (supported only internally), and the ideal solution for the long-term perspective is to migrate to another library for any external projects (at least due to the fact that bugs even for declared functionality are still here for years).

So actually, it's an answer to the original question, thanks to all for participation!

[andreaTP]

So, I've got the point: it's not supported (supported only internally), and the ideal solution for the long-term perspective is to migrate to another library for any external projects (at least due to the fact that bugs even for declared functionality are still here for years).

I appreciate that this is your takeaway, but the opinions and answers expressed on this thread are pretty different.

Having bugs not fixed for years happens in open-source projects for various reasons, and, in this case, we have no known major or blocking issues.

[yantonov]

Answers are not so different as it seems: there are no maintainers, creating a fork is a big deal every time and nobody wants to support it due to lack of time, there are no blockers (almost always there are no blockers, by the way in any random project, it's not an argument to ignore bug reports for years for the existing functionality).

Again the question is about declared functionality, even if it's not a blocker it would be nice to fix (this functionality is explicitly declared in the documentation by the way, and not working, the exception doesn't provide any meaningful information and even if it's not a blocker people have to deal with it, report about it several times but no actions as usual, which is especially strange due to the fact that it's company account).

Definitely, it's easy to start a philosophical discussion about unknown code, risks, and showstoppers than to fix bugs and write tests for the tiny library which ... surprise, surprise just reads a single file.
Especially due to the fact that this library is used, so at least someone from the company should be familiar with it.

[andreaTP]

This started as a good discussion, but it's not the case anymore.

@johanandren would you mind closing it?

• @yantonov seems to have enough information to proceed
• we started going in circles