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

On Tuesday, February 18, 2020 at 11:19:01 PM UTC-5, Tatu Saloranta wrote:
>
> On Tue, Feb 18, 2020 at 4:59 PM Christopher Currie 
> <chris...@currie.com <javascript:>> 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 +- 
>
> > 
> > 
> > 
> > On Tue, Feb 18, 2020 at 1:14 PM Tatu Saloranta <ta...@fasterxml.com 
> <javascript:>> wrote: 
> >> 
> >> 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 +- 
> >> 
> >> -- 
> >> 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 <javascript:>. 
> >> 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 <javascript:>. 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jackson-dev/CAFkNez9G6pV0wpRcXG9D7tT1JquEZWyqyt8nn%3D0ZWWi6pMROYQ%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 jackson-dev+unsubscr...@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.

Reply via email to