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://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://gitbox.apache.org/repos/asf/iotdb-extras.git, 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
