Hi! Sounds great, it is the new experience for us, let's walk this path )
We always have the option to manually transfer commits, but why do it manually when we have a well-established working mechanism? On Fri, Jun 26, 2026 at 12:39 PM Dianjin Wang <[email protected]> wrote: > Hi everyone, > > Following up on our previous discussion about introducing a Command > Center for Apache Cloudberry, and as briefly discussed during our > Cloudberry Bi-weekly Community Meeting this Friday, I'd like to > continue the discussion on the process for bringing the existing > implementation into the Apache Cloudberry project. > > The Yandex Cloud team has expressed interest in donating its existing > Command Center implementation to Apache Cloudberry: > > https://github.com/open-gpdb/yagpcc > > From the previous discussion, it seems there is positive community > interest in having such a project under Apache Cloudberry. The next > question is what the appropriate ASF process would be for accepting an > existing external codebase. > > Based on my reading of the Apache Incubator IP Clearance documentation > [1], importing a substantial codebase that has been developed outside > ASF generally goes through the IP Clearance process before it is > incorporated into an Apache project. > > My current understanding of the overall process is roughly: > > 1. Cloudberry Community VOTE to accept the contribution. > 2. Determine the appropriate copyright grant mechanism (Software > Grant, CCLA, or another ASF-approved approach, depending on copyright > ownership). > 3. Prepare the required IP Clearance documentation. > 4. Submit the IP Clearance request for IPMC review. > 5. After the IP Clearance process is completed, import the repository > into the Apache organization. > > Since this would be our first experience handling an external > repository donation of this scale, I'd especially appreciate feedback > from our mentors and others who have gone through the ASF IP Clearance > process. > > Once we have an agreement on the process, we can coordinate with the > Yandex Cloud team to prepare the required materials and proceed > accordingly. > > I also did some research, we can take this `Donate Apache Arrow > Erlang` case as a reference: > - DISCUSSION on donating: > https://lists.apache.org/thread/pwpm5b4v1jgosxn0hd5jtz10obfxs374 (just > as this mailing thread) > - Community VOTE: > https://lists.apache.org/thread/zgs5wfjwkb9b7xs8423561zy25nvvrm5 > - IP Clearance page: > https://incubator.apache.org/ip-clearance/arrow-erlang-library > - Incubator IPMC Review: > https://lists.apache.org/thread/6787p8mx95krvo689v7zfgj9pyxnp5r7 > - Result of IPMC Review: > https://lists.apache.org/thread/dov6drm72b905tj5gt6dj711cpl5ff7s > - Transfer the repo to ASF org: > https://issues.apache.org/jira/browse/INFRA-27965 > > Thanks! > > [1] https://incubator.apache.org/ip-clearance/ > > > Best, > Dianjin Wang > > On Mon, May 25, 2026 at 10:50 AM Zhang Mingli <[email protected]> > wrote: > > > > > > > > On 2026/05/19 14:33:27 Leonid Borchuk wrote: > > > Hi, developers! > > > > > > I'd like to talk about the command center. ) > > > > > > I know it's a paid feature for historical reasons. Here in Russia, I > might > > > count about 4 different command centers: one for sale and others for > > > internal purposes only. All of them are good at something, but they > have > > > one significant drawback in common: they are closed-source. > > > > > > We had a discussion > https://github.com/apache/cloudberry/discussions/1046 . > > > > > > I want to move forward and propose an open-source command center. Right > > > now, it's worse than all the commercial counterparts. But as we have > seen > > > many times before, all of them will eventually become obsolete, and > only > > > open-source compatible solutions will remain. > > > > > > What I have: > > > 1. A special extension to send query data from CloudBerry to an > external > > > agent > > > > https://github.com/apache/cloudberry/tree/main/gpcontrib/gp_stats_collector > > > 2. A service to gather and aggregate data > > > https://github.com/open-gpdb/yagpcc > > > > > > It has various interfaces - grpc/csv/json. And a generated UI (using > LLM, I > > > do not understand how it works but it works). Times have changed and we > > > could easily generate other features like pg_dash has > > > https://github.com/avamingli/pg_dash > > > > > > What I would like to do: > > > 1. Create new cloudberry ecosystem repository > > > https://github.com/apache/cloudberry-command-center (need help with > how to > > > do this ) ) > > > 2. Rename and move https://github.com/open-gpdb/yagpcc to > > > https://github.com/apache/cloudberry-command-center > > > 3. Seize power Declare it as a new open source command center and > encourage > > > all those interested in developing the functionality to join and make > > > contributions. > > > > > > I would like to hear your thoughts on my initiative. Will it interfere > with > > > other plans? Perhaps there is a better candidate. Perhaps the solution > > > should be significantly improved and only then called a command center. > > > > > > Looking forward to your thoughts. > > > > > > WBW, Leonid > > > > > > > Hi, > > > > +1 from me — really glad to see someone stepping up to drive this. A > command center / monitoring solution would be genuinely convenient for > users, and an open-source one is something the community has been needing > for a while. > > > > You're right that in the AI era, generating both frontend and backend > has become remarkably accessible — even within a day, as pg_dash nicely > demonstrates. That said, not every user has access to AI tooling, and many > would simply prefer a ready-to-use solution over building their own from > scratch. In that sense, having a unified interface is valuable for both > developers and end users. > > > > It doesn't need to be perfect from day one — what matters is that > something exists as a starting point the community can rally around and > improve together over time. Happy to help where I can. > > > > Best regards, > > Zhang Mingli > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
