Track TODOs for graduation

[wu-sheng]

Hi OpenDAL community

I am glad to see that the status of the OpenDAL community keeps improving, and moving forward the graduation.
Here is a keep-update TODO list to track for the OpenDAL, to document what is noticed and should be fixed before graduation.

• graduation: Set up the boundaries for the release #3317
• graduation: Finalize the project management culture #3318
• graduation: Versionize the documents for every SDKs #3319
• Ensure suitable names for project name and product names #3614
• Dependencies evaluation for all existing codebases. Various SDK makes mentors(further IPMC) a little hard to get the dependency list, with licenses. #3615
• Website status check. Ref Apache Podling Website Checks.
• Go through Apache Project Maturity Model and evaluate our status. #3677
• Summarize our released versions and release managers with their specific languages. We should build a diverse and health management committee as a resolution for the TLP PMC. #3462
• Summarize the events, public speaking, collaborations with other projects/teams, and users. All of those are not to build a fancy user wall or numbers for the market. But it indicates the project is ready for stability and being used. #3613
• Go through Apache OpenDAL Project Incubation Status, and finish all TODO items.
• Have an agreement on the members of the PMC. #3616

Reference

• The Graduation Process

[Xuanwo]

Website status check.

[tisonkun]

Update reference - https://incubator.apache.org/guides/graduation.html

[tisonkun]

Podling metadata is updated at - https://svn.apache.org/repos/asf/incubator/public/trunk/content/podlings/opendal.yml

Name search should be done as stated in #3614. @Xuanwo would you open an issue at the referred JIRA project? It should be intuitive with the example linked in #3614.

[tisonkun]

Project status is updated at - https://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/opendal.xml

You can check the rendered version - https://incubator.apache.org/projects/opendal.html

The file should be kept updated during our new releases and new committers.

[wu-sheng]

#3677

Question, I am not sure whether this is suitable for the website. The link should be permanent. But from the place on your website, I doubt it is meaningful after graduation.

[wu-sheng]

#3615

It is good to see the dependencies. Meanwhile, the project team should have a mechanism to manage these dependencies rather than a one-time evaluation for graduation only.
Your dependencies(including languages) could change with time. It could be CI driven or manually or both, but those LICENSEs of dependencies are expected to exist when you release and are expected to update in time always.

[wu-sheng]

About #3317, from the website, it is still unclear. What I was proposing is, that this helps for the community, rather than fit my own or foundation requirements only.
You put them as a top-level menu, and there is also documentation and codebases to show how to use them. How the end users will know these are actually not usable? No official release?
Personally, if that is never released, it doesn't exist from ASF perspective. If you have dev doc, it may be reasonable.

[tisonkun]

Your dependencies(including languages) could change with time. It could be CI driven or manually or both, but those LICENSEs of dependencies are expected to exist when you release and are expected to update in time always.

For dependencies, IIUC only runtime deps are counted? If so, we can use cargo deny to generate the major deps and as stated in the issue, most of bindings doesn't have extra runtime deps so manually maintain the deps (most are N/A so we can omit) should be enough.

[tisonkun]

Question, I am not sure whether this is suitable for the website. The link should be permanent. But from the place on your website, I doubt it is meaningful after graduation.

It's something like a Wiki to document a status at the time. I agree that it doesn't have to be on the website, but it's OK to be on the website also IMO.

BTW, I linked to https://github.com/apache/kvrocks-website/blob/main/maturity.md in the issue but actually the text is simply place there, which doesn't show on the website ;-)

[wu-sheng]

Your dependencies(including languages) could change with time. It could be CI driven or manually or both, but those LICENSEs of dependencies are expected to exist when you release and are expected to update in time always.

For dependencies, IIUC only runtime deps are counted? If so, we can use cargo deny to generate the major deps and as stated in the issue, most of bindings doesn't have extra runtime deps so manually maintain the deps (most are N/A so we can omit) should be enough.

Anyway, the project wants, it works. I just highlight this to help the community understands that, this is an important and long-term action item for the community, rather than one time work for the graduation.

[wu-sheng]

It's something like a Wiki to document a status at the time. I agree that it doesn't have to be on the website, but it's OK to be on the website also IMO.

Yes, it is OK to be there, but once the graduation is done, and being done for years, are we still OK to post this? I don't want a deadline with time.

[Xuanwo]

Yes, it is OK to be there, but once the graduation is done, and being done for years, are we still OK to post this? I don't want a deadline with time.

@suyanhanx previously stored it in a GitHub repository, but I recommended making it visible at opendal.apache.org. Does anyone have other suggestions for where to host this document?