In here https://github.com/apache/iotdb-extras/pull/6
发件人: Christofer Dutz <christofer.d...@c-ware.de> 日期: 星期一, 2024年4月15日 21:01 收件人: dev@iotdb.apache.org <dev@iotdb.apache.org> 主题: AW: Splitting up the repos Well, as I said … I’ve already done the work of splitting things up (I had waited 5 days for any comments here) If we would now do it differently, I am sure someone would be able to re-do the split based on my work and then simply delete the double examples from the extras repo. So, I would be voting for moving all examples to the extras, you for splitting the examples, guess we need at least a third vote (with hopefully not a 3rd opinion ;-) ) Chris Von: Jialin Qiao <qiaojia...@apache.org> Datum: Montag, 15. April 2024 um 14:38 An: dev@iotdb.apache.org <dev@iotdb.apache.org> Betreff: Re: Splitting up the repos Hi, The examples could be classified into two parts (1) Connector example: flink, hadoop, kafka, pulsar, rabiitmq, rocketmq (2) IoTDB native api example: jdbc, mqtt, pipe, rest, schema, session, trigger, udf For (1), we could move into extra repo. For (2) , they should be retained in the IoTDB repo. Jialin Qiao Christofer Dutz <christofer.d...@c-ware.de> 于2024年4月15日周一 17:56写道： > > Hmpf, > > a little bit sooner reply would have been good … I’m already done with the > changes, also with moving all examples and the parts of the distribution > bundling the connectors. > > I do think also moving the examples is a good idea. Usually, examples pull in > all sorts of dependencies, which show up on vulnerability reports. Also do we > have some examples that refer to stuff we now moved out of the main repo, > we’d be getting a cyclic dependency from that, so we would have to split up > the examples in that case. > > So, if we were to vote on this (which we can) I would vote +1 on moving all > examples out of the main repo. > > Chris > > > Von: Jialin Qiao <qiaojia...@apache.org> > Datum: Montag, 15. April 2024 um 11:20 > An: dev@iotdb.apache.org <dev@iotdb.apache.org> > Betreff: Re: Splitting up the repos > Hi, > > 1. Which Parts: Only iotdb-connector need to be moved, distribution > and examples will impact the release and users. > 2. How to split up: I prefer【Simply ignore the history, copy the > files to the new repo and delete them from the old】. > > Jialin Qiao > > Christofer Dutz <christofer.d...@c-ware.de> 于2024年4月15日周一 16:27写道： > > > > Hi all, > > > > > > So, I’ve set a tag on the main repository “before-moving-extras” > > (https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fiotdb%2Freleases%2Ftag%2Fbefore-moving-extras&data=05%7C02%7C%7Ca2db3d8c049d429990f808dc5d4c29b1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638487828914066189%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Y2gAdl928x3zdjrZbpEUdYQgHc2EvUIO%2Bdht%2FaucMMY%3D&reserved=0<https://github.com/apache/iotdb/releases/tag/before-moving-extras>) > > > > Also have I copied the content of the examples and integration modules to > > the new repo, duplicated the build there and updated the versions to > > artifacts in the main repo to reference a variable. > > > > The build in the extras seems to work, now I’ll have to strip out > > configurations, dependency management etc. for stuff that’s not needed in > > the extras and do the same in the main repo. > > > > > > > > Chris > > > > > > > > Von: Christofer Dutz <christofer.d...@c-ware.de> > > Datum: Montag, 15. April 2024 um 09:22 > > An: dev@iotdb.apache.org <dev@iotdb.apache.org> > > Betreff: AW: Splitting up the repos > > Ok … > > > > So, no comment I will simply treat as lazy consensus, therefore I will move > > forward with tagging the main repo with the latest changes as last revision > > before the split and reference that in the commit to the new repo. > > Then I’ll simply copy over the files and delete them from the main repo. > > > > As with other projects however, I really dislike this form of workting > > together. Defaulting back to lazy consensus costs a lot of valuable time as > > I have to wait a reasonable amount of time. If I had gotten any “sure … I’m > > fine with you doing X” I could have long finished this. > > > > In the future it would be a lot better, if some people would actually reply. > > > > > > Chris > > > > > > > > Von: Christofer Dutz <christofer.d...@c-ware.de> > > Datum: Donnerstag, 11. April 2024 um 10:36 > > An: dev@iotdb.apache.org <dev@iotdb.apache.org> > > Betreff: Splitting up the repos > > Hi all, > > > > so now that the new repo is created > > (https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Fiotdb-extras.git&data=05%7C02%7C%7Ca2db3d8c049d429990f808dc5d4c29b1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638487828914074476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=SO2Jd9MAaza3jytG%2FAFLoQjWeCrX2%2F4MIHmId88cA9w%3D&reserved=0, > > but please don’t push anything there just yet), we would need to decide on > > which parts should be moved there. > > > > > > * “distribution”: Here I think we need to split the distribution. > > Keeping the distributions containing only core in the main repo and adding > > a new distribution module in the extras repo, that contains the downstream > > components. > > * “example” (which I would propose to rename to examples as it contains > > multiple) > > * “iotdb-connector” > > > > > > As it seems that in the integration-tests there are no tests testing the > > connectors, I guess we can leave that as it is. > > > > Now the problem is: There are multiple options to split up the repo and > > keeping the entire history. > > > > 1. Split out one directory in a separate branch and then merge all > > branches into an empty new one > > 2. Use the filter plugin to strip out all commits that match a regexp > > 3. Simply ignore the history, copy the files to the new repo and delete > > them from the old. > > > > 3 is the simples, but the person doing the move will be marked as author. > > In general this is not that problematic, as the integration modules and the > > examples are usually not that complex, but I would understand, if people > > wanted to keep the history. > > > > Option 1 is probably the most work, but the most robust option, as with > > option 2, I had to give up when doing the PLC4X split as there were bugs > > and issues in the tooling. > > > > So, if nobody objects and we’ve decided on what should be moved, I > > personally would opt for option 3. > > > > Chris
