Hi Neal, I see all your complains as valid points and, as discussed at IRC, here is the action plan I proposed to our development group, and agreed with our squad leads. Issues ===== We already had this in our radar since a couple of months, but we still need to come up with a plan and see what we can migrate and what we cannot (those that we cannot make public should be only a few, either because of security embargoes, or because there is private user from SUSE customers. So far, I will have a meeting to talk about this at week 7 (Feb 11 - Feb 15), and after that, we'll start the practical work. Sadly I can't tell when this will be ready, but I hope we will be able to provide more information after that meeting. RFC ==== I added a card to our retrospective to talk about this next Thursday. My proposal is making all future RFCs public and open to community discussion, and so community can be part of the decision as well, but we will need to check if there are some kind of legal restrictions (hopefully not) So rest assured, our target is open development, not only when it comes to the code and PRs, but also when talking about planes for the future, issues, etc. Regards. On miércoles, 30 de enero de 2019 6:04:18 (CET) Neal Gompa wrote:

Hey all,

So I've been following the development of Uyuni in parallel to the Spacewalk development for the past few months. I've been glad to see that both projects are showing a steady state of development, and Uyuni development is evenly paced.

However, there have been some (IMO) major disappointments in how the development process for Uyuni is going, which all seem to stem from a foundational issue: It is fundamentally impossible for me to figure out what is going on as you guys are developing and merging in code.

The main "symptoms" of this opaque development process:

* Pull requests are referencing issues that exist in a private repository (SUSE/spacewalk), which presumably is the SUSE Manager codebase. This means that many pull requests have no context for external (i.e. non-SUSE) contributors to review.

* Changes are being made with no obvious indicator of why they are happening, and the way the developers are committing to the codebase makes it impossible to divine any useful understanding. The style of just slamming out change after change with inscrutable commit messages really makes it hard to figure out what the meaningful change even is!

* To my surprise, there is apparently an RFC process for figuring out major decisions. Unfortunately, external contributors have no opportunity to weigh in and help with those decisions. This is because that process is completely private and not open for public discussion. This means that by the time external contributors can react, it's already been implemented and there's no time anymore, which means we're stuck with a potentially bad decision due to incomplete information.

Each of these things have happened during my time observing the Uyuni project. That said, it's not like Spacewalk is too much better, but we should aim for better no matter what!

This most recently was a problem for me because I had been slowly examining the effort required to run Uyuni on Fedora and CentOS and I kept getting broken by changes done before I had any time to react. The most recent one completely broke everything for me[1], and had I known they were trying to decide on an approach to solve that, I would have given them a better strategy that would have worked on CentOS/RHEL 7, Fedora, openSUSE Leap 15.0, and SUSE Linux Enterprise 15. However, I didn't know until it was literally about to be merged, which is a terrible way to find these things out. This change exhibits the characteristics of all the problems I described earlier, because the way changes were done means that reverting this and doing it right will be extraordinarily painful _for me_, and it shows some callousness for the community, because we have no opportunity to be part of the project.

Julio and Pablo (cc'd to this email) have already affirmed to me that they'll reconsider their approach so that this is unbroken. But this development process needs to change. It's too daunting for me to track and work with (and I'm pretty experienced at this stuff!). I worry that it's even scarier for people less versed in these kinds of projects.

I know that in a lot of projects, I wind up being the token "community guy". And I'm okay playing that role for a while, if I can help make a project become good enough that it can start attracting a community to sustain itself. I've done this for a number of projects over the years, and I'm okay with doing this. But I don't want to be only community person forever, and the only way that will improve is if the development process improves.

All the best, Neal

[1]: https://github.com/uyuni-project/uyuni/pull/527

-- 真実はいつも一つ！/ Always, there's only one truth!

Hi Neal, I see all your complains as valid points and, as discussed at IRC, here is the action plan I proposed to our development group, and agreed with our squad leads. Issues ===== We already had this in our radar since a couple of months, but we still need to come up with a plan and see what we can migrate and what we cannot (those that we cannot make public should be only a few, either because of security embargoes, or because there is private user from SUSE customers. So far, I will have a meeting to talk about this at week 7 (Feb 11 - Feb 15), and after that, we'll start the practical work. Sadly I can't tell when this will be ready, but I hope we will be able to provide more information after that meeting. RFC ==== I added a card to our retrospective to talk about this next Thursday. My proposal is making all future RFCs public and open to community discussion, and so community can be part of the decision as well, but we will need to check if there are some kind of legal restrictions (hopefully not) So rest assured, our target is open development, not only when it comes to the code and PRs, but also when talking about planes for the future, issues, etc. Regards. On miércoles, 30 de enero de 2019 6:04:18 (CET) Neal Gompa wrote:

Hey all,

So I've been following the development of Uyuni in parallel to the Spacewalk development for the past few months. I've been glad to see that both projects are showing a steady state of development, and Uyuni development is evenly paced.

However, there have been some (IMO) major disappointments in how the development process for Uyuni is going, which all seem to stem from a foundational issue: It is fundamentally impossible for me to figure out what is going on as you guys are developing and merging in code.

The main "symptoms" of this opaque development process:

* Pull requests are referencing issues that exist in a private repository (SUSE/spacewalk), which presumably is the SUSE Manager codebase. This means that many pull requests have no context for external (i.e. non-SUSE) contributors to review.

* Changes are being made with no obvious indicator of why they are happening, and the way the developers are committing to the codebase makes it impossible to divine any useful understanding. The style of just slamming out change after change with inscrutable commit messages really makes it hard to figure out what the meaningful change even is!

* To my surprise, there is apparently an RFC process for figuring out major decisions. Unfortunately, external contributors have no opportunity to weigh in and help with those decisions. This is because that process is completely private and not open for public discussion. This means that by the time external contributors can react, it's already been implemented and there's no time anymore, which means we're stuck with a potentially bad decision due to incomplete information.

Each of these things have happened during my time observing the Uyuni project. That said, it's not like Spacewalk is too much better, but we should aim for better no matter what!

This most recently was a problem for me because I had been slowly examining the effort required to run Uyuni on Fedora and CentOS and I kept getting broken by changes done before I had any time to react. The most recent one completely broke everything for me[1], and had I known they were trying to decide on an approach to solve that, I would have given them a better strategy that would have worked on CentOS/RHEL 7, Fedora, openSUSE Leap 15.0, and SUSE Linux Enterprise 15. However, I didn't know until it was literally about to be merged, which is a terrible way to find these things out. This change exhibits the characteristics of all the problems I described earlier, because the way changes were done means that reverting this and doing it right will be extraordinarily painful _for me_, and it shows some callousness for the community, because we have no opportunity to be part of the project.

Julio and Pablo (cc'd to this email) have already affirmed to me that they'll reconsider their approach so that this is unbroken. But this development process needs to change. It's too daunting for me to track and work with (and I'm pretty experienced at this stuff!). I worry that it's even scarier for people less versed in these kinds of projects.

I know that in a lot of projects, I wind up being the token "community guy". And I'm okay playing that role for a while, if I can help make a project become good enough that it can start attracting a community to sustain itself. I've done this for a number of projects over the years, and I'm okay with doing this. But I don't want to be only community person forever, and the only way that will improve is if the development process improves.

All the best, Neal

[1]: https://github.com/uyuni-project/uyuni/pull/527

-- 真実はいつも一つ！/ Always, there's only one truth!