+1 for Only iotdb-connector need to be moved 发件人: Jialin Qiao <qiaojia...@apache.org> 日期: 星期一, 2024年4月15日 17:20 收件人: dev@iotdb.apache.org <dev@iotdb.apache.org> 主题: 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%7Caca8308b666943558e9808dc5d2d4199%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638487696171565100%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=jGQ3969ei%2BQ5f5UhFAnl%2FyNEg%2BJXWvspE61lIkM74Wc%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%7Caca8308b666943558e9808dc5d2d4199%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638487696171574238%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=E1yJGlM6QYgOj5YRVXaBBqsWq4U3KwYAOXExhRrzKic%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
