Re: [DISCUSS] Creating a Wiki for Cloudberry?

2025-04-03 Thread Jianghua Yang
+1 , like pytorch community https://github.com/pytorch/pytorch/wiki Dianjin Wang 于2025年4月3日周四 17:46写道: > +1 GitHub Wiki. > > On Thursday, April 3, 2025, Ed Espino wrote: > > > Hi Dianjing and Cloudberry community, > > > > Thanks for initiating this discussion—organizing our collective knowledge

Re: Interest in Incorporating Apache MADlib into Apache Cloudberry (Incubating)?

2025-04-03 Thread Sharma, Abhishek
I strongly recommend including madlib, I find it very useful and convenient. Best regards Abhishek From: Tushar Pednekar Sent: Thursday, April 3, 2025 7:13:16 AM To: dev@cloudberry.apache.org Cc: Roman Shaposhnik Subject: Re: Interest in Incorporating Apache M

Re: [DISCUSS] Creating a Wiki for Cloudberry?

2025-04-03 Thread Dianjin Wang
+1 GitHub Wiki. On Thursday, April 3, 2025, Ed Espino wrote: > Hi Dianjing and Cloudberry community, > > Thanks for initiating this discussion—organizing our collective knowledge > more effectively is a great idea. > > I’d like to voice my support for *Option 1: GitHub Wiki*. > >- > >*Ma

[DISCUSS] Creating a Wiki for Cloudberry?

2025-04-03 Thread Dianjin Wang
Hi all, I'd like to start a discussion on whether we should create a Wiki for Cloudberry. Currently, we have some scattered or informal knowledge, such as feature design documents, marketing events, proposals, and more, that need a flexible place for organization. Managing these directly on the w

Re: Interest in Incorporating Apache MADlib into Apache Cloudberry (Incubating)?

2025-04-03 Thread Tushar Pednekar
Ed - IM(biased)O 😊 Wjat you propose seems appropriate - there are too many people who rely on MADlib, mostly within existing Greenplum user base who would appreciate any effort this community makes towards ease of life for the users. So, I would +1 for sure. Regards, Tushar _

Re: [DISCUSS] Creating a Wiki for Cloudberry?

2025-04-03 Thread Ed Espino
Hi Dianjing and Cloudberry community, Thanks for initiating this discussion—organizing our collective knowledge more effectively is a great idea. I’d like to voice my support for *Option 1: GitHub Wiki*. - *Markdown-native*: GitHub Wiki uses Markdown, which is the de facto standard for