The mailing list has been created and I've opened a PR to update the docs https://github.com/apache/flink-web/pull/583
Op zo 13 nov. 2022 om 09:40 schreef Martijn Visser <martijnvis...@apache.org > > Agreed. I've requested a new private mailing list [1] > > [1] https://issues.apache.org/jira/browse/INFRA-23898 > > On Sat, Nov 12, 2022 at 12:09 PM Márton Balassi <balassi.mar...@gmail.com> > wrote: > >> Hi Martjin, >> >> Given the situation let us set up the Jira signup mailing list following >> the Calcite model. This seems the most sensible to me as of now. >> >> On Fri, Nov 11, 2022 at 7:26 PM Martijn Visser <martijnvis...@apache.org> >> wrote: >> >> > Hi everyone, >> > >> > Unfortunately ASF Infra has already implemented the change and new Jira >> > users can't sign up. >> > >> > I think there is consensus that we shouldn't move from Jira now. My >> > proposal would be to setup a separate mailing list to which users can >> send >> > their request for an account, which gets sent to the PMC so they can >> create >> > accounts for them. I don't see any other short term solution. >> > >> > If agreed, let's open up a vote thread on this. >> > >> > Thanks, Martijn >> > >> > >> > Op do 3 nov. 2022 om 04:51 schreef Xintong Song <tonysong...@gmail.com> >> > >> > > Thanks all for the valuable feedback, opinions and suggestions. >> > > >> > > # Option 1. >> > > I know this is the first choice for pretty much everyone. Many people >> > from >> > > the Flink community (including myself) have shared their opinion with >> > > Infra. However, based on the feedback so far, TBH I don't think things >> > > would turn out the way we want. I don't see what else we can do. Does >> > > anyone have more suggestions on this option? Or we probably have to >> > > scratch it out of the list. >> > > >> > > # Option 4. >> > > Seems there are also quite some concerns on using solely GH issues: >> > limited >> > > features (thus the significant changes to the current issue/release >> > > management processes), migration cost, source of truth, etc. I think >> I'm >> > > also convinced that this may not be a good choice. >> > > >> > > # Option 2 & 3. >> > > Between the two options, I'm leaning towards option 2. >> > > - IMO, making it as easy as possible for users to report issues should >> > be a >> > > top priority. Having to wait for a human response for creating an >> account >> > > does not meet that requirement. That makes a strong objection to >> option 3 >> > > from my side. >> > > - Using GH issues for consumer-facing issues and reflecting the valid >> > ones >> > > back to Jira (either manually by committers or by bot) sounds good to >> me. >> > > The status (open/closed) and labels should make tracking the issues >> > easier >> > > compared to in mailing lists / slack, in terms of whether an issue has >> > been >> > > taken care of / reflected to Jira / closed as invalid. That does not >> mean >> > > we should not reflect things from mailing lists / slack to Jira. >> Ideally, >> > > we leverage every possible channel for collecting user issues / >> feedback, >> > > while guiding / suggesting users to choose GH issues over the others. >> > > - For new contributors, they still need to request an account from a >> PMC >> > > member. They can even make that request on GH issues, if they do not >> mind >> > > posting the email address publicly. >> > > - I would not be worried very much about the privacy issue, if the >> Jira >> > > account creation is restricted to contributors. Contributors are >> exposing >> > > their email addresses publicly anyway, in dev@ mailing list and >> commit >> > > history. I'm also not strongly against creating a dedicated mailing >> list >> > > though. >> > > >> > > Best, >> > > >> > > Xintong >> > > >> > > >> > > >> > > On Wed, Nov 2, 2022 at 9:16 PM Chesnay Schepler <ches...@apache.org> >> > > wrote: >> > > >> > > > Calcite just requested a separate mailing list for users to request >> a >> > > > JIRA account. >> > > > >> > > > >> > > > I think I'd try going a similar route. While I prefer the openness >> of >> > > > github issues, they are really limited, and while some things can be >> > > > replicated with labels (like fix versions / components), things like >> > > > release notes can't. >> > > > We'd also lose a central place for collecting issues, since we'd >> have >> > to >> > > > (?) scope issues per repo. >> > > > >> > > > I wouldn't want to import everything into GH issues (it's just a >> flawed >> > > > approach in the long-term imo), but on the other hand I don't know >> if >> > > > the auto linker even works if it has to link to either jira or a GH >> > > issue. >> > > > >> > > > Given that we need to change workflows in any case, I think I'd >> prefer >> > > > sticking to JIRA. >> > > > For reported bugs I'd wager that in most cases we can file the >> tickets >> > > > ourselves and communicate with users on slack/MLs to gather all the >> > > > information. I'd argue that if we'd had been more pro-active with >> > filing >> > > > tickets for user issues (instead of relying on them to do it) we >> > > > would've addressed several issues way sooner. >> > > > >> > > > Additionally, since either option would be a sort of experiment, >> then >> > > > JIRA is a safer option. We have to change less and there aren't any >> > > > long-term ramifications (like having to re-import GH tickets into >> > JIRA). >> > > > >> > > > On 28/10/2022 16:49, Piotr Nowojski wrote: >> > > > > Hi, >> > > > > >> > > > > I'm afraid of the migration cost to only github issues and lack of >> > many >> > > > > features that we are currently using. That would be very >> disruptive >> > and >> > > > > annoying. For me github issues are far worse compared to using the >> > > Jira. >> > > > > >> > > > > I would strongly prefer Option 1. over the others. Option 4 I >> would >> > > like >> > > > > the least. I would be fine with Option 3, and Option 2 but >> assuming >> > > that >> > > > > Jira would stay the source of truth. >> > > > > For option 2, maybe we could have a bot that would backport/copy >> user >> > > > > created issues in github to Jira (and link them together)? >> > Discussions >> > > > > could still happen in the github, but we could track all of the >> > issues >> > > as >> > > > > we are doing right now. Bot could also sync it the other way >> around >> > > (like >> > > > > marking tickets closed, affected/fixed versions etc). >> > > > > >> > > > > Best, >> > > > > Piotrek >> > > > > >> > > > > czw., 27 paź 2022 o 07:48 Martijn Visser < >> martijnvis...@apache.org> >> > > > > napisał(a): >> > > > > >> > > > >> Hi, >> > > > >> >> > > > >> We have to keep in mind that if a users asks for a new Jira >> account, >> > > > that >> > > > >> person will need to provide its email address which is the Flink >> PMC >> > > > >> processing personal identifiable information. There needs to be a >> > > > careful >> > > > >> process for that and to be honest, I don't think the ASF should >> do >> > > this >> > > > >> from a privacy perspective. >> > > > >> >> > > > >> As an example, the Calcite community decided to create a >> dedicated, >> > > > private >> > > > >> list where users can ask for an account to avoid making the email >> > > > address >> > > > >> public. >> > > > >> >> > > > >> Best regards, >> > > > >> >> > > > >> Martijn >> > > > >> >> > > > >> Op wo 26 okt. 2022 om 22:31 schreef Danny Cranmer < >> > > > dannycran...@apache.org >> > > > >>> Hello, >> > > > >>> >> > > > >>> I agree with Gyula. My preference is also option 1, and as a >> > fallback >> > > > >>> option 3. Handling new user account requests will be manageable, >> > > > >> especially >> > > > >>> via slack. We could setup a dedicated channel for people to ask >> for >> > > > >>> Jira/wiki access. >> > > > >>> >> > > > >>> Thanks, >> > > > >>> Danny >> > > > >>> >> > > > >>> On Wed, 26 Oct 2022, 12:16 Gyula Fóra, <gyf...@apache.org> >> wrote: >> > > > >>> >> > > > >>>> Hi! >> > > > >>>> >> > > > >>>> I would also personally prefer staying with JIRA given the >> feature >> > > set >> > > > >>> and >> > > > >>>> the past positive experience with it. >> > > > >>>> I think the structured nature of JIRA with flexible components, >> > > issue >> > > > >>>> types, epics, release handling etc have been a great benefit to >> > the >> > > > >>>> project, it would be a shame to give some of these up. >> > > > >>>> >> > > > >>>> If for some reason Option 1 is not possible, I would still >> prefer >> > > > >> Option >> > > > >>> 3 >> > > > >>>> (requiring new contributors to ask for JIRA access) compared to >> > the >> > > > >>>> alternatives. >> > > > >>>> >> > > > >>>> Cheers, >> > > > >>>> Gyula >> > > > >>>> >> > > > >>>> >> > > > >>>> On Tue, Oct 25, 2022 at 3:48 PM Robert Metzger < >> > rmetz...@apache.org >> > > > >> > > > >>>> wrote: >> > > > >>>> >> > > > >>>>> Thank you for starting this discussion Xintong! >> > > > >>>>> >> > > > >>>>> I would also prefer option 1. >> > > > >>>>> >> > > > >>>>> The ASF Jira is probably one of the largest, public Jira >> > instances >> > > on >> > > > >>> the >> > > > >>>>> internet. Most other Jiras are internal within companies, so >> > > > >> Atlassian >> > > > >>> is >> > > > >>>>> probably not putting a lot of effort into automatically >> detecting >> > > and >> > > > >>>>> preventing spam and malicious account creation. >> > > > >>>>> If we want to convince Infra to keep the current sign up >> process, >> > > we >> > > > >>>>> probably need to help them find a solution for the problem. >> > > > >>>>> Maybe we can configure the ASF Jira to rely on GitHub as an >> > > identity >> > > > >>>>> provider? I've just proposed that in the discussion on >> > > > >>>>> us...@infra.apache.org, let's see ;) >> > > > >>>>> >> > > > >>>>> Best, >> > > > >>>>> Robert >> > > > >>>>> >> > > > >>>>> >> > > > >>>>> On Tue, Oct 25, 2022 at 2:08 PM Konstantin Knauf < >> > > kna...@apache.org> >> > > > >>>>> wrote: >> > > > >>>>> >> > > > >>>>>> Hi everyone, >> > > > >>>>>> >> > > > >>>>>> while I see some benefits in moving to Github Issues >> completely, >> > > we >> > > > >>>> need >> > > > >>>>> to >> > > > >>>>>> be aware that Github Issues lacks many features that Jira >> has. >> > > From >> > > > >>> the >> > > > >>>>> top >> > > > >>>>>> of my head: >> > > > >>>>>> * there are no issue types >> > > > >>>>>> * no priorities >> > > > >>>>>> * issues can only be assigned to one milestone >> > > > >>>>>> So, you need to work a lot with labels and conventions and >> > > > >> basically >> > > > >>>> need >> > > > >>>>>> bots or actions to manage those. Agreeing on those processes, >> > > > >> setting >> > > > >>>>> them >> > > > >>>>>> up and getting used to them will be a lot of work for the >> > > > >> community. >> > > > >>>>>> So, I am also in favor of 1) for now, because I don't really >> > see a >> > > > >>> good >> > > > >>>>>> alternative option. >> > > > >>>>>> >> > > > >>>>>> Cheers, >> > > > >>>>>> >> > > > >>>>>> Konstantin >> > > > >>>>>> >> > > > >>>>>> >> > > > >>>>>> >> > > > >>>>>> Am Mo., 24. Okt. 2022 um 22:27 Uhr schrieb Matthias Pohl >> > > > >>>>>> <matthias.p...@aiven.io.invalid>: >> > > > >>>>>> >> > > > >>>>>>> I agree that leaving everything as is would be the best >> > option. I >> > > > >>>> also >> > > > >>>>>> tend >> > > > >>>>>>> to lean towards option 4 as a fallback for the reasons >> already >> > > > >>>>> mentioned. >> > > > >>>>>>> I'm still not a big fan of the Github issues. But that's >> > probably >> > > > >>>> only >> > > > >>>>>>> because I'm used to the look-and-feel and the workflows of >> > Jira. >> > > > >> I >> > > > >>>> see >> > > > >>>>>>> certain benefits of moving to Github, though. We're still >> > having >> > > > >>> the >> > > > >>>>> idea >> > > > >>>>>>> of migrating from AzureCI to GitHub Actions. Moving the >> issues >> > to >> > > > >>>>> GitHub >> > > > >>>>>> as >> > > > >>>>>>> well might improve the user experience even more. Reducing >> the >> > > > >>> number >> > > > >>>>> of >> > > > >>>>>>> services a new contributor should be aware of to reach the >> > > > >>> community >> > > > >>>>> is a >> > > > >>>>>>> good way to reduce the confusion for newcomers, I could >> > imagine. >> > > > >>>>>>> Additionally, I also like the fact that I wouldn't have to >> > bother >> > > > >>>> about >> > > > >>>>>> the >> > > > >>>>>>> Apache Jira markdown anymore. 8) >> > > > >>>>>>> >> > > > >>>>>>> I agree with Martijn's concern about not being able to track >> > all >> > > > >>>>>>> Flink-related issues in a single system. I'm just wondering >> > > > >> whether >> > > > >>>>>>> something is holding us back from collecting all >> Flink-related >> > > > >>> issues >> > > > >>>>> in >> > > > >>>>>>> the Flink's Github repository and disabling the issue >> feature >> > in >> > > > >>> any >> > > > >>>>>> other >> > > > >>>>>>> Flink-related repository? >> > > > >>>>>>> >> > > > >>>>>>> About migrating the Jira issues: I would be hopeful that >> > > > >> migrating >> > > > >>> is >> > > > >>>>>>> doable in the end. There is a blog post from the spring data >> > guys >> > > > >>>> about >> > > > >>>>>>> their journey on migrating from Jira to GitHub issues [1]. >> > > > >>>>> Unfortunately, >> > > > >>>>>>> they didn't provide any scripts. >> > > > >>>>>>> >> > > > >>>>>>> For the case that infra moves forward with disabling the >> signup >> > > > >>>> without >> > > > >>>>>> us >> > > > >>>>>>> having come up with a decision and its actual execution >> (i.e. >> > > > >>>> migrating >> > > > >>>>>> the >> > > > >>>>>>> Jira issues to GH), I would prefer having users send a >> request >> > to >> > > > >>> the >> > > > >>>>>>> mailing list. I would rather have a temporary phase where >> > > > >> there's a >> > > > >>>> bit >> > > > >>>>>> of >> > > > >>>>>>> overhead of registering the users in the Apache Jira than >> > having >> > > > >>> two >> > > > >>>>>>> locations for bug tracking. I suspect that there are no >> > > > >> statistics >> > > > >>> on >> > > > >>>>> how >> > > > >>>>>>> many new users register with Jira in a given timeframe to >> > > > >>> contribute >> > > > >>>> to >> > > > >>>>>>> Flink? >> > > > >>>>>>> >> > > > >>>>>>> Matthias >> > > > >>>>>>> >> > > > >>>>>>> [1] >> > > > >>>>>>> >> > > > >>>>>>> >> > > > >> >> > > > >> > > >> > >> https://spring.io/blog/2021/01/07/spring-data-s-migration-from-jira-to-github-issues >> > > > >>>>>>> [2] >> > > > >>> >> https://lists.apache.org/thread/pjb5jzvw41xjtzgf4w0gggpqrt2fq6ov >> > > > >>>>>>> >> > > > >>>>>>> On Mon, Oct 24, 2022 at 10:28 AM Xintong Song < >> > > > >>> tonysong...@gmail.com >> > > > >>>>>>> wrote: >> > > > >>>>>>> >> > > > >>>>>>>> I agree with you that option 1) would be the best for us. >> > Let's >> > > > >>>> keep >> > > > >>>>>>> hoping >> > > > >>>>>>>> for the best. >> > > > >>>>>>>> >> > > > >>>>>>>> Option 4), as you said, comes with prices. At the moment, I >> > > > >> don't >> > > > >>>>> have >> > > > >>>>>>>> thorough answers to your questions. >> > > > >>>>>>>> >> > > > >>>>>>>> Just one quick response, I think there's a good chance >> that we >> > > > >>> can >> > > > >>>>>> import >> > > > >>>>>>>> current Jira tickets into GH. Jira supports exporting >> issues >> > > > >> with >> > > > >>>>>> fields >> > > > >>>>>>>> that you specified as CSV/XML/... files. With a brief >> google >> > > > >>>> search, >> > > > >>>>> I >> > > > >>>>>>>> found some tools that help bulk creating issues in GH. >> E.g., >> > > > >>>>>>>> github-csv-tools [1] is described to support importing >> issues >> > > > >>> with >> > > > >>>>>> title, >> > > > >>>>>>>> body, labels, status and milestones from a CSV file. That's >> > > > >>>> probably >> > > > >>>>>> good >> > > > >>>>>>>> enough for us to search/filter the issues in GH, and a >> link to >> > > > >>> the >> > > > >>>>> Jira >> > > > >>>>>>>> ticket can be posted in the GH issue for complete >> conversation >> > > > >>>>> history >> > > > >>>>>>> and >> > > > >>>>>>>> other details. >> > > > >>>>>>>> >> > > > >>>>>>>> Best, >> > > > >>>>>>>> >> > > > >>>>>>>> Xintong >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> [1] https://github.com/gavinr/github-csv-tools >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> On Mon, Oct 24, 2022 at 3:58 PM Martijn Visser < >> > > > >>>>>> martijnvis...@apache.org >> > > > >>>>>>>> wrote: >> > > > >>>>>>>> >> > > > >>>>>>>>> Hi Xintong, >> > > > >>>>>>>>> >> > > > >>>>>>>>> I'm also not in favour of option 2, I think that two >> systems >> > > > >>> will >> > > > >>>>>>> result >> > > > >>>>>>>>> in an administrative burden and less-efficient workflow. >> I'm >> > > > >>> also >> > > > >>>>> not >> > > > >>>>>>> in >> > > > >>>>>>>>> favour of option 3, I think that this will result in first >> > > > >> time >> > > > >>>>>>>>> users/contributors in not-filling their first bug report, >> > > > >> user >> > > > >>>>>> question >> > > > >>>>>>>> or >> > > > >>>>>>>>> feature request. >> > > > >>>>>>>>> >> > > > >>>>>>>>> I'm still hoping for option 1 while the discussion is not >> > > > >>>> finished >> > > > >>>>>> with >> > > > >>>>>>>>> Infra. >> > > > >>>>>>>>> >> > > > >>>>>>>>> If we assume that option 1 won't be possible, then I think >> > > > >>>> option 4 >> > > > >>>>>>> will >> > > > >>>>>>>>> be the best-option-left. I'm not necessarily in favour, >> > > > >> because >> > > > >>>> of >> > > > >>>>> a >> > > > >>>>>>>> number >> > > > >>>>>>>>> of problems it will introduce: >> > > > >>>>>>>>> >> > > > >>>>>>>>> 1. I don't think importing current Jira tickets into >> Github >> > > > >>>> Issues >> > > > >>>>>> is a >> > > > >>>>>>>>> realistic option. So we would have two administrations. >> > > > >> Before >> > > > >>>> you >> > > > >>>>>>>> create a >> > > > >>>>>>>>> new ticket, you should check if it exists both as a Jira >> > > > >> ticket >> > > > >>>> and >> > > > >>>>>> as >> > > > >>>>>>> a >> > > > >>>>>>>>> Github Issue. >> > > > >>>>>>>>> 2. How would we deal with completing a PR? There must be >> one >> > > > >>>>>>>>> administration leading for the changelog generation (to >> avoid >> > > > >>>> that >> > > > >>>>>>> you're >> > > > >>>>>>>>> missing an item), which could then only be Github Issues. >> So >> > > > >>>> would >> > > > >>>>> we >> > > > >>>>>>>>> require all PRs that are merged to exist as a Github >> Issue? >> > > > >>>>>>>>> 3. There's no longer one central administration, which is >> > > > >>>>> especially >> > > > >>>>>>>>> valuable to track all issues across projects like the >> > > > >> different >> > > > >>>>>>>> connectors, >> > > > >>>>>>>>> Flink ML, Table Store etc. >> > > > >>>>>>>>> 4. Our current CI labeling works on the Jira issues, not >> on >> > > > >> the >> > > > >>>>>> Github >> > > > >>>>>>>>> Issues labels. >> > > > >>>>>>>>> >> > > > >>>>>>>>> Best regards, >> > > > >>>>>>>>> >> > > > >>>>>>>>> Martijn >> > > > >>>>>>>>> >> > > > >>>>>>>>> On Mon, Oct 24, 2022 at 7:29 AM Xintong Song < >> > > > >>>>> tonysong...@gmail.com> >> > > > >>>>>>>>> wrote: >> > > > >>>>>>>>> >> > > > >>>>>>>>>> Hi devs and users, >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> As many of you may have already noticed, Infra announced >> > > > >> that >> > > > >>>> they >> > > > >>>>>>> will >> > > > >>>>>>>>>> soon disable public Jira account signups [1]. That >> means, in >> > > > >>>> order >> > > > >>>>>> for >> > > > >>>>>>>>>> someone who is not yet a Jira user to open or comment on >> an >> > > > >>>> issue, >> > > > >>>>>>>> he/she >> > > > >>>>>>>>>> has to first reach out to a PMC member to create an >> account >> > > > >>> for >> > > > >>>>>>> him/her. >> > > > >>>>>>>>>> This raises the bar for new contributors and users to >> > > > >>>> participate >> > > > >>>>> in >> > > > >>>>>>>>>> community interactions, making it necessary for us to >> > > > >> consider >> > > > >>>>>> whether >> > > > >>>>>>>> (and >> > > > >>>>>>>>>> how) we should change our issue tracking workflows. >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> I can see a few possible options. >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> 1. Reaching out to Infra and trying to change their mind >> on >> > > > >>> this >> > > > >>>>>>>>>> decision. I’ve already been trying this [2], and so far >> the >> > > > >>>>> feedback >> > > > >>>>>>>> seems >> > > > >>>>>>>>>> unoptimistic. >> > > > >>>>>>>>>> 2. Using both Jira (for development issues) & Github >> Issues >> > > > >>> (for >> > > > >>>>>>>>>> customer-facing issues), as Infra suggested. >> > > > >>>>>>>>>> 3. Stay with using Jira only, so that new Jira users >> need to >> > > > >>> ask >> > > > >>>>> on >> > > > >>>>>>> the >> > > > >>>>>>>>>> mailing lists / Slack for creating accounts. >> > > > >>>>>>>>>> 4. Migrating to Github Issues completely. >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> Personally, I’m leaning toward option 4). >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> TBH, I don’t see any good reason for option 2). I’d >> expect >> > > > >>> using >> > > > >>>>> two >> > > > >>>>>>>>>> different issue tracking tools at the same time would be >> > > > >>> complex >> > > > >>>>> and >> > > > >>>>>>>>>> chaotic. Option 3) is probably more friendly to existing >> > > > >>>>> developers >> > > > >>>>>>> and >> > > > >>>>>>>>>> users, while being less friendly to newcomers. Option 4) >> on >> > > > >>> the >> > > > >>>>>>>> contrary, >> > > > >>>>>>>>>> is more friendly to newcomers, at some migration cost >> which >> > > > >>>> might >> > > > >>>>> be >> > > > >>>>>>>>>> non-trivial but once for all. >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> Github issues have been widely used by many open source >> > > > >>>> projects, >> > > > >>>>>>>>>> including Kubernetes, Flink CDC, and Apache projects >> Iceberg >> > > > >>> and >> > > > >>>>>>>> Airflow. >> > > > >>>>>>>>>> With a set of well-designed labels, we should be able to >> > > > >>> achieve >> > > > >>>>>> most >> > > > >>>>>>> of >> > > > >>>>>>>>>> the Jira functions / features that we currently rely on. >> > > > >>>> Moreover, >> > > > >>>>>> it >> > > > >>>>>>>>>> better integrates the issue tracking and code >> contributing >> > > > >>>>> systems, >> > > > >>>>>>> and >> > > > >>>>>>>>>> would be easier to access (I believe there’s more GH >> users >> > > > >>> than >> > > > >>>>>> Jira / >> > > > >>>>>>>>>> mailing lists). >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> All in all, I’d suggest to keep monitoring Infra’s >> feedback >> > > > >> on >> > > > >>>>>> option >> > > > >>>>>>>> 1), >> > > > >>>>>>>>>> while taking steps (investigation, workflow & label >> design) >> > > > >>>>>> preparing >> > > > >>>>>>>> for >> > > > >>>>>>>>>> option 4). >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> Looking forward to hearing what you think about this. >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> Best, >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> Xintong >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> [1] >> > > > >>>>>> >> > https://lists.apache.org/thread/jx9d7sp690ro660pjpttwtg209w3m39w >> > > > >>>>>>>>>> [2] >> > > > >>>>>> >> > https://lists.apache.org/thread/fjjtk30dxf6fyoo4q3rmkhh028or40fw >> > > > >>>>>>>>>> >> > > > >>>>>> >> > > > >>>>>> -- >> > > > >>>>>> https://twitter.com/snntrable >> > > > >>>>>> https://github.com/knaufk >> > > > >>>>>> >> > > > >> -- >> > > > >> Martijn >> > > > >> https://twitter.com/MartijnVisser82 >> > > > >> https://github.com/MartijnVisser >> > > > >> >> > > > >> > > > >> > > >> > -- >> > Martijn >> > https://twitter.com/MartijnVisser82 >> > https://github.com/MartijnVisser >> > >> > -- Martijn https://twitter.com/MartijnVisser82 https://github.com/MartijnVisser
