Escalating bugs / requests
Hi, my question might seem a bit strange, but is there a way to escalate bugs or requests? So I mean if the maintainer of package does not respond for months, even if there is already a SR fixing the bug. I do not want to blame anyone, please do not feel offended, but boo#1191345 is quite annoying while the fix waits for about 3 months (SR#948954). Regards, Ferdinand
Hello Ferdinand, Am Dienstag, 26. April 2022, 19:09:18 CEST schrieb Ferdinand Thiessen:
my question might seem a bit strange, but is there a way to escalate bugs or requests? So I mean if the maintainer of package does not respond for months, even if there is already a SR fixing the bug.
I do not want to blame anyone, please do not feel offended, but boo#1191345 is quite annoying while the fix waits for about 3 months (SR#948954).
Contact the maintaners of server:dns directly for an override. HTH Axel
Am 26.04.22 um 19:20 schrieb Axel Braun:
Contact the maintaners of server:dns directly for an override.
Exactly, you can also add a comment @mentioning them, just like the staging-bot does it. The bot will only ping package maintainers if they are explicitly specified, but project maintainers can also accept this. I can only guess, but the maintainer is likely no longer active. Aaron
On 4/27/22 08:39, Aaron Puchert wrote:
Am 26.04.22 um 19:20 schrieb Axel Braun:
Contact the maintaners of server:dns directly for an override.
Exactly, you can also add a comment @mentioning them, just like the staging-bot does it. The bot will only ping package maintainers if they are explicitly specified, but project maintainers can also accept this.
You can also try and directly email them, some of us get very large numbers of comments and can often miss them. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
"Simon" == Simon Lees <sflees@suse.de> writes:
Simon> On 4/27/22 08:39, Aaron Puchert wrote:
Am 26.04.22 um 19:20 schrieb Axel Braun:
Contact the maintaners of server:dns directly for an override.
Exactly, you can also add a comment @mentioning them, just like the staging-bot does it. The bot will only ping package maintainers if they are explicitly specified, but project maintainers can also accept this.
Simon> You can also try and directly email them, some of us get very large Simon> numbers of comments and can often miss them. Which he did with no response, so that ship has sailed I am afraid. The question is not relevant to one single incident, when people bring issues to the mailinglist, the common and then logical answer is create an issue at bugzilla. So Jo the happy chap does as told creates the bugzilla, and 80 % (arbitrary number but let's say Pareto rule) the issue is solved. The remaining 20% is the extra debt that is on the system. There is a fix, SR to the upper project in this case server:dns if and when that is approved there would be another SR to factory and finally sometime in the near future the old SR would end up in production. So the question how do we solve this not for now but for the future as well ? Thanks Togan -- Life is endless possibilities, and there is choice!
Hi, Am Mittwoch, 27. April 2022, 17:00:52 CEST schrieb toganm@dinamizm.com:
So the question how do we solve this not for now but for the future as well ?
I think we need different steps: First we need to clean up OBS from inactive users or invalid mail addresses. I seem to remember that there was an initiative planned, but dont know about the status. Second it would help to have an overview about the SR per project - ideally with the option to sort by different criteria, e.g. age. Some kind of dashboard. Third - someone has to process overdue SR, if the package maintainer does not do, for whatever reason. The natural choice would be the project maintainers. Second choice could be some kind of taskforce that reviews open SR on a regular basis. This would require additional communication with the package/ project owners, just to make sure the SR is in line with standards and (local) guidelines (from my experience, it can make a difference to where you submit a package - in one case one discusses that the description has to have a line break after 80 char, in the other case it is much more relaxed...). My 2c Axel
tOn Wednesday 2022-04-27 21:58, Axel Braun wrote:
Second it would help to have an overview about the SR per project - ideally with the option to sort by different criteria, e.g. age. Some kind of dashboard.
already exists. e.g. o:F at https://build.opensuse.org/project/requests/openSUSE:Factory
Am Mittwoch, 27. April 2022, 22:52:52 CEST schrieb Jan Engelhardt:
tOn Wednesday 2022-04-27 21:58, Axel Braun wrote:
Second it would help to have an overview about the SR per project - ideally with the option to sort by different criteria, e.g. age. Some kind of dashboard.
already exists. e.g. o:F at https://build.opensuse.org/project/requests/openSUSE:Factory
Good point, so step 3 can immediately be taken... Cheers Axel
"Jan" == Jan Engelhardt <jengelh@inai.de> writes:
Jan> tOn Wednesday 2022-04-27 21:58, Axel Braun wrote:
Second it would help to have an overview about the SR per project - ideally with the option to sort by different criteria, e.g. age. Some kind of dashboard.
Jan> already exists. e.g. o:F at Jan> https://build.opensuse.org/project/requests/openSUSE:Factory That is for SR submitted to factory. We need to find a strategy to apply it and use it project wise. For every user/project there exists a similar dashboard for requests, but it seems to me that this approach alone is not bringing the desired outcomes to the expected levels. So we need to find answers to the following at first otherwise this whole discussion is like baby birds chipping in the woods. 1. What has been working well ? 2. What hasn’t been working well ? 3. What are we going to change moving forward ? -- Life is endless possibilities, and there is choice!
On 4/28/22 00:30, toganm@dinamizm.com wrote:
"Simon" == Simon Lees <sflees@suse.de> writes:
Simon> On 4/27/22 08:39, Aaron Puchert wrote:
Am 26.04.22 um 19:20 schrieb Axel Braun:
Contact the maintaners of server:dns directly for an override.
Exactly, you can also add a comment @mentioning them, just like the staging-bot does it. The bot will only ping package maintainers if they are explicitly specified, but project maintainers can also accept this.
Simon> You can also try and directly email them, some of us get very large Simon> numbers of comments and can often miss them.
Which he did with no response, so that ship has sailed I am afraid.
Sorry I meant email the project maintainers, if there is a submit request that isn't being acted on its there responsibility too look at and approve it. They also have the power to appoint a new maintainer if someone volunteers. If you don't get a response from project maintainers then email here and we will appoint someone else to help. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
"Simon" == Simon Lees <sflees@suse.de> writes:
Simon> Sorry I meant email the project maintainers, if there is a submit Simon> request that isn't being acted on its there responsibility too look at Simon> and approve it. They also have the power to appoint a new maintainer if Simon> someone volunteers. Simon> If you don't get a response from project maintainers then email here Simon> and we will appoint someone else to help. What you are suggesting is a bandaid option, which is pointing to someone else or another group/project. I suggest we need to find a better, sustainable approach which will help everyone from enduser to project maintainer to release team. Out of curiosity how is it done in the corporate SuSE and if done how can we apply/adapt the approach to openSUSE ? Togan -- Life is endless possibilities, and there is choice!
On Thu, Apr 28, Togan Muftuoglu wrote:
Out of curiosity how is it done in the corporate SuSE and if done how can we apply/adapt the approach to openSUSE ?
It's "SUSE" and not "SuSE" since a really very, very long time. SUSE pays developers to do the work, while openSUSE depends on contributors and their spare time. So you cannot apply or adapt the approach. Except somebody donates so much money to the openSUSE project, that they can hire developers, too. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Ivo Totev (HRB 36809, AG Nürnberg)
"Thorsten" == Thorsten Kukuk <kukuk@suse.de> writes:
Thorsten> On Thu, Apr 28, Togan Muftuoglu wrote:
Out of curiosity how is it done in the corporate SuSE and if done how can we apply/adapt the approach to openSUSE ?
Thorsten> It's "SUSE" and not "SuSE" since a really very, very long time. Sorry my bad. Though on a second thought I couldn't figure out how this helps the issue at hand. -- Life is endless possibilities, and there is choice!
On 4/28/22 22:08, Togan Muftuoglu wrote:
"Simon" == Simon Lees <sflees@suse.de> writes:
Simon> Sorry I meant email the project maintainers, if there is a submit Simon> request that isn't being acted on its there responsibility too look at Simon> and approve it. They also have the power to appoint a new maintainer if Simon> someone volunteers.
Simon> If you don't get a response from project maintainers then email here Simon> and we will appoint someone else to help.
What you are suggesting is a bandaid option, which is pointing to someone else or another group/project.
Well in an ideal world people would realize they no longer have time and would put there packages up for adoption that happens sometimes, often it doesn't. Regularly we don't realise until a package no longer builds. Project maintainers are designed to be the fallback for cases where package maintainers are away and to help when package maintainers disappear. I'm not really sure what we can do better here but if you have suggestions.
I suggest we need to find a better, sustainable approach which will help everyone from enduser to project maintainer to release team.
Out of curiosity how is it done in the corporate SuSE and if done how can we apply/adapt the approach to openSUSE ?
Sometimes well, sometimes badly but not really in a way we can adapt for openSUSE. For example if I was to leave the company my manager has a list of my packages and would get other people in the team to look after them until they hire a replacement, often in this period we will ping project maintainers with specific requests if they aren't being picked up by anyone then eventually a replacement person will be found and they will be assigned my packages (or they may swap some with others in the team). We also has a script that finds all SLE packages without a maintainer that usually have a lighter workload (not many security updates etc) and they rotate between a group of different people. This works for SUSE because we pay maintainers and can tell them that its there job to look after this group of packages for a week. That doesn't work for openSUSE where everyone is a volunteer and we can't really tell them to work on things. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Wed, 2022-04-27 at 01:09 +0200, Aaron Puchert wrote:
Am 26.04.22 um 19:20 schrieb Axel Braun:
Contact the maintaners of server:dns directly for an override.
Exactly, you can also add a comment @mentioning them, just like the staging-bot does it. The bot will only ping package maintainers if they are explicitly specified, but project maintainers can also accept this.
I can only guess, but the maintainer is likely no longer active.
server:dns seems entirely abandoned. I have two requsts towards it since a couple months (one of them being a new package) and the only thing that happens there is the review reminder bot sending me an email every other week. Looking at the maintainers of server:dns to CC them, I've noticed the project doesn't appear to have a bugowner set (but I guess that doesn't really matter if it isn't maintained in the first place).
Aaron
Regards, Florian "sp1rit" -- $\int_\text{now}^{+\infty}\text{Keep trying}$ Matrix: @sp1rit:tchncs.de <sp1rit@disroot.org> D248BF2F4C6A82A1E0569D897D8C1CD573166D09 <sp1rit@national.shitposting.agency> BBDE032EAAFBFC627FB7E635B1F4055D8460CE34
Axel Braun wrote:
Contact the maintaners of server:dns directly for an override.
That was something I already thought of, wrote to two of them last month without response. But is not only about that package, but for a general discussion as there are several packages I noticed (in Factory not random 3rd party packages) not updated / fixed for quite a time with pending requests. As Togan wrote there probably should be a strategy for handling requests without response and even bugs without response. Regards, Ferdinand
"FT" == Ferdinand Thiessen <rpm@fthiessen.de> writes:
FT> Hi, my question might seem a bit strange, but is there a way to escalate FT> bugs or requests? So I mean if the maintainer of package does not respond FT> for months, even if there is already a SR fixing the bug. FT> I do not want to blame anyone, please do not feel offended, but FT> boo#1191345 is quite annoying while the fix waits for about 3 months FT> (SR#948954). Thanks for bringing this up. I guess we are the only two effected by this bug. While knowing the fix being available is good news, I definitely agree on your point that the process being blocked by on by one person is a bad design strategy. But this is true for lot's of other bugs in bugzilla. Bugzilla needs a cleanup strategy as there are open bugs which are not even relevant as of today. Some of them are in progress. boo#965037 Status New last change 2016-02-04 boo#1177872 Status IN_PROGREE last change 2020-12-30 Bugzilla has lot's of techical debts that has to be paid. Maybe it is time to do a cleanup event ? -- Life is endless possibilities, and there is choice!
participants (11)
-
Aaron Puchert -
Axel Braun -
Axel Braun
-
Axel Braun -
Ferdinand Thiessen -
Jan Engelhardt -
Simon Lees -
sp1rit -
Thorsten Kukuk -
Togan Muftuoglu -
toganm＠dinamizm.com