This page doesn't have any information. It shared the plan to do the hadoop->hadoop-ozone repository move.
As discussed on the mailing list:
Code Block |
---|
When Ozone was adopted as a new Hadoop subproject it was proposed[1] to be part of the source tree but with separated release cadence, mainly because it had the hadoop-trunk/SNAPSHOT as compile time dependency. During the last Ozone releases this dependency is removed to provide more stable releases. Instead of using the latest trunk/SNAPSHOT build from Hadoop, Ozone uses the latest stable Hadoop (3.2.0 as of now). As we have no more strict dependency between Hadoop trunk SNAPSHOT and Ozone trunk I propose to separate the two code base from each other with creating a new Hadoop git repository (apache/hadoop-ozone.git): With moving Ozone to a separated git repository: * It would be easier to contribute and understand the build (as of now we always need `-f pom.ozone.xml` as a Maven parameter) * It would be possible to adjust build process without breaking Hadoop/Ozone builds. * It would be possible to use different Readme/.asf.yaml/github template for the Hadoop Ozone and core Hadoop. (For example the current github template [2] has a link to the contribution guideline [3]. Ozone has an extended version [4] from this guideline with additional information.) * Testing would be more safe as it won't be possible to change core Hadoop and Hadoop Ozone in the same patch. * It would be easier to cut branches for Hadoop releases (based on the original consensus, Ozone should be removed from all the release branches after creating relase branches from trunk) |
Technical solution
There are two main methods to split repository:
...
As this is a new repository we don't need to follow the Hadoop "trunk" historical naming convention. We can go with the master which makes it easier to use it from external tools.
What should I do?
After the repository split you should use the new apache/hadoop-ozone repository.
...
To create pull requests, you should fork the new hadoop-ozone repository.
How can I migrate my work?
(1) cherry-pick always works even if the source and destination branches have different history. Just add the old and new remote to the same repository and cherry-pick between the branches.
...