On 3/21/19 9:10 PM, Jan Engelhardt wrote:
.. and requests to add more fine-grained user roles in OBS have gone unheard in the past.
On the other hand, the absence of a maintainer (especially if prolonged) should not be able to cause a stall.
No, but that also doesn't mean you get to make changes immediately without talking to someone in charge of the package if a package is actively maintained. Not everyone is sitting in front of their computers 24/7, people can become sick or go on vacation. So, a little more patience is not too much to ask for.
For example, I am maintaining the Python Azure SDK for the Public Cloud Team at SUSE. For the second time now, someone has sent in requests to update just two out of over 100 packages that make up the Python Azure SDK. [...]
There are only three maintainers in that project, yourself included, and they all work for SUSE. If it's impossible to coordinate with the two other maintainers, I just wonder how we ever managed to survive the ridiculous amount of 30 listed maintainers with a good mix of non-SUSE poeple in devel:libraries:c_c++ so far.
The problem is the ridiculous amount of submit requests pouring in, especially with changes like "Change phrasing in Summary". This produces a lot of noise and important things fall off the table. This is why I'm not a fan of these micro changes.
I missed the two submit request mails as there are currently dozens of these mails per day for the devel:languages:python project. I was also quite busy moving apartments during that week so I could not read mail all the time, I would have rejected those requests. Now they were accepted by another d:l:p maintainer and eventually successfully accepted into Factory despite making the Python Azure SDK uninstallable. I'm also surprised that these changes were not blocked by the Factory maintainers despite the fact they introduced breakage.
Likely because they did not introduce breakage as far as OBS is concerned - are you sure there is a Azure SDK test job in OpenQA?
The package is uninstallable. I'm pretty sure OBS should catch that on its own and Stephan Kulow already commented that the issue was known and they hoped for a rebuild to fix the issue. The problem is though that the dependencies are hardwired for good reasons and thus a rebuild won't fix them.
I don't know what I can do to prevent this in the future, but I really wish the communication would work better and people wouldn't just randomly push submit requests to packages without having at least talked to the maintainer of the packages in question first. Good communication is a key point when collaborating in open source projects.
SRs are a form of communication. It might be a somewhat clunky one due to OBS's implementation (messages and comments are separate entities for example), but they still have fields for messages, comments, and a patch, similar to Github PRs or git-send-email'ed mails.
Not if I am drowning in submit requests for d:l:p. I'm a human, not a robot. If I receive 150+ mails per day, I can only process that many.
I really wish maintainers would calm down and not interpret the presence of a patch fragment (in SRs, GH PRs, or whatever) as an "uncommunicated attack" on their package and authority, but to interpret such requests as "this is my idea, and this is how it could look in program code".
Look, the problem here is that these packages are primarily for the Public Cloud Team. This means that these packages are of strategic relevance for SUSE and their paying customers. And unless you are willing to take care of all 112+ packages of the Azure SDK, you are not helping me but make my life harder. Thanks, Adrian N�����r��y隊Z)z{.��ZrF��x>�{.n�+������Ǩ��r��i�m��0��ޙ������� ��$j���0�����Ǩ�