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

-Drew

On Thursday, February 20, 2020 at 4:34:39 PM UTC-5, tsaloranta wrote:
>
> On Thu, Feb 20, 2020 at 12:34 PM Drew Stephens <[email protected] 
> <javascript:>> 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 +-
>
>  
>
>>
>> -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 
>>> <[email protected]> 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 <[email protected]> 
>>> 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 [email protected]. 
>>> >> 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 [email protected]. 
>>> > 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 [email protected] <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jackson-dev/9e9f0fbf-d0b6-4640-8ec2-ff602eaa81ba%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jackson-dev/9e9f0fbf-d0b6-4640-8ec2-ff602eaa81ba%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jackson-dev/3122c6c4-bcf1-42fc-8c41-16ef9e78b954%40googlegroups.com.

Reply via email to