[jira] [Closed] (IOTDB-145) [IoTDB-Grafana]Please update readme.md and readme_zh.md in incubator-iotdb/grafana/
[ https://issues.apache.org/jira/browse/IOTDB-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] FengQingxin closed IOTDB-145. - Fix Version/s: 0.9.0-SNAPSHOT Resolution: Fixed > [IoTDB-Grafana]Please update readme.md and readme_zh.md in > incubator-iotdb/grafana/ > --- > > Key: IOTDB-145 > URL: https://issues.apache.org/jira/browse/IOTDB-145 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: FengQingxin >Priority: Major > Labels: pull-request-available > Fix For: 0.9.0-SNAPSHOT > > Attachments: image-2019-07-18-18-53-20-782.png > > Time Spent: 20m > Remaining Estimate: 0h > > [IoTDB-Grafana]Please update readme.md and readme_zh.md in > incubator-iotdb/grafana/; > There are some links are point to github.con/thulab > > !image-2019-07-18-18-53-20-782.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-91) Improve tsfile-spark-connector to support spark 2.2.0
[ https://issues.apache.org/jira/browse/IOTDB-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xiangdong Huang closed IOTDB-91. > Improve tsfile-spark-connector to support spark 2.2.0 > -- > > Key: IOTDB-91 > URL: https://issues.apache.org/jira/browse/IOTDB-91 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Yang Yawen >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Current tsfile-spark-connector project only supports spark version 2.0.1, > while Ts-Flok project uses spark-version 2.2.0 to run operators. Therefore, > Ts-Flok project can't use it to read or write tsfile format as intermediate > results. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-65) Merge TsFileGeneratorForTest.java and IncompleteFileTestUtil.java
[ https://issues.apache.org/jira/browse/IOTDB-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xiangdong Huang closed IOTDB-65. Resolution: Fixed > Merge TsFileGeneratorForTest.java and IncompleteFileTestUtil.java > -- > > Key: IOTDB-65 > URL: https://issues.apache.org/jira/browse/IOTDB-65 > Project: Apache IoTDB > Issue Type: Task >Reporter: xiangdong Huang >Priority: Minor > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > [tsfile/src/test/java/org/apache/iotdb/tsfile/utils/TsFileGeneratorForTest.java|https://github.com/apache/incubator-iotdb/pull/100/files/fb55aa66c2f4aef315ab7a2c977709152fa46432#diff-fea07ebec93c90546dec1eafcaaebc2f] > and > tsfile/src/main/java/org/apache/iotdb/tsfile/write/writer/IncompleteFileTestUtil.java > have the same purpose. > We can merge them together to let codes more graceful -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-140) TsFile write interface does not support string with Unicode characters
[
https://issues.apache.org/jira/browse/IOTDB-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xiangdong Huang closed IOTDB-140.
-
> TsFile write interface does not support string with Unicode characters
> --
>
> Key: IOTDB-140
> URL: https://issues.apache.org/jira/browse/IOTDB-140
> Project: Apache IoTDB
> Issue Type: Bug
>Reporter: Zihan Meng
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If we add a measurement with Chinese name the write module will fail and
> throw this exception:
>
> {code:java}
> java.io.IOException: Flushed data size is inconsistent with computation!
> Estimated: 120, Actual: 128
> at
> org.apache.iotdb.tsfile.write.TsFileWriter.flushAllChunkGroups(TsFileWriter.java:273)
> at org.apache.iotdb.tsfile.write.TsFileWriter.close(TsFileWriter.java:298)
> at Chinese.writeData(Chinese.java:35)
> at Chinese.tsFileWriteDirect(Chinese.java:53)
> at Chinese.main(Chinese.java:59){code}
>
> This exception may be because when writing a string, the writer will write
> the length of a string first to indicate the reader to read. However, in
> UTF-8 encoding, the length of a string may not equal to the length in
> corresponding byte array. Debugging is in progress.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IOTDB-159) NullPointerException in SeqTsFileRecoverTest.java and UnseqTsFileRecoverTest
[
https://issues.apache.org/jira/browse/IOTDB-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xiangdong Huang closed IOTDB-159.
-
Resolution: Cannot Reproduce
If someone occurs the same issue, please reopen it.
> NullPointerException in SeqTsFileRecoverTest.java and UnseqTsFileRecoverTest
>
>
> Key: IOTDB-159
> URL: https://issues.apache.org/jira/browse/IOTDB-159
> Project: Apache IoTDB
> Issue Type: Bug
>Reporter: xiangdong Huang
>Priority: Major
> Attachments: image-2019-08-13-08-49-11-242.png
>
>
> see
> [https://builds.apache.org/job/IoTDB-Pipeline/job/master/154/]
>
> h3. Stacktrace
> java.lang.NullPointerException at
> org.apache.iotdb.db.writelog.recover.UnseqTsFileRecoverTest.test(UnseqTsFileRecoverTest.java:130)
> h3. Standard Output
> INFO [2019-08-12 23:42:02,269] [main]
> org.apache.iotdb.db.writelog.node.ExclusiveWriteLogNode:74 - create the WAL
> folder {}.data/wal/testNodetest.ts INFO [2019-08-12 23:42:02,605] [main]
> org.apache.iotdb.tsfile.read.TsFileSequenceReader:608 - TsFile self-check
> cannot proceed at position 20952 after 10 chunk groups recovered, because :
> reach the end of the file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IOTDB-35) flush error message
[ https://issues.apache.org/jira/browse/IOTDB-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xiangdong Huang closed IOTDB-35. Resolution: Cannot Reproduce If someone occurs the same problem, please reopen it. > flush error message > --- > > Key: IOTDB-35 > URL: https://issues.apache.org/jira/browse/IOTDB-35 > Project: Apache IoTDB > Issue Type: Bug >Reporter: Yongmin,Cheng >Assignee: Tian Jiang >Priority: Major > Attachments: server_log.txt > > > 1. reset value of period_time_for_flush_in_second vim iotdb-engine.properties > period_time_for_flush_in_second=120 > 2. restart IoTDB server > 3. commands of cli > SET STORAGE GROUP TO root.ln.wf01.wt06 > CREATE TIMESERIES root.ln.wf01.wt06.status WITH DATATYPE=BOOLEAN, > ENCODING=PLAIN > INSERT INTO root.ln.wf01.wt06(timestamp,status) values(150946560,true) > select status from root.ln.wf01.wt06 > INSERT INTO root.ln.wf01.wt06(timestamp,status) values(NOW(),true) > IoTDB> flush > Msg: org.apache.iotdb.db.exception.FileNodeManagerException: > org.apache.iotdb.db.exception.FileNodeProcessorException: Stream Closed > > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-77) test ticket
[ https://issues.apache.org/jira/browse/IOTDB-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xiangdong Huang closed IOTDB-77. Resolution: Not A Bug > test ticket > --- > > Key: IOTDB-77 > URL: https://issues.apache.org/jira/browse/IOTDB-77 > Project: Apache IoTDB > Issue Type: Bug >Reporter: Drew Foulks >Priority: Trivial > > test ticket -- This message was sent by Atlassian Jira (v8.3.4#803005)
Close the issues that have been solved on JIRA
Hi, Tianjiang help me to review the issue list to check which issues are solved. I will close some of them, and please close others if you are the assignees or who solved them. The list: [Not a Bug] https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-77?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-35?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-159?filter=allopenissues (I will close the above issues.) [Solved] https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-137?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-136?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-140?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-65?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-91?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-135?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-139?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-104?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-147?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-148?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-161?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-182?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-57?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-242?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-174?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-236?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-88?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-226?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-42?filter=allopenissues (I will close the above issues.) https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-92?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-98?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-13?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-180?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-191?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-188?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-117?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-116?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-23?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-145?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-195?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-209?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-224?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-241?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-235?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-206?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-234?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-240?filter=allopenissues https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-114?filter=allopenissues Best, --- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院
[jira] [Closed] (IOTDB-13) Support batched ingestion
[ https://issues.apache.org/jira/browse/IOTDB-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tian Jiang closed IOTDB-13. --- > Support batched ingestion > - > > Key: IOTDB-13 > URL: https://issues.apache.org/jira/browse/IOTDB-13 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Tian Jiang >Assignee: Yanzhe An >Priority: Minor > Labels: pull-request-available > Fix For: 0.8.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Our current insertion interface is based on building one TsRecord for a > timestamp. This limits our capability when ingestion a large amount of > pre-generated data. > We need specifically designed batch load interface to improve our performance > when loading, say, historical data. For example, the size checks of multiple > PageWriters can be reduced to one in a batched fashion. Moreover, when the > schema of the data is static, we can use primitive arrays instead of Lists > which may incur the performance greatly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-191) Enrich Session interfaces
[ https://issues.apache.org/jira/browse/IOTDB-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-191. - Fix Version/s: 0.9.0 Resolution: Fixed > Enrich Session interfaces > - > > Key: IOTDB-191 > URL: https://issues.apache.org/jira/browse/IOTDB-191 > Project: Apache IoTDB > Issue Type: New Feature >Reporter: Jialin Qiao >Priority: Minor > Labels: pull-request-available > Fix For: 0.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The module "Session" is an RPC interface for users, which is more efficient > than JDBC. > Currently, it only has 3 interfaces: (1) ser storage group (2) create time > series (3) insert batch. > Other interfaces such as delete time series, the query could be added. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-180) Get rid of JSON format in "show timeseries"
[ https://issues.apache.org/jira/browse/IOTDB-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-180. - Fix Version/s: 0.9.0 Resolution: Fixed > Get rid of JSON format in "show timeseries" > --- > > Key: IOTDB-180 > URL: https://issues.apache.org/jira/browse/IOTDB-180 > Project: Apache IoTDB > Issue Type: Wish >Reporter: Jialin Qiao >Priority: Minor > Labels: pull-request-available > Fix For: 0.9.0 > > Attachments: image-2019-08-27-09-56-20-654.png, > image-2019-08-27-09-56-28-577.png > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, "show timeseries" prints result in JSON format, which is not > friendly compared to "show timeseries root" in table format. > !image-2019-08-27-09-56-20-654.png|width=463,height=538! > !image-2019-08-27-09-56-28-577.png|width=694,height=458! > Intuitively, I would expect that "show timeseries" works as "show timeseries > root". > Therefore, when users input a "show timeseries", I suggest that we treat it > as "show timeseries root" and print results in table format. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-98) Batch insertion in Server
[ https://issues.apache.org/jira/browse/IOTDB-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-98. Resolution: Done > Batch insertion in Server > - > > Key: IOTDB-98 > URL: https://issues.apache.org/jira/browse/IOTDB-98 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Jialin Qiao >Priority: Minor > > Currently, when the client sends a batch of statements (insert/delete) to the > server, the server will get each statement from the batch and execute one by > one. For each statement, the corresponding FileNodeProcessor (for a storage > group) will get a write lock and then execute the statement, which causes > unnecessary lock contention. > It can be improved by getting a write lock once and executing a batch of > statements. We can first consider the scenario that the statements in a batch > are all insertions. > The new process mainly contains 3 steps: > (1) Group the insert statement by storage group while retaining the original > order in the batch. > (2) For each storage group, get the write lock and execute all statements > belong to it. > (3) Set the return code of each statement to the origin position in the batch. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [discussion] Release of IoTDB 0.8.1 RC2
Hi, > (Learnt from Julian: if we can get 3 votes from IPMCs, e.g., from our > mentors, then it will be an easy task to get votes from general@ mail list) > > (The holiday of National Day of China is over, so Chinese guys, PPMC > especially, it is your time. :D I’d like the see a few PPMC votes on this before the mentors, once you become a top level project you won’t have mentors so need to learn how to do this and what to look for yourselves. Thanks, Justin
[jira] [Closed] (IOTDB-143) Support merge
[ https://issues.apache.org/jira/browse/IOTDB-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tian Jiang closed IOTDB-143. > Support merge > - > > Key: IOTDB-143 > URL: https://issues.apache.org/jira/browse/IOTDB-143 > Project: Apache IoTDB > Issue Type: New Feature >Reporter: Tian Jiang >Priority: Major > Labels: pull-request-available > Fix For: 0.8.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Merge (or compaction) is an important feature of LSM or LSM-like systems and > IoTDB depends on it to put the data in the sequential files and unsequential > files together and make them ordered and non-duplicated again. > Merged data files provide better locality and potentially higher compression > rate (for some of the missing values are supplemented). While merging > interacts with many aspects of IoTDB like ingestion and query, finding an > effective implementation may be rather difficult. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[discussion] Release of IoTDB 0.8.1 RC2
Hi all, Please pay attention to the vote for release of IoTDB 0.8.1 RC2. (Learnt from Julian: if we can get 3 votes from IPMCs, e.g., from our mentors, then it will be an easy task to get votes from general@ mail list) (The holiday of National Day of China is over, so Chinese guys, PPMC especially, it is your time. :D) Best, --- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院
[jira] [Closed] (IOTDB-160) External sort in non-sequential data
[ https://issues.apache.org/jira/browse/IOTDB-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] suyue closed IOTDB-160. --- > External sort in non-sequential data > > > Key: IOTDB-160 > URL: https://issues.apache.org/jira/browse/IOTDB-160 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: suyue >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > For the query of non-sequential data, each chunk is constructed separately as > reader, then merged and sorted. When non-sequential data is large, so the > number of chunks of merge is too large, it may cause the problem of > exhausting memory. So when the number of chunks merged at the same time > reaches a certain limit, the external method is adopted. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-247) Need to improve the function of dynamic parameter
FengQingxin created IOTDB-247: - Summary: Need to improve the function of dynamic parameter Key: IOTDB-247 URL: https://issues.apache.org/jira/browse/IOTDB-247 Project: Apache IoTDB Issue Type: Improvement Reporter: FengQingxin Attachments: image-2019-10-08-09-19-41-442.png When I using iotdb to simulate the status of Shanghai Subway,I got below results: IoTBD config: MAX_HEAP_SIZE="100G" enable_parameter_adapter=true Server config: Core num: 24 ; Mem Size: 128G |车量数|100列车|200列车|300列车| |变量数|写入延时（ms）| |3200|39.24|36.52|23.85| |4000|68.41|48.71|30.26| |6000|136.6|91.18|54.62| |8000|184.1|153.2|75.43| !image-2019-10-08-09-19-41-442.png! In my opinion the result of 100 trains should be less than 200&300 trains. So I think we need to improve the function of dynamic parameter. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: How about a summary of what you're all up to?
Hi, > overall my impression is that its getting better. +1 to that and both what Julian and Chris have said. I think the next step is a little more transparency on how how people decided on what issues to work on. Thanks, Justin
Re: How about a summary of what you're all up to?
Hi, overall my impression is that its getting better. Initially it was way calmer here but now there are discussion threads or announcements about features from time to time. So I totally agree with chris but I also think there is already a learning curve. So keep it going guys : ) Julian Am 06.10.19, 15:22 schrieb "Xiangdong Huang" : Hi, +1 for more discussions, rather than just opening issues, working on them and closing them. Indeed, there are some discussions for some issues, but we can do more about that. If the issue is for a new feature, we can show the main idea about how to implement it on the mailing list. I summarize some new features/improvements we have solved or addressed in September according to the mailing list, and github as following with 3 columns: Feature/imporvement description. status. Is there some discussions? (The statistics may be not accurate. Some of the issues have been solved but the status of the issues are not changed. Some discussions are on github but I do not review the contents of related PRs.) - Improvement for LRUCache. Not solved. no discussion. - Reimplementation sync module. not solved. no discussion. - improving spark-tsfile query for narrow table view. not solved. no discussion. - Spark-IoTDB connector. not solved. no discussion. - maintain hadoop-tsfile module. not solved. no discussion (but the contributor pointed out his main idea). - load configuration file on-site. not solved. no discussion. - connect IoTDB with python or C. not solved. no discussion but there are some replies for that. - use hive to query Tsfile data. solved. no discussion. - switch Antlr3 to antlr4. Not solved. Some discussions (finally, the performance using antlr4 is worse?). - enrich session interfaces (using API rather than SQL to operate data) Not solved. Some discussions. - support saving data file into HDFS directly. Solved. Some discussions. - make the result format of metadata query like "show timeseries" consistent. solved. no discussion but the contributor keeps updating his progress on the mailing list. - Create metadata automatically in the insertion. not solved. Some discussions. - A simple tool to visualize logs. not solved. Some discussions. - A new result set format. not solved. no discussion. Some discussions. - Add bloom filters to TsFile. not solved. Some discussions. - support retention policy (remove stale data automatically). not solved. few discussion. - Convert Path(String) to ID(Long). not solved. few discussions. - support connection pool (e.g., Ali druid). not solved. few discussion. - TsFile skeleton viewer tool. solved. few discussion. - support External sort for non-sequential data. solved. some discussions on github. After reviewing these "discussions", I find that there are few mails for discussing the idea of how to implement new features.. which I think is the same important with why the feature is needed or how to define the feature. In my personal opinion, in the next 3 month (and then 2019 is over...), I think there are two important features, distributed version and relational model view. Best, --- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院 Christofer Dutz 于2019年10月5日周六 下午11:24写道： > Hi Xiangdong, > > well a Maven release usually does exactly 2 commits. > But it's something I noticed quite often. Two digit number of commits, 1-2 > emails on dev. > So everyone is working hard on all sorts of stuff, but I see absolutely no > coordination here. > Is everything just people open Issues, and then people start working on > these? > Usually I would sort of expect some discussions about things. > > Chris > > Am 05.10.19, 17:12 schrieb "Xiangdong Huang" : > > Hi, > > if the mails are sent today, I think most of them are because I am > running > ‘mvn release:prepare’ and ‘mvn release:rollback’, others are for fixing > issues in RC1. All of them are on the rep/0.8 branch. > > Best, > > Christofer Dutz 于2019年10月5日 周六下午8:48写道： > > > Hi all, > > > > Again I noticed my Mail client showed me the usual picture … a 2 > digit > > number of emails in the commit list, and 1 in the dev list. > > Would be cool if you could sum up what the team is currently working > on. > > > > Are there any new names on the contributor side? You haven’t voted in > > anyone for quite some time > > > > Chris > > > -- > --- > Xiangdong Huang > School of Soft
