Jackson Kotlin Module needs active maintainers. But what would be the process?

[Tatu Saloranta]

So. I think that the current semi-existence of Jackson Kotlin module
is not good for anyone. While there has been positive progress wrt
many features in 2.10, there have been a few new issues that are
partly my fault for not being able to properly sanity check risks,
concerns, or weight effects of changes.
A particular example would be changes in 2.10 to handling of Singleton
values, where situation is pretty close to lose-lose: regardless of
whether to just blindly skip matching JSON content (2.10 behavior),
return Singleton, or deserialize content, drop resulting instance and
return Singleton (2.9 and before).

At this point my feeling is this: unless a new set of active
maintainers can be found, agreed upon, I do not think I should release
new minor versions of Kotlin module. That just gives false impression
of maintained component.

On plus side, multiple individuals have mentioned they would be
interested in helping -- big thank you to everyone.
But the problem here is this: since I can not properly judge
development of the module, I also can not quite figure out how and who
to hand over guardianship either.

I would be very interested in hearing suggestions, proposals for
finding new owners: and one of few things I have opinion about this
here is that ownership should be shared across more than 1 individual
(but probably no more than 2 - 4).

So. WDYT?

-+ Tatu +-

[Christopher Currie]

Coming out of hibernation to drop some thoughts:

While I sympathize with the idea of not making new releases until a maintainer is found, the unfortunate side-effect of that will be to lock-out Kotlin users from any critical fixes that might occur in Jackson proper, unless it can be guaranteed that last 2.10 release will be forward compatible, which sounds unlikely if you're targeting a major version as the next Jackson release.

That said, holding a release of the next version until a maintainer can be found does make some sense, if it's going to happen eventually, as it gives that maintainer an opportunity to make the next release solid, rather than having to wait for the next patch release train for fixes or improvements. So I guess I'm coming down on the side if "sounds reasonable, for a short time." Better to not release right away, and keep your options open, and re-evaluate if there's a lot of demand for a release.

On the maintainer side, perhaps a team of approvers? Github now supports configuring a repo to require a certain number of reviews before merging; if you've had multiple offers for maintenance, a team of at least three, configured to require two positive reviews, may help to guard against risky merges.

HTH,

Christopher

--
You received this message because you are subscribed to the Google Groups "jackson-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jackson-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/CAL4a10jSFPzGqZJGSyDvrfpWyGRpeFiH2%2BWBphSZev_EXZuGMQ%40mail.gmail.com.

[Tatu Saloranta]

On Tue, Feb 18, 2020 at 4:59 PM Christopher Currie
<chris...@currie.com> wrote:
>
> Coming out of hibernation to drop some thoughts:
>
> While I sympathize with the idea of not making new releases until a maintainer is found, the unfortunate side-effect of that will be to lock-out Kotlin users from any critical fixes that might occur in Jackson proper, unless it can be guaranteed that last 2.10 release will be forward compatible, which sounds unlikely if you're targeting a major version as the next Jackson release.

Right, good points. Moratorium (if any) would not be meant as
punitive, esp. so not for users.

So at very minimum testing to keep 2.10 of module compatible should be done.

I also think that I will probably not do this for 2.11, yet, at least.
That one blocker issue is something I can probably work around by
adding feature (to select singleton handling).
This would give more time and not force the issue too early.

I need to gather some more thoughts as I think there are basically 3
issues (of which just 1 wrt Kotlin) to resolve before 2.11. And maybe
minor 4th question on whether there is need for a RC/alpha/beta
version.

> That said, holding a release of the next version until a maintainer can be found does make some sense, if it's going to happen eventually, as it gives that maintainer an opportunity to make the next release solid, rather than having to wait for the next patch release train for fixes or improvements. So I guess I'm coming down on the side if "sounds reasonable, for a short time." Better to not release right away, and keep your options open, and re-evaluate if there's a lot of demand for a release.
>
> On the maintainer side, perhaps a team of approvers? Github now supports configuring a repo to require a certain number of reviews before merging; if you've had multiple offers for maintenance, a team of at least three, configured to require two positive reviews, may help to guard against risky merges.

Yes, I think that there are good mechanisms for helping with practical aspects.
What I would like to resolve is just the conceptual part: agreements
-- who should and has the right to decide, in a way that tries to
balance stability of changes (reviewing) with efficiency of getting
changes merged (merging what is considered a good change).

>
> HTH,
> Christopher

Thank you, this is helpful.

-+ Tatu +-

> To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/CAFkNez9G6pV0wpRcXG9D7tT1JquEZWyqyt8nn%3D0ZWWi6pMROYQ%40mail.gmail.com.

[Drew Stephens]

I'm a long time Jackson user and almost always use it alongside Kotlin these days.  I'm happy to lend a hand in management of the module going forward; I have significant Kotlin expertise, having used it since right when 1.0 was released, though the internals of the Jackson Kotlin module are new to me.

-Drew

>> To unsubscribe from this group and stop receiving emails from it, send an email to jacks...@googlegroups.com.

>> To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/CAL4a10jSFPzGqZJGSyDvrfpWyGRpeFiH2%2BWBphSZev_EXZuGMQ%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups "jackson-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to jacks...@googlegroups.com.

[Tatu Saloranta]

On Thu, Feb 20, 2020 at 12:34 PM Drew Stephens <drewgs...@gmail.com> wrote:

I'm a long time Jackson user and almost always use it alongside Kotlin these days.  I'm happy to lend a hand in management of the module going forward; I have significant Kotlin expertise, having used it since right when 1.0 was released, though the internals of the Jackson Kotlin module are new to me.

Excellent! I created placeholder issue:

https://github.com/FasterXML/jackson-module-kotlin/issues/302

and included you (still need github account too), as well as Vyacheslav who indicated interest earlier when I asked (I assume he is still interested too).

Everyone else: apologies if I missed an earlier discussion; please remind me if you are still interested in helping as active maintainer. Intention is not to have a ton of work/process/maintenance to do, but to have individuals who can follow-up on issues, help contributors make decisions on PRs. Of course any other active help is appreciated too, but my main concern right now is that I want to enable community to further develop this module without my being the blocker.

So: we have 2 volunteers -- and I think with just one more we would have initial set of new maintainers to give access.

-+ Tatu +-

 

To unsubscribe from this group and stop receiving emails from it, send an email to jackson-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/9e9f0fbf-d0b6-4640-8ec2-ff602eaa81ba%40googlegroups.com.

[Drew Stephens]

I am dinomite on Github: https://github.com/dinomite/

-Drew

To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/9e9f0fbf-d0b6-4640-8ec2-ff602eaa81ba%40googlegroups.com.