So I know I’m replying to my own email but I figured I’d mention some patches. I’m trying to help out the project by suggesting backports and engaging with patch contributors.

You mentioned https://review.opendev.org/c/openstack/skyline-apiserver/+/957743 in your email and said you didn’t see a point to it but per the author and Jingwei’s comment its necessary for https://review.opendev.org/c/openstack/skyline-console/+/957801 I’ve given the author some review comments.

I’ve also gone ahead and applied another fix to https://review.opendev.org/c/openstack/skyline-apiserver/+/961595 so the skyline-apiserver will pass tests. On the skyline-apiserver side the release patches aren’t passing and I’m guessing they need this.

We should land the patches for the release:
- https://review.opendev.org/c/openstack/skyline-console/+/961168/
- https://review.opendev.org/c/openstack/skyline-console/+/961169
- https://review.opendev.org/c/openstack/skyline-console/+/961170

But I’m not sure if that’ll need https://review.opendev.org/c/openstack/skyline-console/+/961092 backported to it first.

Thanks.
—
Doug


On Sep 26, 2025, at 6:25 PM, Doug Goldstein <cardoe@cardoe.com> wrote:

So I’ll be honest, I’m only interested in this from an OpenStack Helm standpoint and the containers that are used there. Previously the OpenStack Helm PTL added Skyline to the repo but couldn’t get a container to build. He engaged the mailing list and submitted a patch but ultimately had to build a one off container which isn’t a situation I’d like to keep us in. What I would like is to be able to build the stable branches (2025.1, 2025.2) and master on a regular cadence and we cannot. I’ve asked around and folks have had problems building them regularly. I know there was a previous thread about adding maintainers and a few people replied so I’ve chased them down and they’ve said they have tried to get engaged but couldn’t. This last part is what’s caused me some alarm with my TC hat on and resulted in me starting the ML post.

I don’t want the TC to force any changes. I would very much like the project to operate and add maintainers that the core folks see fit. The current core members are absolutely going to be experts in the code base. So I want to figure out how we can help make the project more healthy. Something that I’ve brought up more than once in TC meetings are projects that say that they need contributors but then turn those contributors away. This is what’s currently happening with Skyline and that’s a concern to me. Sowmya’s organization has made a fork of Skyline cause of this, I’m okay naming them since they’re my employer as well and I’ve made a big stink about that part of the company needing to try harder to engage upstream. As for the other folks that I’ve spoken to since its been off-list I won’t name them unless they chose to name themselves.

So to summarize.

I want to have Skyline be a healthy project. To me that means:
  1) CI loop that should pass on stable and master
  2) regular releases from the core maintainers and not just a default release made by the release team due to a lack of a response
  3) engagement with contributors that submit patches, especially when they ask for feedback

If that means the core maintainers mentoring some new maintainers then that should be something that some effort is put into.

Thanks.
—
Doug


On Sep 26, 2025, at 8:53 AM, 吴文相 <wu.wenxiang@99cloud.net> wrote:

Hello, 

I'm glad the community has emails regarding Skyline.  

We can discuss and resolve issues based on facts:  

1. Contrary to what was mentioned in the previous email, it’s not true that there have been no non-core submissions or code reviews for Skyline since June 12th. For https://review.opendev.org/c/openstack/skyline-apiserver/+/957099, ZHAOWANGSHU submitted a patch and merged it on August 14th. For https://review.opendev.org/c/openstack/skyline-apiserver/+/957743 on September 23rd, I thought this patch was meaningless, so I gave a -1. There are indeed some issues with CI, but it’s not completely down. From June to August, I spent a lot of time converting the entire Skyline API server from asynchronous (async) mode to synchronous (sync) mode—this was to lower the barrier for participants and make the code easier to maintain. Earlier, from February to March, when DevStack was migrated to version 24.04, CI also had issues for a period of time, but we resolved them.  

2. The fact that the CI issue is being brought up this time is because more people are paying attention to it, which is a good thing. The Skyline core team has always been relatively small; only three of us—myself, Zhu Boxiang, and Zhang Jingwei—are still continuously conducting code reviews and contributing code. I only have about half a day per week to dedicate to open-source work, and the other two core members are in a similar situation. Therefore, we definitely hope to have new core members join us, and resolving this CI issue seems like a good opportunity.  

3. I have had some communications with Haoyang, and more frequent communications in the future will certainly be beneficial—especially those based on code reviews. Personally, I don’t particularly like meetings: first, due to time zone differences, and second, due to challenges in verbal expression. Emails allow things to be explained more clearly, and code reviews can describe specific issues in greater detail. Haoyang can also help us achieve smoother communication.  

4. Nowadays, large-model programming has greatly improved efficiency, which is a boon for open source. It reduces the time we spend troubleshooting issues and writing code, and lowers the cost of project maintenance. With new core members joining, I believe many things will improve.

Thanks

Best Regrads
Wu Wenxiang



Original:
On Thu, Sep 18, 2025 at 7:48 PM Doug Goldstein <cardoe@cardoe.com> wrote:
>
> Hello,
>
> It appears that skyline, both skyline-console and skyline-apiserver, have been broken from a test standpoint for a bit. Additionally the last patch from not one of the core members that has been merged was June 12th, which is also the last time a core member has commented on a patch not from the core members.
>
> There has been a recent uptick in contributors coming from another organization and I would like to help see their contributions land. Some of these are fixes so that the tests actually pass as well as fixes for other bugs and new features. There have also been requests for backports to 2025.1. What do we need to get this work to start landing and make sure this project stays healthy?
>
> fix for skyline-console tests: https://review.opendev.org/c/openstack/skyline-console/+/961092
> fix for one of the two failing skyline-apiserver tests: https://review.opendev.org/c/openstack/skyline-console/+/961092
> open skyline-apiserver changes: https://review.opendev.org/q/project:openstack/skyline-apiserver+status:open
> open skyline-console changes: https://review.opendev.org/q/project:openstack/skyline-console+status:open

Thank you for highlighting these patches. As we noted during numerous
discussions on #openstack-tc, the underlying concern here is that the
Skyline team is small, and apparently, they've had recent challenges
to deal with alongside project/community maintenance.

Besides that, over the past few years, the team hasn't grown despite
the growth in project usage. I want to take the opportunity to urge
the team to actively consider adding new core reviewers to help with
some of the bandwidth concerns. In another thread [1], we were looking
for volunteers that could help the team, and Skyline's PTL, Wu
Wenxiang, has stated that they'd welcome any new contributors—but we
have a chicken-and-egg problem where:

- New contributors will need to establish their knowledge of the
codebase and trust with the rest of the core team to be anointed as
core reviewers.
- The existing team doesn't seem to have the bandwidth or time to
engage and are mired with challenges (firewalls, language and time
zone barriers, little or no presence on OFTC's #openstack-skyline
channel, no PTG discussions, etc.).

I'd like to break this logjam. If these CI fixes can't be prioritized
by the team, it affects code delivery processes in OpenStack, and the
project is hostile towards new/interested contributors no matter the
well-meaning intentions of the current core team. We'll be discussing
this issue in the OpenStack TC's weekly meeting next week (Sept. 29th,
2025) [2]. I'm inviting the Skyline team to participate; if it's
harder to meet in sync, please feel free to respond to this thread
with your thoughts for resolution.


>
> Thanks.
> —
> Doug



[1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/4XBC547ICPFIQSM4MM5M5MVZLHJJQ3CR/#H6P4UKCJS52V66RNGLPZUTSBSY66FPCR
[2] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda