[opensuse-factory] didn't we just discuss this? (maintainer role)

newer
[opensuse-factory] a stop job is...

older
[opensuse-factory] OT: opensuse...

Wolfgang Rosenauer

2 Feb 2016 2 Feb '16

23:41

Hi, sorry for the bad $SUBJECT but now I finally need to complain as well a bit. Following is a snippet from an SR for a package I'm maintaining into its devel project: (happened just today) XXXXX created request about 8 hours ago YYYYY Request got accepted about 8 hours ago I actually like that stuff does not lie around just because of lazy maintainers but is this really how it's supposed to work? It seems I simply should drop my maintainer role for this package. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Show replies by date

Bernhard Voelker

3 Feb 3 Feb

07:47

On 02/03/2016 12:41 AM, Wolfgang Rosenauer wrote:

...

Following is a snippet from an SR for a package I'm maintaining into its devel project: (happened just today)

XXXXX created request about 8 hours ago YYYYY Request got accepted about 8 hours ago

I actually like that stuff does not lie around just because of lazy maintainers but is this really how it's supposed to work?

Hard to tell - it seems there is more than 1 maintainer (you) for this package, and the other maintainer seems to have accepted the request. Assuming XXXXX abd YYYYY are user names and therefore different people, I couldn't tell if they e.g. haven't been in contact before the creation of the SR, thus e.g. YYYYY may already have had a look at the home:XXXXX project. Well, or not. However, both you and YYYYY seem to have the maintainer role, and there don't seem to be technical differences between a "main maintainer" and a "co-maintainer". Everyone has the same rights. So your question boild down to: "Why is YYYYY a maintainer in my project?", right? Well, I don't have an answer. But given that also YYYYY is spending his/her spare time, I'd assume he/she is also trying to give his best to fill the role and serve the project. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Wolfgang Rosenauer

09:40

Am 03.02.2016 um 08:47 schrieb Bernhard Voelker:

...

On 02/03/2016 12:41 AM, Wolfgang Rosenauer wrote:

...
Following is a snippet from an SR for a package I'm maintaining into its devel project: (happened just today)

XXXXX created request about 8 hours ago YYYYY Request got accepted about 8 hours ago

I actually like that stuff does not lie around just because of lazy maintainers but is this really how it's supposed to work?

Hard to tell - it seems there is more than 1 maintainer (you) for this package, and the other maintainer seems to have accepted the request. Assuming XXXXX abd YYYYY are user names and therefore different people, I couldn't tell if they e.g. haven't been in contact before the creation of the SR, thus e.g. YYYYY may already have had a look at the home:XXXXX project. Well, or not.

However, both you and YYYYY seem to have the maintainer role, and there don't seem to be technical differences between a "main maintainer" and a "co-maintainer". Everyone has the same rights.

short answer here is that YYYYY is not the other maintainer but a project maintainer of the devel project. More comprehensive answer in another mail in this thread. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Wolfgang Rosenauer

10:53

Hi, the approver outlined his reasons to me personally why he came to the conclusion that it's fine to approve the SR. I can follow this reasoning and in the first place I had and have no technical doubts about accepting this SR in the first place. I would have done so as well and it was a "simple" version upgrade only. Still the reasons contain some assumptions and I'm not sure if we should have a pretty strict rule to give at least a bit of time to the maintainer even if they look really simple. There could be several reasons which cannot be known by project maintainers for example. Another solution could be to have a really easy and quick to use "revert" feature in the webui (at least I haven't seen something like this yet). Opinions? Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Johannes Meixner

13:17

Hello, On Feb 3 11:53 Wolfgang Rosenauer wrote (excerpt):

...

... I'm not sure if we should have a pretty strict rule to give at least a bit of time to the maintainer even if they look really simple. There could be several reasons which cannot be known by project maintainers for example. Another solution could be to have a really easy and quick to use "revert" feature in the webui

I think in general it is bad when a project maintainer ignores explicitly specified package maintainers. If there exists one or more explicitly specified package maintainers, then anyone else should normally leave any issue for the explicit package maintainers decision up to a reasonable waiting time. In the other mail thread there was a proposal that the default waiting time should be one week. I think this makes sense. Exceptions could be things like an urgent security fix that is a simple change in the code - but even in this case explicit package maintainers should get involved. In contrast from my point of view a normal bugfix that is a simple change in the code is no reason to ignore explicit package maintainers. I am against a "revert" feature because I think this cannot really work well: Assume a project maintainer who ignores explicitly specified package maintainers "just accepts" a change and also forwards it to Factory on Friday afternoon... In the end I think what is acutally missing is communication in advance First the one who submits a change ignores the explicitly specified package maintainers because he did not contact them in advance to tell them what he likes to do before he does his submitrequest. Then the one who accepts such a submitrequest also ignores the explicitly specified package maintainers. Perhaps a technical help to avoid that package maintainers are ignored might be an automated review request that needs to be accepted by a package maintainer within a reasonable waiting time (e.g. one week)? Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andrei Borzenkov

13:42

On Wed, Feb 3, 2016 at 4:17 PM, Johannes Meixner wrote: ...

...

In the end I think what is acutally missing is

communication in advance

First the one who submits a change ignores the explicitly specified package maintainers because he did not contact them in advance to tell them what he likes to do before he does his submitrequest.

Submit request is the best way to tell what he likes to do. What is missing is usable platform for reviewing and discussing such requests. And clicking through web GUI and manually finding persons who probably should be informed is not encouraging doing it either. As much as link "send e-mail to maintainers" would already help, if you think this is what is needed (I do not). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Johannes Meixner

13:57

Helo, On Feb 3 16:42 Andrei Borzenkov wrote (excerpt):

...

On Wed, Feb 3, 2016 at 4:17 PM, Johannes Meixner wrote: ...

...
In the end I think what is acutally missing is

communication in advance

First the one who submits a change ignores the explicitly specified package maintainers because he did not contact them in advance to tell them what he likes to do before he does his submitrequest.

Submit request is the best way to tell what he likes to do.

No! - from my point of view. But I do not mean submitrequests from people who are already well known to the package maintainers. I meant primarily completely new submitrequests from people where that submitrequests are the very first thing the package maintainers get.

...

What is missing is usable platform for reviewing and discussing such requests.

If you have something like GitHub in mind, I do fully agree. But even on GitHub - as far as I experienced - it usually starts ther with an issue and not with a pull request. So that also on GitHub there is communication in advance via GitHub issues. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Ruediger Meier

21:19

On Wednesday 03 February 2016, Johannes Meixner wrote:

...

Hello,

On Feb 3 11:53 Wolfgang Rosenauer wrote (excerpt):

...
... I'm not sure if we should have a pretty strict rule to give at least a bit of time to the maintainer even if they look really simple. There could be several reasons which cannot be known by project maintainers for example. Another solution could be to have a really easy and quick to use "revert" feature in the webui

I think in general it is bad when a project maintainer ignores explicitly specified package maintainers.

If there exists one or more explicitly specified package maintainers, then anyone else should normally leave any issue for the explicit package maintainers decision up to a reasonable waiting time.

In the other mail thread there was a proposal that the default waiting time should be one week.

I think this makes sense.

Sometimes it's annoying to wait that long. I guess this is the only reason why we have so many project maintainers sitting in any project at all. Another idea might be that one package maintainer could accept immediately but it would need at least 2 or 3 project maintainers to accept. If the package maintainer is sr'ing himself then one project maintainer might be enough to accept. Then ... after one week silence ... anybody of the project maintainers can accept alone. BTW what I really don't like is that a maintainer can just commit without branching/sr'ing at all. Some people just commit (even without any commit message) and they would never sr at all. That's the most annoying thing. You don't even get a message that somebody did something. And last but not least ... the submitter should not be allowed to accept his own request accept he _owns_ the project (e.g. his own home:USER). cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michal Kubecek

4 Feb 4 Feb

06:59

On Wednesday 03 of February 2016 22:19:34 Ruediger Meier wrote:

...

Sometimes it's annoying to wait that long. I guess this is the only reason why we have so many project maintainers sitting in any project at all.

Another idea might be that one package maintainer could accept immediately but it would need at least 2 or 3 project maintainers to accept. If the package maintainer is sr'ing himself then one project maintainer might be enough to accept.

Then ... after one week silence ... anybody of the project maintainers can accept alone.

I would rather suggest for project maintainers to check if package maintainer (in the formal sense) does really actively maintain the package. If so, please give him some time. If not - and often this is quite obvious - there is probably no need to wait, especially for simple "obviously correct" changes. But in that case, they should probably also contact such inactive "maintainer" and check if is going to live up to his role or not.

...

BTW what I really don't like is that a maintainer can just commit without branching/sr'ing at all. Some people just commit (even without any commit message) and they would never sr at all. That's the most annoying thing. You don't even get a message that somebody did something.

First, committing changes without any message or changelog entry is definitely wrong. Other than that: no, please no. If a package is maintained by a group of people and they agree on such "requests only" policy, it's their choice and it should be respected. But there is a lot (perhaps even majority) of packages with a single maintainer who is usually the only one caring for that package (except for an occasional trivial change from someone else). Often the project managers don't even know the package as users. In such case, enforcing a "requests only" policy - with OBS branching by far not as easy to use as git branches (notice: no "-hub" here) - would be just adding useless bureaucracy without any positive effect. And, I dare to say, another thing that could very well discourage people from going out of their home projects with packages. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jiri Slaby

09:01

On 02/04/2016, 07:59 AM, Michal Kubecek wrote:

...

On Wednesday 03 of February 2016 22:19:34 Ruediger Meier wrote:

...
BTW what I really don't like is that a maintainer can just commit without branching/sr'ing at all. Some people just commit (even without any commit message) and they would never sr at all. That's the most annoying thing. You don't even get a message that somebody did something.

First, committing changes without any message or changelog entry is definitely wrong.

Other than that: no, please no.

+1. If you want to enforce something, disallow empty commit messages. thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt

09:40

On Thursday 2016-02-04 07:59, Michal Kubecek wrote:

...

On Wednesday 03 of February 2016 22:19:34 Ruediger Meier wrote:

...
...
[multiple other people with proposals] [proposal] [proposal]

Whatever the proposal is, unless there is software support to flip an enforcement option, nothing will change. (IOW, someone has to start writing code.) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Takashi Iwai

11:32

On Thu, 04 Feb 2016 07:59:38 +0100, Michal Kubecek wrote:

...

On Wednesday 03 of February 2016 22:19:34 Ruediger Meier wrote:

...
Sometimes it's annoying to wait that long. I guess this is the only reason why we have so many project maintainers sitting in any project at all.

Another idea might be that one package maintainer could accept immediately but it would need at least 2 or 3 project maintainers to accept. If the package maintainer is sr'ing himself then one project maintainer might be enough to accept.

Then ... after one week silence ... anybody of the project maintainers can accept alone.

I would rather suggest for project maintainers to check if package maintainer (in the formal sense) does really actively maintain the package. If so, please give him some time. If not - and often this is quite obvious - there is probably no need to wait, especially for simple "obviously correct" changes. But in that case, they should probably also contact such inactive "maintainer" and check if is going to live up to his role or not.

Can we have some marker in the package information, showing the maintainer X wants to be a gatekeeper, every SR has to be accepted by X? I bet they are rather minority, and majority of thousands of packages are loosely maintained. So it's easier to achieve than asking inactive maintainer at each time. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marcus Meissner

12:41

On Thu, Feb 04, 2016 at 12:32:05PM +0100, Takashi Iwai wrote:

...

On Thu, 04 Feb 2016 07:59:38 +0100, Michal Kubecek wrote:

...
On Wednesday 03 of February 2016 22:19:34 Ruediger Meier wrote:

...
Sometimes it's annoying to wait that long. I guess this is the only reason why we have so many project maintainers sitting in any project at all.

Another idea might be that one package maintainer could accept immediately but it would need at least 2 or 3 project maintainers to accept. If the package maintainer is sr'ing himself then one project maintainer might be enough to accept.

Then ... after one week silence ... anybody of the project maintainers can accept alone.

I would rather suggest for project maintainers to check if package maintainer (in the formal sense) does really actively maintain the package. If so, please give him some time. If not - and often this is quite obvious - there is probably no need to wait, especially for simple "obviously correct" changes. But in that case, they should probably also contact such inactive "maintainer" and check if is going to live up to his role or not.

Can we have some marker in the package information, showing the maintainer X wants to be a gatekeeper, every SR has to be accepted by X? I bet they are rather minority, and majority of thousands of packages are loosely maintained. So it's easier to achieve than asking inactive maintainer at each time.

I think you can add a "reviewer" role in addition to "maintainer". Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stefan Seyfried

09:09

On 03.02.2016 22:19, Ruediger Meier wrote:

...

BTW what I really don't like is that a maintainer can just commit without branching/sr'ing at all. Some people just commit (even without any commit message) and they would never sr at all. That's the most annoying thing. You don't even get a message that somebody did something.

Well, the "no/bad commit message" is obviously bad. But there are sometimes fixes that are just too trivial (SPDX license string fix, really trivial specfile fixes / cleanups, ...) to warrant the whole fork, build, ... cycle, so I also sometimes just commit the fix in the devel package.

...

And last but not least ... the submitter should not be allowed to accept his own request accept he _owns_ the project (e.g. his own home:USER).

And also there are exceptions to the rule IMO. Example: bluez package is really maintained in home:seife:testing. home:seife:testing is enabled and used on all my machines (13.2, 42.1, Factory). So once I have decided to submit bluez to Base:System, the only thing someone could improve by having a second look is to fix style issues in the spec file ("missing patch tag" is one of those i especially like, but it's not enforced in Base:System AFAICT). So usually I submit it to Base:System, just to immediately accept and forward it to Factory. Where it will be looked at anyway and it will undergo scrutiny in staging, which would not have happened in Base:System anyway. Add to that, that bluez upstream is extremely reliable IMHO, means: they do not break compatibility without announcing it, their announce mails for new versions can be put 1:1 into the rpm changelog and are a useful sumkmary etc, so the risk of an bluez update breaking things is low. (No, they are not perfect, yes, there have been bugs exposed by staging or obs tests, but usually a version update is extremely painless). I certainly would usually not accept my own submitrequest against a package which is not maintained and tested by me, but where I just made a build fix and submitted that to get dependencies fixed again. But even there it depends. If it is some pacakge where lots of stuff depends upon (and which thus blocks a rebuild) and where I just had to do a trivial buildfix which "surely does not break anything" (famous last words, I know), then I might be tempted to just speed things up by self-accepting / forwarding things if I'm in a position to do that (co-maintainer of the project) Applying common sense is certainly helpful :-) The above things written about bluez and home:seife:testing can be applied to the vdr packages and home:seife:vdrdevel, too. I'm self-accepting all the submissions in the vdr repo also. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Simon Lees

09:24

On 02/04/2016 07:49 AM, Ruediger Meier wrote:

...

And last but not least ... the submitter should not be allowed to accept his own request accept he _owns_ the project (e.g. his own home:USER). cu, Rudi

Thats pretty hard for projects like X11:Enlightenment:Factory where there is only 1 core maintainer + someone else who fixes up the odd bits and pieces occasionally when they get a chance or notice something. It would add a massive burden to that second person. Even worse would be devel projects If there was only 1 person willing to maintain, basically nothing could get done. It may be a reasonable Idea for larger projects though (I don't know, I don't maintain any). Cheers Simon -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Johannes Meixner

11:26

Hello, On Feb 3 22:19 Ruediger Meier wrote (excerpt):

...

On Wednesday 03 February 2016, Johannes Meixner wrote:

...
I think in general it is bad when a project maintainer ignores explicitly specified package maintainers.

If there exists one or more explicitly specified package maintainers, then anyone else should normally leave any issue for the explicit package maintainers decision up to a reasonable waiting time.

In the other mail thread there was a proposal that the default waiting time should be one week.

I think this makes sense.

Sometimes it's annoying to wait that long.

Why? If you are the one who did the submitrequest, you already have the new stuff because you have built it and tested it on your system to verify that the new stuff works at least for you on your system. If you are someone else do you think explicitly specified package maintainers could be ignored only to get some newest stuff faster? I think nobody should ignore explicitly specified package maintainers without giving them a reasonable time to act. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Ruediger Meier

12:19

On Thursday 04 February 2016, Johannes Meixner wrote:

...

Hello,

On Feb 3 22:19 Ruediger Meier wrote (excerpt):

...
On Wednesday 03 February 2016, Johannes Meixner wrote:

...
I think in general it is bad when a project maintainer ignores explicitly specified package maintainers.

If there exists one or more explicitly specified package maintainers, then anyone else should normally leave any issue for the explicit package maintainers decision up to a reasonable waiting time.

In the other mail thread there was a proposal that the default waiting time should be one week.

I think this makes sense.

Sometimes it's annoying to wait that long.

Why?

...

If you are the one who did the submitrequest, you already have the new stuff because you have built it and tested it on your system to verify that the new stuff works at least for you on your system.

But I want to get rid of all my local branches as quickly a possible. osc is a bit annoying centralized VCS. It's difficult to have many local patches. If it would be git then I've had less problems.

...

If you are someone else do you think explicitly specified package maintainers could be ignored only to get some newest stuff faster?

...

I think nobody should ignore explicitly specified package maintainers without giving them a reasonable time to act.

I have the feeling that 90% of my requests are not accepted by the package maintainer but by anybody else with permissions. The one-week delay would just slow down things I guess. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Johannes Meixner

14:07

Hello, On Feb 4 13:19 Ruediger Meier wrote (excerpt): ...

...

...
I think nobody should ignore explicitly specified package maintainers without giving them a reasonable time to act.

I have the feeling that 90% of my requests are not accepted by the package maintainer but by anybody else with permissions. The one-week delay would just slow down things I guess.

I did not check anything but I have the dim feeling that perhaps 90% of the packages do not have an explicitly specified package maintainer or that there are many falsely specified package maintainers (i.e. who do not actively maintain the package) and as an unfortunate consequence others with permissions step in to move things forward. That a one-week delay should be an exceptional case. I meant it as the maximum waiting time for an explicitly specified package maintainer to react. Afterwards others with permissions can step in to move things forward. I wonder if it is possible for a package maintainer to neither accept or decline a submitrequest immediately but to immediately only "take" it which means that the package maintainer has recognized the submitrequest and will work on it but needs some time for checking until he can accept or decline the submitrequest. Currently it happened to me that while I was checking a submitrequest someone else "just accepted" it. I wished I could signal that I recognized the submitrequest and that I am working on it. In the end I mean what in bugzilla "assigned" means. Also for such recognized/assigned/taken submitrequests there should be a reasonable timeout (one week) until an accept or decline must happen. Afterwards others with permissions can step in to move things forward. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Tomáš Chvátal

14:16

Dne Čt 4. února 2016 15:07:56, Johannes Meixner napsal(a):

...

I wonder if it is possible for a package maintainer to neither accept or decline a submitrequest immediately but to immediately only "take" it which means that the package maintainer has recognized the submitrequest and will work on it but needs some time for checking until he can accept or decline the submitrequest.

You can add commentary about you doing the testing/review. Or add yourself as reviewer to the sr#. osc review add -U USERNAME SUBMISSION_ID But if you add yourself as reviewer then it gets hidden from all the other people until you approve it. Usually even just the comment for the others should be enough, also you can talk with them there. Cheers Tom -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Johannes Meixner

14:49

Hello Tomas, On Feb 4 15:16 Tomáš Chvátal wrote (excerpt):

...

Dne ?t 4. února 2016 15:07:56, Johannes Meixner napsal(a):

...
I wonder if it is possible for a package maintainer to neither accept or decline a submitrequest immediately but to immediately only "take" it which means that the package maintainer has recognized the submitrequest and will work on it but needs some time for checking until he can accept or decline the submitrequest.

You can add commentary about you doing the testing/review.

Probably it becomes now embarrassing: I do not know how to add only a comment to a request. Perhaps I am somehow blind or slow-witted but I cannot find it documented how to do that. "osc help request" only talks about accept, decline, revoke, reopen, setincident, supersede, approvenew, and priorize. I would like to do something like $ osc request comment -m 'jsmeix is working on it' REQUEST_ID without changing the request's state.

...

Or add yourself as reviewer to the sr#.

osc review add -U USERNAME SUBMISSION_ID

But if you add yourself as reviewer then it gets hidden from all the other people until you approve it.

I would like to have it open for all the other people so that they can follow what I am doing.

...

Usually even just the comment for the others should be enough, also you can talk with them there.

Yes. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg)

Tomáš Chvátal

15:30

Dne Čt 4. února 2016 15:49:09, Johannes Meixner napsal(a):

...

"osc help request" only talks about accept, decline, revoke, reopen, setincident, supersede, approvenew, and priorize.

I would like to do something like

$ osc request comment -m 'jsmeix is working on it' REQUEST_ID

without changing the request's state.

Completely understand. I have feeling this works only on web interface. There is hopefuly api to put it in osc. But nobody so far included adding comments to the command-line tool. I don't even see bugs on github about it so probably open a bug to github.com/openSUSE/osc and lets see how much briberies we need to give to OBS team to get it fixed ;-) HTH Tom -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Johannes Meixner

18:14

Hello, On Feb 4 16:30 Tomáš Chvátal wrote (excerpt):

...

Dne ?t 4. února 2016 15:49:09, Johannes Meixner napsal(a):

...
"osc help request" only talks about accept, decline, revoke, reopen, setincident, supersede, approvenew, and priorize.

I would like to do something like

$ osc request comment -m 'jsmeix is working on it' REQUEST_ID

without changing the request's state.

Completely understand. I have feeling this works only on web interface.

I found out right now that one can misuse $ echo y | request reopen -m 'a comment' REQUEST_ID to get a comment added with the little drawback that in the request history "Request got reopened" messages appear (regardless that the actual state was not changed). Somehow "request reopen -f -m 'a comment' REQUEST_ID" still asks one "The state of the request (#357769) is already 'new'. Change state anyway? [y/n]" regardless that "osc help request" reads "-f ... enforce state change" so that I use "echo y | ..." to get that question automatically answered. Misusing "osc request priorize" also works to some extent but $ osc request priorize -m 'a comment with dummy priority' REQUEST_ID moderate does not add a comment that is shown by "osc request show" (regardles that one is specified) but that comment is shown in the web interface. See https://build.opensuse.org/request/show/357769 Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg)

Johannes Meixner

3 Feb 3 Feb

08:30

Hello, On Feb 3 00:41 Wolfgang Rosenauer wrote (excerpt):

...

Following is a snippet from an SR for a package I'm maintaining into its devel project: (happened just today)

XXXXX created request about 8 hours ago YYYYY Request got accepted about 8 hours ago

I actually like that stuff does not lie around just because of lazy maintainers but is this really how it's supposed to work? It seems I simply should drop my maintainer role for this package.

Even better: Make YYYYY bugowner of that package. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Olaf Hering

09:59

On Wed, Feb 03, Johannes Meixner wrote:

...

On Feb 3 00:41 Wolfgang Rosenauer wrote (excerpt):

...
Following is a snippet from an SR for a package I'm maintaining into its devel project: (happened just today)

XXXXX created request about 8 hours ago YYYYY Request got accepted about 8 hours ago

I actually like that stuff does not lie around just because of lazy maintainers but is this really how it's supposed to work? It seems I simply should drop my maintainer role for this package.

Even better: Make YYYYY bugowner of that package.

That does not fix any bugs. Perhaps the UI needs to display that a given pkg in prj has a maintainer set. It could be as simple as converting the string "Accept" into "Accept even if I'm not listed as maintainer of $pkg".. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Henne Vogelsang

10:17

Hering, On 03.02.2016 10:59, Olaf Hering wrote:

...

Perhaps the UI needs to display that a given pkg in prj has a maintainer set. It could be as simple as converting the string "Accept" into "Accept even if I'm not listed as maintainer of $pkg"..

Feature requests belong to github[1] :-) Henne [1] https://github.com/openSUSE/open-build-service/issues -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Johannes Meixner

13:21

Hello, On Feb 3 10:59 Olaf Hering wrote (excerpt):

...

On Wed, Feb 03, Johannes Meixner wrote:

...
Make YYYYY bugowner of that package.

That does not fix any bugs.

That is not meant to fix bugs. It is meant to make YYYYY aware what it means when he "just accepts" changes for a package regardless that he is not the package maintainer. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andreas Färber

4 Feb 4 Feb

12:00

Hi, Am 03.02.2016 um 09:30 schrieb Johannes Meixner:

...

On Feb 3 00:41 Wolfgang Rosenauer wrote (excerpt):

...
Following is a snippet from an SR for a package I'm maintaining into its devel project: (happened just today)

XXXXX created request about 8 hours ago YYYYY Request got accepted about 8 hours ago

I actually like that stuff does not lie around just because of lazy maintainers but is this really how it's supposed to work? It seems I simply should drop my maintainer role for this package.

Even better: Make YYYYY bugowner of that package.

We had a similar issue in Virtualization (with a long list of maintainers), so to avoid incomplete qemu requests getting accepted (in particular .in file updates frequently missing) we set a Reviewer, so that if another Maintainer wants to accept an SR they get a warning. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; 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

3008

Age (days ago)

3010

Last active (days ago)

List overview

Download

26 comments

16 participants

participants (16)

Andreas Färber
Andrei Borzenkov
Bernhard Voelker
Henne Vogelsang
Jan Engelhardt
Jiri Slaby
Johannes Meixner
Marcus Meissner
Michal Kubecek
Olaf Hering
Ruediger Meier
Simon Lees
Stefan Seyfried
Takashi Iwai
Tomáš Chvátal
Wolfgang Rosenauer

[opensuse-factory] didn't we just discuss this? (maintainer role)

tags

participants (16)