Since there were no further comments on this discussion, I removed the "draft" label from the Wiki page and I consider the Jira semantics proposal agreed upon.
On Mon, Jun 15, 2020 at 9:49 AM Piotr Nowojski <pi...@ververica.com> wrote: > > > On 12 Jun 2020, at 15:44, Robert Metzger <rmetz...@apache.org> wrote: > > > > Piotrek, do you agree with my "affects version" explanation? I would like > > to bring this discussion to a conclusion. > > > > +0 for this semantic from my side. > > > On Tue, May 26, 2020 at 4:51 PM Till Rohrmann <trohrm...@apache.org> > wrote: > > > >> If we change the meaning of the priority levels, then I would suggest to > >> have a dedicated discussion for it. This would also be more visible than > >> compared to being hidden in some lengthy discussion thread. I think the > >> proposed definitions of priority levels differ slightly from how the > >> community worked in the past. > >> > >> Cheers, > >> Till > >> > >> On Tue, May 26, 2020 at 4:30 PM Robert Metzger <rmetz...@apache.org> > >> wrote: > >> > >>> Hi, > >>> > >>> 1. I'm okay with updating the definition of the priorities for the > reason > >>> you've mentioned. > >>> > >>> 2. "Affects version" > >>> > >>> The reason why like to mark affects version on unreleased versions is > to > >>> clearly indicate which branch is affected by a bug. Given the current > >> Flink > >>> release status, if there's a bug only in "release-1.11", but not in > >>> "master", there is no way of figuring that out, if we only allow > released > >>> versions for "affects version" (In my proposal, you would set "affects > >>> version" to '1.11.0', '1.12.0' to indicate that). > >>> > >>> What we could do is introduce "1.12-SNAPSHOT" as version to mark issues > >> on > >>> unreleased versions. (But then people might accidentally set the "fix > >>> version" to a "-SNAPSHOT" version.) > >>> > >>> I'm still in favor of my proposal. I have never heard a report from a > >>> confused user about our Jira fields (I guess they usually check bugs > for > >>> released versions only) > >>> > >>> > >>> On Tue, May 26, 2020 at 12:39 PM Piotr Nowojski <pi...@ververica.com> > >>> wrote: > >>> > >>>> Hi, > >>>> > >>>> Sorry for a bit late response. I have two concerns: > >>>> > >>>> 1. Priority > >>>> > >>>> I would propose to stretch priorities that we are using to > >> differentiate > >>>> between things that must be fixed for given release: > >>>> > >>>> BLOCKER - drop anything you are doing, this issue must be fixed right > >> now > >>>> CRITICAL - release can not happen without fixing it, but can be fixed > a > >>>> bit later (for example without context switching and dropping whatever > >>> I’m > >>>> doing right now) > >>>> MAJOR - default, nice to have > >>>> Anything below - meh > >>>> > >>>> We were already using this semantic for tracking test instabilities > >>> during > >>>> the 1.11 release cycle. Good examples: > >>>> > >>>> BLOCKER - master branch not compiling, very frequent test failures > (for > >>>> example almost every build affected), … > >>>> CRITICAL - performance regression/bug that we introduced in some > >> feature, > >>>> but which is not affecting other developers as much > >>>> MAJOR - freshly discovered test instability with unknown > >> impact/frequency > >>>> (could be happening once a year), > >>>> > >>>> 2. Affects version > >>>> > >>>> If bug is only on the master branch, does it affect an unreleased > >>> version? > >>>> > >>>> So far I was assuming that it doesn’t - unreleased bugs would have > >> empty > >>>> “affects version” field. My reasoning was that this field should be > >> used > >>>> for Flink users, to check which RELEASED Flink versions are affected > by > >>>> some bug, that user is searching for. Otherwise it might be a bit > >>> confusing > >>>> if there are lots of bugs with both affects version and fix version > set > >>> to > >>>> the same value. > >>>> > >>>> Piotrek > >>>> > >>>>> On 25 May 2020, at 16:40, Robert Metzger <rmetz...@apache.org> > >> wrote: > >>>>> > >>>>> Hi all, > >>>>> thanks a lot for the feedback. The majority of responses are very > >>>> positive > >>>>> to my proposal. > >>>>> > >>>>> I have put my proposal into our wiki: > >>>>> > >>>> > >>> > >> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=154995514 > >>>>> > >>>>> Regarding the comments so far: > >>>>> @Jark: I clarified this in the wiki. > >>>>> > >>>>> @Israel: I have not considered build changing all 3000 resolved > >> tickets > >>>> to > >>>>> closed yet, but after consideration I don't think it is necessary. If > >>>>> others in the community would like to change them, please speak up in > >>>> this > >>>>> thread :) > >>>>> > >>>>> @Flavio: I agree that we can not ask new or infrequent users to fully > >>>>> adhere to these definitions. I added a note in the Wiki. > >>>>> Using the resolved state for indicating "PR available" is problematic > >>>>> because there are plenty of cases where PRs are stale (and this > >> ticket > >>>>> would then appear as a "resolved"). The Apache tools are adding a > >> link > >>> to > >>>>> the PR, and some contributors are setting the ticket to "In > >> Progress". > >>> I > >>>>> don't see a problem that we need to solve here. > >>>>> > >>>>> @Yun: Thank you for your comment. I added an example clarifying how I > >>>> would > >>>>> handle such a case. It is slightly different from your proposal: You > >>>>> suggested using x.y.0 versions, I used "the next supported, > >> unreleased > >>>>> version", because that's how we've done it so far (and I don't want > >> to > >>>>> change things, I just want to document how the majority of the core > >>>>> contributors are using JIRA). > >>>>> > >>>>> Here are all the changes (in green, blue are just formatting > >> changes) I > >>>>> made compared to my initial proposal: > >>>>> > >>>> > >>> > >> > https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=154995514&selectedPageVersions=4&selectedPageVersions=1 > >>>>> > >>>>> > >>>>> > >>>>> On Mon, May 25, 2020 at 2:28 PM Congxian Qiu <qcx978132...@gmail.com > >>> > >>>> wrote: > >>>>> > >>>>>> @ches...@apache.org <ches...@apache.org> Thanks for the > >> confirmation > >>>>>> > >>>>>> Best, > >>>>>> Congxian > >>>>>> > >>>>>> > >>>>>> Zhu Zhu <reed...@gmail.com> 于2020年5月25日周一 下午4:13写道： > >>>>>> > >>>>>>> This is very helpful! > >>>>>>> +1 > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Zhu Zhu > >>>>>>> > >>>>>>> Yang Wang <danrtsey...@gmail.com> 于2020年5月25日周一 下午4:04写道： > >>>>>>> > >>>>>>>> +1 from this useful proposal. > >>>>>>>> > >>>>>>>> This makes me clearer about "Resolve" and "Close" since I used to > >> be > >>>>>>>> confused by this two button. > >>>>>>>> > >>>>>>>> Best, > >>>>>>>> Yang > >>>>>>>> > >>>>>>>> Jingsong Li <jingsongl...@gmail.com> 于2020年5月25日周一 下午3:10写道： > >>>>>>>> > >>>>>>>>> +1 for the proposal. > >>>>>>>>> It makes me clearer. > >>>>>>>>> > >>>>>>>>> Best, > >>>>>>>>> Jingsong Lee > >>>>>>>>> > >>>>>>>>> On Mon, May 25, 2020 at 2:51 PM Zhijiang < > >>> wangzhijiang...@aliyun.com > >>>>>>>>> .invalid> > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> Thanks for launching this discussion and giving so detailed > >> infos, > >>>>>>>>>> Robert! +1 on my side for the proposal. > >>>>>>>>>> > >>>>>>>>>> For "Affects Version", I previously thought it was only for the > >>>>>>> already > >>>>>>>>>> released versions, so it can give a reminder that the fix should > >>>>>> also > >>>>>>>>> pick > >>>>>>>>>> into the related released branches for future minor versions. > >>>>>>>>>> I saw that Jark had somehow similar concerns for this field in > >>>>>> below > >>>>>>>>>> replies. Either way makes sense for me as long as we give a > >>>>>>> determined > >>>>>>>>>> rule in Wiki. > >>>>>>>>>> > >>>>>>>>>> Re Flavio' s comments, I agree that the Jira reporter can leave > >>>>>> most > >>>>>>> of > >>>>>>>>>> the fields empty if not confirmed of them, then the respective > >>>>>>>> component > >>>>>>>>>> maintainer or committer can update them accordingly later. > >>>>>>>>>> But the state of Jira should not be marked as "resolved" when > >> the > >>>>>> PR > >>>>>>> is > >>>>>>>>>> detected, that is not fitting into the resolved semantic I > >> guess. > >>>>>> If > >>>>>>>>>> possible, the Jira can be updated as "in progress" automatically > >>> if > >>>>>>>>>> the respective PR is ready, then it will save some time to stat > >>>>>>>> progress > >>>>>>>>>> of related issues during release process. > >>>>>>>>>> > >>>>>>>>>> Best, > >>>>>>>>>> Zhijiang > >>>>>>>>>> > >> ------------------------------------------------------------------ > >>>>>>>>>> From:Congxian Qiu <qcx978132...@gmail.com> > >>>>>>>>>> Send Time:2020年5月25日(星期一) 13:57 > >>>>>>>>>> To:dev@flink.apache.org <dev@flink.apache.org> > >>>>>>>>>> Subject:Re: [DISCUSS] Semantics of our JIRA fields > >>>>>>>>>> > >>>>>>>>>> Hi > >>>>>>>>>> > >>>>>>>>>> Currently, when I'm going to create an issue for > >> Project-website. > >>>>>> I'm > >>>>>>>> not > >>>>>>>>>> very sure what the "Affect Version/s" should be set. The problem > >>> is > >>>>>>>> that > >>>>>>>>>> the current Dockfile[1] in flink-web is broken because of the > >> EOL > >>>>>> of > >>>>>>>>> Ubuntu > >>>>>>>>>> 18.10[2], the project-web does not affect any release of Flink, > >> it > >>>>>>> does > >>>>>>>>>> affect the process to build website, so what's the version > >> should > >>> I > >>>>>>> set > >>>>>>>>> to? > >>>>>>>>>> > >>>>>>>>>> [1] > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>> > >>> > >> > https://github.com/apache/flink-web/blob/bc66f0f0f463ab62a22e81df7d7efd301b76a6b4/docker/Dockerfile#L17 > >>>>>>>>>> [2] https://wiki.ubuntu.com/Releases > >>>>>>>>>> > >>>>>>>>>> Best, > >>>>>>>>>> Congxian > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Flavio Pompermaier <pomperma...@okkam.it> 于2020年5月24日周日 > >> 下午1:23写道： > >>>>>>>>>> > >>>>>>>>>>> In my experience it's quite complicated for a normal reporter > >> to > >>>>>> be > >>>>>>>>> able > >>>>>>>>>> to > >>>>>>>>>>> fill all the fields correctly (especially for new users). > >>>>>>>>>>> Usually you just wanto to report a problem, remember to add a > >> new > >>>>>>>>> feature > >>>>>>>>>>> or improve code/documentation but you can't really give a > >>>>>> priority, > >>>>>>>>>> assign > >>>>>>>>>>> the correct label or decide which releases will benefit of the > >>>>>>>> fix/new > >>>>>>>>>>> feature. This is something that only core developers could > >> decide > >>>>>>>>> (IMHO). > >>>>>>>>>>> > >>>>>>>>>>> My experiece says that it's better if normal users could just > >>>>>> open > >>>>>>>>>> tickets > >>>>>>>>>>> with some default (or mark ticket as new) and leave them in > >> such > >>>>>> a > >>>>>>>>> state > >>>>>>>>>>> until an experienced user, one that can assign tickets, have > >> the > >>>>>>> time > >>>>>>>>> to > >>>>>>>>>>> read it and immediately reject the ticket or accept it and > >>>>>> properly > >>>>>>>>>> assign > >>>>>>>>>>> priorities, fix version, etc. > >>>>>>>>>>> > >>>>>>>>>>> With respect to resolve/close I think that a good practice > >> could > >>>>>> be > >>>>>>>> to > >>>>>>>>>> mark > >>>>>>>>>>> automatically a ticket as resolved once that a PR is detected > >> for > >>>>>>>> that > >>>>>>>>>>> ticket, while marking it as closed should be done by the > >> commiter > >>>>>>> who > >>>>>>>>>> merge > >>>>>>>>>>> the PR. > >>>>>>>>>>> > >>>>>>>>>>> Probably this process would slightly increase the work of a > >>>>>>> committer > >>>>>>>>> but > >>>>>>>>>>> this would make things a lot cleaner and will bring the benefit > >>>>>> of > >>>>>>>>>> having a > >>>>>>>>>>> reliable and semantically sound JIRA state. > >>>>>>>>>>> > >>>>>>>>>>> Cheers, > >>>>>>>>>>> Flavio > >>>>>>>>>>> > >>>>>>>>>>> Il Dom 24 Mag 2020, 05:05 Israel Ekpo <israele...@gmail.com> > >> ha > >>>>>>>>> scritto: > >>>>>>>>>>> > >>>>>>>>>>>> +1 for the proposal > >>>>>>>>>>>> > >>>>>>>>>>>> This will bring some consistency to the process > >>>>>>>>>>>> > >>>>>>>>>>>> Regarding Closed vs Resolved, should we go back and switch all > >>>>>>> the > >>>>>>>>>>> Resolved > >>>>>>>>>>>> issues to Closed so that is is not confusing to new people to > >>>>>> the > >>>>>>>>>> project > >>>>>>>>>>>> in the future that may not have seen this discussion? > >>>>>>>>>>>> > >>>>>>>>>>>> I would recommend changing it to Closed just to be consistent > >>>>>>> since > >>>>>>>>>> that > >>>>>>>>>>> is > >>>>>>>>>>>> the majority and the new process will be using Closed going > >>>>>>> forward > >>>>>>>>>>>> > >>>>>>>>>>>> Those are my thoughts for now > >>>>>>>>>>>> > >>>>>>>>>>>> On Sat, May 23, 2020 at 7:48 AM Congxian Qiu < > >>>>>>>> qcx978132...@gmail.com > >>>>>>>>>> > >>>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> +1 for the proposal. It's good to have a unified description > >>>>>>> and > >>>>>>>>>> write > >>>>>>>>>>> it > >>>>>>>>>>>>> down in the wiki, so that every contributor has the same > >>>>>>>>>> understanding > >>>>>>>>>>> of > >>>>>>>>>>>>> all the fields. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Best, > >>>>>>>>>>>>> Congxian > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Till Rohrmann <trohrm...@apache.org> 于2020年5月23日周六 > >>>>>> 上午12:04写道： > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks for drafting this proposal Robert. +1 for the > >>>>>>> proposal. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Cheers, > >>>>>>>>>>>>>> Till > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Fri, May 22, 2020 at 5:39 PM Leonard Xu < > >>>>>>> xbjt...@gmail.com> > >>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks bringing up this topic @Robert, +1 to the > >>>>>> proposal. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> It clarifies the JIRA fields well and should be a rule to > >>>>>>>>> follow. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Best, > >>>>>>>>>>>>>>> Leonard Xu > >>>>>>>>>>>>>>>> 在 2020年5月22日，20:24，Aljoscha Krettek < > >>>>>> aljos...@apache.org > >>>>>>>> > >>>>>>>>> 写道： > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> +1 That's also how I think of the semantics of the > >>>>>>> fields. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Aljoscha > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On 22.05.20 08:07, Robert Metzger wrote: > >>>>>>>>>>>>>>>>> Hi all, > >>>>>>>>>>>>>>>>> I have the feeling that the semantics of some of our > >>>>>>> JIRA > >>>>>>>>>> fields > >>>>>>>>>>>>>> (mostly > >>>>>>>>>>>>>>>>> "affects versions", "fix versions" and resolve / > >>>>>> close) > >>>>>>>> are > >>>>>>>>>> not > >>>>>>>>>>>>>> defined > >>>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>>> the same way by all the core Flink contributors, which > >>>>>>>> leads > >>>>>>>>>> to > >>>>>>>>>>>>> cases > >>>>>>>>>>>>>>> where > >>>>>>>>>>>>>>>>> I spend quite some time on filling the fields > >>>>>> correctly > >>>>>>>> (at > >>>>>>>>>>> least > >>>>>>>>>>>>>> what I > >>>>>>>>>>>>>>>>> consider correctly), and then others changing them > >>>>>> again > >>>>>>>> to > >>>>>>>>>>> match > >>>>>>>>>>>>>> their > >>>>>>>>>>>>>>>>> semantics. > >>>>>>>>>>>>>>>>> In an effort to increase our efficiency, and since I'm > >>>>>>>>>> creating > >>>>>>>>>>> a > >>>>>>>>>>>>> lot > >>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>> (test instability-related) tickets these days, I would > >>>>>>>> like > >>>>>>>>> to > >>>>>>>>>>>>> discuss > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>> semantics, come to a conclusion and document this in > >>>>>> our > >>>>>>>>> Wiki. > >>>>>>>>>>>>>>>>> *Proposal:* > >>>>>>>>>>>>>>>>> *Priority:* > >>>>>>>>>>>>>>>>> "Blocker": needs to be resolved before a release > >>>>>>> (matched > >>>>>>>>>> based > >>>>>>>>>>> on > >>>>>>>>>>>>> fix > >>>>>>>>>>>>>>>>> versions) > >>>>>>>>>>>>>>>>> "Critical": strongly considered before a release > >>>>>>>>>>>>>>>>> other priorities have no practical meaning in Flink. > >>>>>>>>>>>>>>>>> *Component/s:* > >>>>>>>>>>>>>>>>> Primary component relevant for this feature / fix. > >>>>>>>>>>>>>>>>> For test-related issues, add the component the test > >>>>>>>> belongs > >>>>>>>>> to > >>>>>>>>>>>> (for > >>>>>>>>>>>>>>> example > >>>>>>>>>>>>>>>>> "Connectors / Kafka" for Kafka test failures) + > >>>>>> "Test". > >>>>>>>>>>>>>>>>> The same applies for documentation tickets. For > >>>>>> example, > >>>>>>>> if > >>>>>>>>>>>> there's > >>>>>>>>>>>>>>>>> something wrong with the DataStream API, add it to the > >>>>>>>> "API > >>>>>>>>> / > >>>>>>>>>>>>>>> DataStream" > >>>>>>>>>>>>>>>>> and "Documentation" components. > >>>>>>>>>>>>>>>>> *Affects Version/s:*Only for Bug / Task-type tickets: > >>>>>> We > >>>>>>>>> list > >>>>>>>>>>> all > >>>>>>>>>>>>>>> currently > >>>>>>>>>>>>>>>>> supported and unreleased Flink versions known to be > >>>>>>>> affected > >>>>>>>>>> by > >>>>>>>>>>>>> this. > >>>>>>>>>>>>>>>>> Example: If I see a test failure that happens on > >>>>>>> "master" > >>>>>>>>> and > >>>>>>>>>>>>>>>>> "release-1.11", I set "affects version" to "1.12.0" > >>>>>> and > >>>>>>>>>>> "1.11.0". > >>>>>>>>>>>>>>>>> *Fix Version/s:* > >>>>>>>>>>>>>>>>> For closed/resolved tickets, this field lists the > >>>>>>> released > >>>>>>>>>> Flink > >>>>>>>>>>>>>>> versions > >>>>>>>>>>>>>>>>> that contain a fix or feature for the first time. > >>>>>>>>>>>>>>>>> For open tickets, it indicates that a fix / feature > >>>>>>> should > >>>>>>>>> be > >>>>>>>>>>>>>> contained > >>>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>>> the listed versions. Only blocker issues can block a > >>>>>>>>> release, > >>>>>>>>>>> all > >>>>>>>>>>>>>> other > >>>>>>>>>>>>>>>>> tickets which have "fix version/s" set at the time of > >>>>>> a > >>>>>>>>>> release > >>>>>>>>>>>> and > >>>>>>>>>>>>>> are > >>>>>>>>>>>>>>>>> unresolved will be moved to the next version. > >>>>>>>>>>>>>>>>> *Assignee:* > >>>>>>>>>>>>>>>>> Person currently working on the ticket. Assigned after > >>>>>>>>>>> conclusion > >>>>>>>>>>>> on > >>>>>>>>>>>>>>>>> approach by a committer. > >>>>>>>>>>>>>>>>> Often, fixes are obvious and committers self-assign > >>>>>> w/o > >>>>>>>>>>>> discussion. > >>>>>>>>>>>>>>>>> *Resolve / Close:* > >>>>>>>>>>>>>>>>> You can either Resolve or Close a ticket once it is > >>>>>> done > >>>>>>>>>> (fixed, > >>>>>>>>>>>>>>> rejected, > >>>>>>>>>>>>>>>>> invalid, ...). > >>>>>>>>>>>>>>>>> As a rule, we Close tickets instead of Resolving them > >>>>>>> when > >>>>>>>>>> they > >>>>>>>>>>>> are > >>>>>>>>>>>>>>> done. > >>>>>>>>>>>>>>>>> Background: There are semantic differences for Resolve > >>>>>>> and > >>>>>>>>>> Close > >>>>>>>>>>>>>>>>> (implementor vs reporter considers it done), but I > >>>>>> don't > >>>>>>>> see > >>>>>>>>>> how > >>>>>>>>>>>>> they > >>>>>>>>>>>>>>>>> practically apply to the Flink project. Looking at the > >>>>>>>>>> numbers, > >>>>>>>>>>>>> Flink > >>>>>>>>>>>>>>> has > >>>>>>>>>>>>>>>>> 11066 closed tickets, and 3372 resolved tickets > >>>>>> (that's > >>>>>>>> why > >>>>>>>>> I > >>>>>>>>>>>>> propose > >>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>> close instead of resolve) > >>>>>>>>>>>>>>>>> *Labels:* > >>>>>>>>>>>>>>>>> "test-stability" for all test instabilities > >>>>>>>>>>>>>>>>> "starter" for tickets suitable for new contributors > >>>>>>>>>>>>>>>>> *Release Note:* > >>>>>>>>>>>>>>>>> Small notes that will be included into the release > >>>>>> notes > >>>>>>>>>>> published > >>>>>>>>>>>>>> with > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>> release. > >>>>>>>>>>>>>>>>> *All other fields are not used not used on a regular > >>>>>>>> basis.* > >>>>>>>>>>>>>>>>> Please +1 my proposal if you want it to be published > >>>>>> in > >>>>>>>> our > >>>>>>>>>> Wiki > >>>>>>>>>>>>> like > >>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>>> or let me know if I got something wrong here. > >>>>>>>>>>>>>>>>> Best, > >>>>>>>>>>>>>>>>> Robert > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Best, Jingsong Lee > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>> > >>>> > >>> > >> > >
