Request @jcastill to be a maintainer

[pmoravec]

Hello,
I would like to propose Jose Castillo (@jcastill) as a maintainer. We have touched on this in the past and the arguments are even stronger since then.

At the moment, no maintainer works on sos on a full time basis, so things obviously don’t go as quickly as they could go because other maintainers have other priorities. Having more maintainers can speed-up things.

Proven work in upstream, Jose has many PRs, he is replying to issues and finding and fixing new bugs. He is quite active and responsive.

He is already doing reviews upstream and helping maintainers, but cannot merge and his reviews don’t normally count for the 2-ACK system for non-maintainers.

A partial reason is also to standby / loadbalance myself, so we can deputize each other if either is not available to work in upstream. From a business continuity stand point it makes sense that there be more than one Red Hatter who is a sos maintainer.

[arif-ali]

I would be more than happy with this, and discussed this with Jose privately a few months ago.

We have 4 active people on the repo and Jose one being a non-maintainer, and it makes sense in my opinion for Jose to be there.

So, based on the work we have done here and the collaboration, and his contributions thus far, I would be happy to endorse that.

[TurboTurtle]

sos is not looking for additional maintainers at this time. I am happy to discuss other points privately if either you @pmoravec or @arif-ali wish to talk further.

[jcastill]

Thank you so much Pavel and Arif.

sos is not looking for additional maintainers at this time.

The project needs additional maintainers at this time. It has been brought up many times, specially in the last months, that the maintainers are volunteers and spend time on other things, so PR reviews and work on issues may be slow. But SoS is one of the projects I work on full time, so I have time and capacity for it. And my response times and availability during the last year have shown that many times. That's on top of what Arif and Pavel have said already. Why would the maintainer team refuse this help, when it's clear it's needed?

So the situation is that 2 out of 3 maintainers are in favour of this. Here's other questions for you all then:
Are all maintainers equal, or not? Is one maintainer above all others, and they can ignore the others' opinions and reasonings, even veto things?
My understanding (and the understanding from Red Hat side) is that all maintainers are equal. Is that not the case?

[TurboTurtle]

Ok, I guess we're doing this even after I made it painfully obvious that if you or anyone else wanted to continue this discussion it would be in your best interest to do so privately. But I suppose here we go, my apologies to everyone I am having to tag on this to make a point.

The project needs additional maintainers at this time. It has been brought up many times, specially in the last months, that the maintainers are volunteers and spend time on other things, so PR reviews and work on issues may be slow.

We make our releases on time, and with meaningful changes. Please, inform us what major features have been left out of recent releases due to slow issue reviews. But let's pretend for a moment that we do need another maintainer. What would an additional maintainer bring to the project? We still need 2 acks for PRs. We still need meaningful review to ensure code quality. Your spurious reviews have materially amounted, majorily, to accepting anything that gets thrown up on a PR. I stopped keeping track of PRs that you tried to review and approve, where 2 other maintainers, not always even me but admittedly myself a lot, found issues with. If you want to be a maintainer you need to be able to properly maintain code and not just rubber stamp things.

But SoS is one of the projects I work on full time, so I have time and capacity for it.

You don't get a pass on low quality submissions, just because you make them full time. Your PRs have historically been the most in need of review and changes, often through multiple rounds. You also have a history of opening PRs and then abandoning them once you get feedback for anything beyond single-string collections changes. Shall we count how many of your currently open PRs have been sitting for months after a review?

Let's not forget trying to do int comparisons by casting to str and counting the number of digits.

Let's not forget breaking the entire execution of the utility when adding a PackageManager.

Let's not forget simply moving existing code around without fixing any existing issues and trying to portray it as a major feat.

Let's not forget trying to blame an initialization issue on threading before we do any threading work of any kind.

Let's not forget lifting code wholly from another project and slapping your own name on the copyright without ANY attribution originally. I will absolutely die on the hill of not allowing this project to willfully violate the GPL.

A maintainer is understood to know python very well. A maintainer is understood to know sos code very well. You have demonstrated neither. This is not a matter of time spent working, this is a matter of ability. Even if we were looking for another maintainer, even if both @pmoravec and @arif-ali insist, right here right now, that they want another maintainer added to the team, which I am open to even if I'm not convinced it is necessary, there are several more qualified contributors to reach out to.

Notice how this project does not have the same churn with @pmoravec, also a Red Hatter. Or @arif-ali. Or @TrevorBenson. Or @dnegreira. Or any other number of people who not only provide quality code but do so in a timely manner.

You think @bmr-cymru originally made me a maintainer, and then handed the lead role over, because I happened to be active? Hell no. I, rightfully, got reamed on many of my early commits that were not up to snuff. And guess what? I actually took that feedback and improved my submissions.

But lo and behold, the times that you do actually take the feedback, make the needed changes, and update your PR - we accept the code, just the same as from anyone else. Because what this project is after is quality contributions. Stop trying to play the victim here, and really look at what you've been putting forward. When the code is solid and makes sense, it gets merged. If it isn't, it doesn't. Simple as that.

[jcastill]

Ok, I guess we're doing this even after I made it painfully obvious that if you or anyone else wanted to continue this discussion it would be in your best interest to do so privately. But I suppose here we go, my apologies to everyone I am having to tag on this to make a point.

You didn't make "painfully obvious" anything. You told @arif-ali and @pmoravec that you could discuss things privately with them, and didn't address me directly at all.

We make our releases on time, and with meaningful changes. Please, inform us what major features have been left out of recent releases due to slow issue reviews.

I'm not going to fall into the trap of start listing things that fell through the cracks, because then the conversation will drag forever trying to find if something was or wasn't delayed. But both @pmoravec and @arif-ali have mentioned multiple times that things have indeed been slow.

But let's pretend for a moment that we do need another maintainer. What would an additional maintainer bring to the project? We still need 2 acks for PRs. We still need meaningful review to ensure code quality. Your spurious reviews have materially amounted, majorily, to accepting anything that gets thrown up on a PR.

No, I've suggested changes and improvements in many PRs, with things that I've been learning after every mistake I've made. These changes have been either implemented or ignored, like always happens. I've even done to a couple of yours.

I stopped keeping track of PRs that you tried to review and approve, where 2 other maintainers, not always even me but admittedly myself a lot, found issues with. If you want to be a maintainer you need to be able to properly maintain code and not just rubber stamp things.

You don't get a pass on low quality submissions, just because you make them full time.

I have never asked for a pass on this. I mentioned why working full time on this makes me a good candidate to help with the load. Don't put words on my mouth.

Your PRs have historically been the most in need of review and changes, often through multiple rounds.

Not in all of them, not half of them. And every time I've learned.

You also have a history of opening PRs and then abandoning them once you get feedback for anything beyond single-string collections changes. Shall we count how many of your currently open PRs have been sitting for months after a review?

Count them if you want. You don't know what's going on behind the scenes with Jiras and support engineers, testing, reviewing, etc.

Let's not forget trying to do int comparisons by casting to str and counting the number of digits.

Let's not forget breaking the entire execution of the utility when adding a PackageManager.

Let's not forget simply moving existing code around without fixing any existing issues and trying to portray it as a major feat.

Let's not forget trying to blame an initialization issue on threading before we do any threading work of any kind.

Let's not forget lifting code wholly from another project and slapping your own name on the copyright without ANY attribution originally. I will absolutely die on the hill of not allowing this project to willfully violate the GPL.

We come back to this again. The code was contributed internally via a comment and I was told it was original. When I learned it was not so, I referenced the place where the code was coming from in the first comment. And I apologized for my mistake, but it's clear that I will be reminded of this forever. Fine.

But lets take the whole project on this, not my contributions only.
Let's not forget about changes to the project linting that broke many other things, that we investigated, and solved (some even by me). And nobody came back to the engineers that made these reasonable mistakes and threw the issues at their faces.

Let's not forget old code that has never been working, like the RHEL upload functionality for files bigger than 1GB, that has been failing silently forever. But I'm not going to go searching for who wrote this code, and point fingers, because I recognize that shit happens, and we (well, some of us) learn from our mistakes.

A maintainer is understood to know python very well. A maintainer is understood to know sos code very well. You have demonstrated neither. This is not a matter of time spent working, this is a matter of ability. Even if we were looking for another maintainer, even if both @pmoravec and @arif-ali insist, right here right now, that they want another maintainer added to the team, which I am open to even if I'm not convinced it is necessary, there are several more qualified contributors to reach out to.

This project is huge and I don't think any maintainer should be expected to understand all the code from the top of their heads. And I've shown this in the past by pointing things in the code that were obvious to me but not to others while helping with reviews and implementations. This is the point and the essence of a collaborative project.
But also, I come from the C/C++ world, and I inherited a project in Red Hat where I had to learn as much as possible as quickly as possible about python. I was lucky that I had many many mentors, and I keep learning. I have demonstrated that I improve. I have fixed bugs, worked in issues, submited PRs, that have been merged without issues. And again, when I had to make changes, I made them, and learnt and avoided making them again.

Notice how this project does not have the same churn with @pmoravec, also a Red Hatter. Or @arif-ali. Or @TrevorBenson. Or @dnegreira. Or any other number of people who not only provide quality code but do so in a timely manner.

Strange that you bring the fact that @pmoravec is also a Red Hatter. Why is that? I never that mentioned being a Red Hatter is a problem.

You think @bmr-cymru originally made me a maintainer, and then handed the lead role over, because I happened to be active? Hell no. I, rightfully, got reamed on many of my early commits that were not up to snuff. And guess what? I actually took that feedback and improved my submissions.

Please do tell where I refused, mocked, denied, or simply ignored feedback. This is not a competition between what you did, and what I do. People learn at different rhythms and speeds.

But lo and behold, the times that you do actually take the feedback, make the needed changes, and update your PR - we accept the code, just the same as from anyone else. Because what this project is after is quality contributions. Stop trying to play the victim here, and really look at what you've been putting forward. When the code is solid and makes sense, it gets merged. If it isn't, it doesn't. Simple as that.

I am not playing the victim, but I genuinely do feel attacked by your comments and I believe it's not warranted in this situation.
I never asked for anything different, so I'm not sure why you think I'm asking to be treated specially. @pmoravec asked if I can be in the maintainers team to help, and both him and @arif-ali thought it was a good idea. Then you came and went nuclear. And still didn't answer my questions:

Are all maintainers equal, or not? Is one maintainer above all others, and they can ignore the others' opinions and reasoning, even veto things?
My understanding (and the understanding from Red Hat side) is that all maintainers are equal. Is that not the case?

And I guess the answer is: All maintainers are equal, but some are more equal than others.

You have also gone through the code quality as the main drive for being a maintainer, but since you want to do everything public, lets do this.
A maintainer should not be consistently responsible for contributors abandoning the project after being treated badly. We actually opened a thread some time ago about being kinder, and it clearly went completely over your head.
A maintainer should be open to constructive criticism about the project, and not jump full on trying to destroy someone else's contributions. It's still interesting how both @arif-ali and @pmoravec see that there have been issues, but not you, and none of them raised technical issues with my contributions. And I have always taken the criticism without complaining, only trying to understand my technical shortcomings, and being quite thankful when I received feedback.
A maintainer should not harass contributors and potential contributors. For example, a maintainer should never retaliate and approach another contributor's company to complain about said contributor, with the aim of causing as much damage as possible. And it caused a lot of damage.

Once again, I believe I can contribute meaningfully to this project, and that I have been learning and improving and taking feedback, but you insist on not being supportive (all the opposite), so I would invite you to consider your own role and part in the project, and the feedback about kinder interactions that we have already brought up.

[TurboTurtle]

I'm not going to fall into the trap of start listing things that fell through the cracks

That's what a maintainer does is watch the cracks. Bugs get through, obviously, but we don't let major issues through.

You don't know what's going on behind the scenes with Jiras and support engineers, testing, reviewing, etc.

Having previously been the Supportability Development lead at Red Hat, and my history in GSS, I assure you that I do.

We come back to this again. The code was contributed internally via a comment and I was told it was original. When I learned it was not so, I referenced the place where the code was coming from in the first comment. And I apologized for my mistake, but it's clear that I will be reminded of this forever. Fine.

Not only does this completely gloss over the fact that a maintainer needs to be on the look out for this by default, but passing the buck is something else entirely. Your original response to my highlighting this problem was you stating you "adapted" the code to the PR. You only ever referenced the source after I made a deal out of it. Only now are you saying someone else provided it, which completely misses the point that you also did not reference them.

But, yes, let's completely skip over the other, numerous, issues that have come through on PRs that I listed.

And nobody came back to the engineers that made these reasonable mistakes and threw the issues at their faces.

Code reviews are done solely focusing on the code at hand. I'm sorry if you feel attacked, but at no point have I gone out of my way give harder reviews to anyone, including you. Code reviews aren't personal, and any statement that I have made has been completely around the code as written. If your reviews have more changes requested then most, maybe don't look at the reviewer.

As far as "throwing the issues in your face" go - you are asking why you shouldn't be a maintainer. That's (part of) why. That wasn't throwing issues in your face, it was answering the question.

This project is huge and I don't think any maintainer should be expected to understand all the code from the top of their heads.

All code? No. But a majority of the project should be deeply understood, and in your own response here you have made it clear that you don't have that.

But also, I come from the C/C++ world, and I inherited a project in Red Hat where I had to learn as much as possible as quickly as possible about python. I was lucky that I had many many mentors, and I keep learning. I have demonstrated that I improve.

None of this is the concern of the project. None of this compensates for the fact that as of today you have not shown the ability to maintain this project.

Strange that you bring the fact that @pmoravec is also a Red Hatter. Why is that? I never that mentioned being a Red Hatter is a problem.

Never said it was a problem. But part of the push for another maintainer has been the time availability of RH contributors. Time availability is a moot point as Pavel has shown with his own contributions.

I am not playing the victim, but I genuinely do feel attacked by your comments and I believe it's not warranted in this situation.
I never asked for anything different, so I'm not sure why you think I'm asking to be treated specially. @pmoravec asked if I can be in the maintainers team to help, and both him and @arif-ali thought it was a good idea. Then you came and went nuclear.

Oh, no, no, no. You do not get to try and flip the script on this.

You went apeshit over me opening an upload PR.

You only posted your changes after my PR was open because you took it personally.

You came in here and restarted this conversation trying to blow this up as something personal with me after I simply said no, with no nukes anywhere to be found.

I am simply done putting up with the bullshit.

A maintainer should not be consistently responsible for contributors abandoning the project after being treated badly. We actually opened a thread some time ago about being kinder, and it clearly went completely over your head.

There has been one case of a contributor abandoning a PR because of a response of mine. A response to that contributor going off on a fellow maintainer, and at that I still only said that if they were going to behave like that, then we don't want them around. No project wants people like that coming in.

But let me be clear: I will in no way apologize for not letting contributors bully, harass, or spoutoff on project maintainers, or for that matter other contributors.

A maintainer should be open to constructive criticism about the project, and not jump full on trying to destroy someone else's contributions.

Again, I have not tried to "destroy" your contributions. You taking reports of technical issues with your PRs personally is not on me.

For example, a maintainer should never retaliate and approach another contributor's company to complain about said contributor, with the aim of causing as much damage as possible. And it caused a lot of damage.

What in the absolute hell are you talking about? The only sos-related contact I've had with Red Hat was an email from Pavel in October 2023. I won't post it since I don't want to violate Pavel's privacy, but feel free to ask him for it - I have nothing to hide in it. That email did in fact pertain to maintainership and even mentioned you as well as Jan, but it was between the two of us, started by Pavel, and in no way aimed "of causing as much damage as possible". Get all the way out of here with that bullshit.

And I guess the answer is: All maintainers are equal, but some are more equal than others.

Maintainers work together; Arif and Pavel know that they can broach any topic with me at any time, and if they feel strongly about something that they are fully empowered to put the kibosh on it themselves. I may be the "lead" maintainer due to my experience with the project, but by no means have I ever before said that my opinion outweighs either of theirs. It doesn't. It hasn't. The 2-ack system allows for disagreement on code, but as far as the project itself goes we have always worked on a consensus basis.

That said, I am doing something that I have never done before; I am absolutely putting my foot down on this. Your reactions are proof enough for me. Hell, your own response here amounts to "but I'm doing better than before!". "Better" is not sufficient.

If we need another maintainer, so be it, but at this time it will not be you.

[jcastill]

i have not taken feedback personally at any point, other than the moments when it was a clear criticism of my approach and my work, and not a constructive one. I believe I have demonstrated the capacity to learn and evolve, which you are now saying is not enough. Unfortunately, you and I don't seem to be communicating successfully or productively on this, or to have compatible opinions on a lot of these issues, so I will await the opinion of the other maintainers, as you propose that you work on a consensus.

[pmoravec]

The only sos-related contact I've had with Red Hat was an email from Pavel in October 2023. I won't post it since I don't want to violate Pavel's privacy, but feel free to ask him for it - I have nothing to hide in it.

There were a few mail threads between me and Jake since summer 2023, initiated by either of us. Neither of them contained anything that Jose writes about - but I think Jose did not meant any communication involving myself (while I can't comment communication I was not involved in, obviously).

[pmoravec]

Since I don't see we can get to a consensus here while I prefer a consensual agreement on such topic, I am closing this request.