Citeren Michal Kubecek :

On Thu, Jul 11, 2019 at 07:47:57PM +0200, Stasiek Michalski wrote:

...

Hi,

On czw, 11 lip, 2019 at 7:45 PM, Arjen de Korte wrote:

...

I just found out that a package I maintain (php-cs-fixer) got a request, which was accepted within three hours (and not by me). Why? Shouldn't maintainers be allowed a few days before someone stepping in?

I'm f*cking pissed that someone just accepted this change without having a clue of what he is doing. Note: the 'new' version was released on the same date as the previous one and I deliberately choose not to use that one.

There are 13 maintainers of the package (see: https://build.opensuse.org/package/users/server:php:applications/php-cs-fixe...), and it was accepted by one of them.

Not really. If you look carefully, you'll notice that none of those 13 people has a check in the "Maintainer" column (or bugowner, FWIW). All of them are _project_ maintainers. The package actually does not have any maintainer.

Michal Kubecek

It *had* a maintainer until about an hour ago. Said maintainer removed himself at that time. What's the point of maintaining a package if you're given less than three hours to accept/reject a request before someone else butts in? I have better things to do... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Op donderdag 11 juli 2019 21:40:19 CEST schreef Michal Kubecek:

On Thu, Jul 11, 2019 at 08:22:45PM +0200, Arjen de Korte wrote:

...

Citeren Michal Kubecek :

...

On Thu, Jul 11, 2019 at 07:47:57PM +0200, Stasiek Michalski wrote:

...

Hi,

On czw, 11 lip, 2019 at 7:45 PM, Arjen de Korte

wrote:

...

I just found out that a package I maintain (php-cs-fixer) got a request, which was accepted within three hours (and not by me). Why? Shouldn't maintainers be allowed a few days before someone stepping in?

I'm f*cking pissed that someone just accepted this change without having a clue of what he is doing. Note: the 'new' version was released on the same date as the previous one and I deliberately choose not to use that one.

There are 13 maintainers of the package (see: https://build.opensuse.org/package/users/server:php:applications/php-c s-fixer), and it was accepted by one of them.

Not really. If you look carefully, you'll notice that none of those 13 people has a check in the "Maintainer" column (or bugowner, FWIW). All of them are _project_ maintainers. The package actually does not have any maintainer.

Michal Kubecek

It *had* a maintainer until about an hour ago. Said maintainer removed himself at that time.

Ah, I see.

...

What's the point of maintaining a package if you're given less than three hours to accept/reject a request before someone else butts in?

Preaching to the choir... The same problem (project maintainer accepting a submit request within hours, before package maintainer had a chance to react) happened to me few times already and I was also very angry - and even tried to complain about it (with little success). What I can say that it doesn't happen as often recently; or at least not to me, it probably depends on the project (or rather the project maintainers).

There is a trick if you want to make bypassing the maintainer harder: add also the "reviewer" role to yourself in the package. There will be probably still a way to accept such request without your consent if there is a need but it shouldn't be possible in the annoying "ha, there is a submit request, submit requests are good, mkay, let's accept it ASAP" way.

Michal Kubecek Arjen, dat zou moeten helpen ..... ;>D

-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 2019-07-12 at 09:45 +0200, Stefan Seyfried wrote:

...

It *had* a maintainer until about an hour ago. Said maintainer removed himself at that time.

Hint (in case you're still interested...):

Setting yourself as "reviewer" helps to avoid this. Even though I think the pending review can still be overridden, it send a very clear signal to all other project maintainers about that there is someone interested in this package and so this will not happen accidentally.

This is good advice, especially when you consider many Project Maintainers are Project Maintainers in different projects..and not all Project's have the same ways of working. This is by design..the whole point of the Devel Project model is that each Devel Project should come up with rules that works for the individuals involved. But when you then consider that we have some horrifically large Devel Projects with hundreds of packages, some of which are cared for by individual maintainers who have different expectations than the rest of the Project..sure, I can see how this issue still happens even with everyone acting with absolute best intentions. Speaking from my own experience in the GNOME: devel projects, we have things set up so that every SR _MUST_ be reviewed by someone else in the GNOME project before it can be accepted by anyone in the GNOME Project. This two stage approach pretty much utterly kills off self- accepting anything. In devel:kubic things are a little more split up, as we have pretty much only myself as the Project Maintainer, but a growing handful of Package Maintainers. If I'm submitting something to a package with a Package Maintainer, I will almost always respect OBS's bloody huge warning message and only self-accept my own SR as a last resort, after giving some significant time to pass for the assigned maintainer to do their thing. Any exceptions will only be in the name of fixing major issues urgently in Kubic/Tumbleweed, and I'll be explaining myself to the Package Maintainer when I do that. The same goes for devel:kubic's Package Maintainers - self-acceptance should be avoided when it can, so I do my best to review SR's from assigned maintainers quickly so they're not feeling like they're stuck waiting. In short - as empathetic as I am to the original posters plight, I do think talking directly to the Project Maintainers involved is a better approach than profane posts to -factory. Regards, -- Richard Brown Linux Distribution Engineer - Future Technology Team Chairman - openSUSE Phone +4991174053-361 SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org