Mailinglist Archive: opensuse-packaging (121 mails)

< Previous Next >
Re: [opensuse-packaging] Packagers - please check your "Url:"s

On 22/03/2019 15:51, John Paul Adrian Glaubitz wrote:
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

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 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

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

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

If you are struggling to manage to maintain all these packages then you likely should be talking to your Manager / Team Lead to look at getting extra resources.

At the same time the project maintainers of d:l:p should probably be giving atleast 2-3 days for actual maintainers to accept requests before they do, there are plenty of other devel repo's where the maintainers do a much better job of this.


Simon Lees (Simotek)

Emergency Update Team
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >