On Thu, Feb 20, 2020 at 12:34 PM Drew Stephens <drewgsteph...@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 +- > > -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> 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> >> 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. >> >> 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. >> > 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 > <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 jackson-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/CAGrxA27TGYocpX2n2n%3DTPQ8JTydCFFxdjt4G92uOxp%3DXbxpW3A%40mail.gmail.com.
