Hi,
I know we have had this discussion/appeal before but it appears it has not reached everyone yet.
To those that have the power to accept SRs on the behalf of others please be so kind and give package maintainers at least a few days before you accept submit request.
What is the point of having individual package maintainers when those at the project maintainer or higher level simply accept submit requests for package that they do not really maintain?
This is a discouraging practice and unless as a project maintainer you have the intention to maintain all those packages in the project yourself I suggest you exercise restraint for a few days before you run that accept command.
Later, Robert
At Fri, 27 Mar 2015 02:50:08 -0400, Robert Schweikert wrote:
Hi,
I know we have had this discussion/appeal before but it appears it has not reached everyone yet.
To those that have the power to accept SRs on the behalf of others please be so kind and give package maintainers at least a few days before you accept submit request.
What is the point of having individual package maintainers when those at the project maintainer or higher level simply accept submit requests for package that they do not really maintain?
This is a discouraging practice and unless as a project maintainer you have the intention to maintain all those packages in the project yourself I suggest you exercise restraint for a few days before you run that accept command.
Well, I don't think waiting for a few days unconditionally is good, it'd just slow down the process without much gain. Majority of people assigned as package maintainer still ignore the requests unless they are project maintainers.
What I'd love to see instead is to mark each package whether it's actively maintained by package maintainer, or it's in a loose maintenance mode. In the former case, approval from package maintainer is mandatory. Then the project manager's job is to ping package maintainer if they don't react quickly enough (this can be well automated). In the latter case, you don't need to wait so much. Rather quick review and acceptance by project manager is a preferred action.
Just my $0.02.
Takashi
On Fri, 2015-03-27 at 11:33 +0100, Takashi Iwai wrote:
At Fri, 27 Mar 2015 02:50:08 -0400, Robert Schweikert wrote:
Hi,
I know we have had this discussion/appeal before but it appears it has not reached everyone yet.
To those that have the power to accept SRs on the behalf of others please be so kind and give package maintainers at least a few days before you accept submit request.
What is the point of having individual package maintainers when those at the project maintainer or higher level simply accept submit requests for package that they do not really maintain?
This is a discouraging practice and unless as a project maintainer you have the intention to maintain all those packages in the project yourself I suggest you exercise restraint for a few days before you run that accept command.
Well, I don't think waiting for a few days unconditionally is good, it'd just slow down the process without much gain. Majority of people assigned as package maintainer still ignore the requests unless they are project maintainers.
For the package I care that strongly, I set myself as reviewer. Project maintainers do have the power to ignore this, but so far I have to say, I didn't see anybody doing this (which is good).
My recommendation is: - Project maintainers are there to maintain the ENTIRE project (meta data incl. packages) - Package maintainers are limited to a specific package / group of packages. But they are not on their own - If a package maintainer commits sufficiently to be 'the only responsible', he should mark himself as reviewer of the package
- project maintainers that don't care for the content of the entire project should add themselves as maintainer of the packages they care for and remove themselves from the list of project maintainers.
- a package maintainer, that did not ask for explicit review by himself, once something 'against his ideas' is checked in, is free/welcome to discuss with the sumitter/accepter and revert the change (webui makes that terribly easy: revisions view, revert to this revision)
Some projects have 20 project maintainers, and each cares for one package... That's misleading in every aspect.
Cheers, Dominique
On March 27, 2015 6:42:46 AM EDT, Dimstar / Dominique Leuenberger dimstar@opensuse.org wrote:
On Fri, 2015-03-27 at 11:33 +0100, Takashi Iwai wrote:
At Fri, 27 Mar 2015 02:50:08 -0400, Robert Schweikert wrote:
Hi,
I know we have had this discussion/appeal before but it appears it has not reached everyone yet.
To those that have the power to accept SRs on the behalf of others please be so kind and give package maintainers at least a few days before you accept submit request.
What is the point of having individual package maintainers when those at the project maintainer or higher level simply accept submit requests for package that they do not really maintain?
This is a discouraging practice and unless as a project maintainer you have the intention to maintain all those packages in the project yourself I suggest you exercise restraint for a few days before you run that accept command.
Well, I don't think waiting for a few days unconditionally is good, it'd just slow down the process without much gain. Majority of people assigned as package maintainer still ignore the requests unless they are project maintainers.
For the package I care that strongly, I set myself as reviewer. Project maintainers do have the power to ignore this, but so far I have to say, I didn't see anybody doing this (which is good).
My recommendation is:
- Project maintainers are there to maintain the ENTIRE project (meta
data incl. packages)
- Package maintainers are limited to a specific package / group of
packages. But they are not on their own
- If a package maintainer commits sufficiently to be 'the only
responsible', he should mark himself as reviewer of the package
- project maintainers that don't care for the content of the entire
project should add themselves as maintainer of the packages they care for and remove themselves from the list of project maintainers.
- a package maintainer, that did not ask for explicit review by
himself, once something 'against his ideas' is checked in, is free/welcome to discuss with the sumitter/accepter and revert the change (webui makes that terribly easy: revisions view, revert to this revision)
Some projects have 20 project maintainers, and each cares for one package... That's misleading in every aspect.
Cheers, Dominique
If the reviewer flag is easily automated into the review notification process (or already has been) I strongly endorse more active use of that flag.
Particularly when I was a newbie maintainer I would be a package maintainer of new packages I submitted but I would not have felt comfortable reviewing other's SRs.
Thus the idea of having an actively used flag saying I review SRs for a package separate from the maintainer flag makes a tremendous amount of sense to me.
Greg
Hello,
On Mar 27 11:42 Dimstar / Dominique Leuenberger wrote (excerpt):
Some projects have 20 project maintainers, and each cares for one package... That's misleading in every aspect.
As far as I know that's how it was set up (automatically?) from the very beginning and that does not change automatically.
Kind Regards Johannes Meixner
On Freitag, 27. März 2015, 11:42:46 wrote Dimstar / Dominique Leuenberger:
On Fri, 2015-03-27 at 11:33 +0100, Takashi Iwai wrote:
At Fri, 27 Mar 2015 02:50:08 -0400, Robert Schweikert wrote:
Hi,
I know we have had this discussion/appeal before but it appears it has not reached everyone yet.
To those that have the power to accept SRs on the behalf of others please be so kind and give package maintainers at least a few days before you accept submit request.
What is the point of having individual package maintainers when those at the project maintainer or higher level simply accept submit requests for package that they do not really maintain?
This is a discouraging practice and unless as a project maintainer you have the intention to maintain all those packages in the project yourself I suggest you exercise restraint for a few days before you run that accept command.
Well, I don't think waiting for a few days unconditionally is good, it'd just slow down the process without much gain. Majority of people assigned as package maintainer still ignore the requests unless they are project maintainers.
For the package I care that strongly, I set myself as reviewer. Project maintainers do have the power to ignore this, but so far I have to say, I didn't see anybody doing this (which is good).
My recommendation is:
- Project maintainers are there to maintain the ENTIRE project (meta
data incl. packages)
- Package maintainers are limited to a specific package / group of
packages. But they are not on their own
- If a package maintainer commits sufficiently to be 'the only
responsible', he should mark himself as reviewer of the package
I do not understand that part, you want to be the maintainer additionaly be reviewer in a package in some devel project? What does this help you? Isn't it more a burden to accept first the review and afterwards the request?
- project maintainers that don't care for the content of the entire
project should add themselves as maintainer of the packages they care for and remove themselves from the list of project maintainers.
- a package maintainer, that did not ask for explicit review by
himself, once something 'against his ideas' is checked in, is free/welcome to discuss with the sumitter/accepter and revert the change (webui makes that terribly easy: revisions view, revert to this revision)
Some projects have 20 project maintainers, and each cares for one package... That's misleading in every aspect.
This is okay, if all of them do really take care of all packages. eg. KDE people work that way and that is quite okay from my POV.
But, yes, people should not be project maintainer if they do not take care of all projects.
Btw, while I think the OBS notification mails improved a lot last year, it is of course also okay to work via the pull model.
You see always all open tasks for you in
- the webui on top right (X tasks)
or by running
- osc my
All open requests for you and also wanted maintenance updates are listed here.
On Fri, 2015-03-27 at 14:42 +0100, Adrian Schröter wrote:
For the package I care that strongly, I set myself as reviewer.
Project maintainers do have the power to ignore this, but so far I have to say, I didn't see anybody doing this (which is good).
My recommendation is:
- Project maintainers are there to maintain the ENTIRE project
(meta data incl. packages)
- Package maintainers are limited to a specific package / group of
packages. But they are not on their own
- If a package maintainer commits sufficiently to be 'the only
responsible', he should mark himself as reviewer of the package
I do not understand that part, you want to be the maintainer additionaly be reviewer in a package in some devel project? What does this help you? Isn't it more a burden to accept first the review and afterwards the request?
In some cases this makes sense; e.g vlc in multimedia:libs: whereas I like the fact that other people contribute, this has much more impact than people tend to see. so I added myself as reviewer, despite being maintainer.
It gives the project maintainers, which do a fabulous job accepting packages, a hint that 'ey, this is NOT something I should accept without asking back'
if I want to check it in, I am perfectly happy in taking the extra step to either accept the review first or confirm on checkin that there are open reviews.
OBS could actually improve there: if the only open reviews to handle are of the user that is performing the accept, it is of little use to ask him...
Maybe this is a special case setup; but it has the exact effect people are looking for.
At Fri, 27 Mar 2015 14:42:59 +0100, Adrian Schröter wrote:
On Freitag, 27. März 2015, 11:42:46 wrote Dimstar / Dominique Leuenberger:
On Fri, 2015-03-27 at 11:33 +0100, Takashi Iwai wrote:
At Fri, 27 Mar 2015 02:50:08 -0400, Robert Schweikert wrote:
Hi,
I know we have had this discussion/appeal before but it appears it has not reached everyone yet.
To those that have the power to accept SRs on the behalf of others please be so kind and give package maintainers at least a few days before you accept submit request.
What is the point of having individual package maintainers when those at the project maintainer or higher level simply accept submit requests for package that they do not really maintain?
This is a discouraging practice and unless as a project maintainer you have the intention to maintain all those packages in the project yourself I suggest you exercise restraint for a few days before you run that accept command.
Well, I don't think waiting for a few days unconditionally is good, it'd just slow down the process without much gain. Majority of people assigned as package maintainer still ignore the requests unless they are project maintainers.
For the package I care that strongly, I set myself as reviewer. Project maintainers do have the power to ignore this, but so far I have to say, I didn't see anybody doing this (which is good).
My recommendation is:
- Project maintainers are there to maintain the ENTIRE project (meta
data incl. packages)
- Package maintainers are limited to a specific package / group of
packages. But they are not on their own
- If a package maintainer commits sufficiently to be 'the only
responsible', he should mark himself as reviewer of the package
I do not understand that part, you want to be the maintainer additionaly be reviewer in a package in some devel project? What does this help you? Isn't it more a burden to accept first the review and afterwards the request?
My understanding is that the point is that this makes the review by this maintainer mandatory for acceptance. Otherwise the project manager may pick up the change without package maintainer's review.
Takashi
At Fri, 27 Mar 2015 11:42:46 +0100, Dimstar / Dominique Leuenberger wrote:
On Fri, 2015-03-27 at 11:33 +0100, Takashi Iwai wrote:
At Fri, 27 Mar 2015 02:50:08 -0400, Robert Schweikert wrote:
Hi,
I know we have had this discussion/appeal before but it appears it has not reached everyone yet.
To those that have the power to accept SRs on the behalf of others please be so kind and give package maintainers at least a few days before you accept submit request.
What is the point of having individual package maintainers when those at the project maintainer or higher level simply accept submit requests for package that they do not really maintain?
This is a discouraging practice and unless as a project maintainer you have the intention to maintain all those packages in the project yourself I suggest you exercise restraint for a few days before you run that accept command.
Well, I don't think waiting for a few days unconditionally is good, it'd just slow down the process without much gain. Majority of people assigned as package maintainer still ignore the requests unless they are project maintainers.
For the package I care that strongly, I set myself as reviewer. Project maintainers do have the power to ignore this, but so far I have to say, I didn't see anybody doing this (which is good).
My recommendation is:
- Project maintainers are there to maintain the ENTIRE project (meta
data incl. packages)
- Package maintainers are limited to a specific package / group of
packages. But they are not on their own
- If a package maintainer commits sufficiently to be 'the only
responsible', he should mark himself as reviewer of the package
- project maintainers that don't care for the content of the entire
project should add themselves as maintainer of the packages they care for and remove themselves from the list of project maintainers.
- a package maintainer, that did not ask for explicit review by
himself, once something 'against his ideas' is checked in, is free/welcome to discuss with the sumitter/accepter and revert the change (webui makes that terribly easy: revisions view, revert to this revision)
Slightly off-topic, about this revert commit work flow: Currently the forward to FACTORY is set as default at SR acceptance. This is good in one side, but also bad in another side, especially when such a revert may happen. Luckily, we have now FACTORY staging, so the impact became much less than before. But I still feel sometimes uneasy by impact of push back.
Takashi
On Fri, 2015-03-27 at 14:53 +0100, Takashi Iwai wrote:
I do not understand that part, you want to be the maintainer
additionaly be reviewer in a package in some devel project? What does this help you? Isn't it more a burden to accept first the review and afterwards the request?
My understanding is that the point is that this makes the review by this maintainer mandatory for acceptance. Otherwise the project manager may pick up the change without package maintainer's review.
As project maintainer (or also other package maintainer) you CAN override the open reviews; as well as it does not protect you from any other package maintainer / project maintainer to do direct changes on a package, not passing through submit requests... but it's better than the current situation where a package maintainer cares enough and is overruled, as prj maintainers are not aware of each package and each maintainers schedules.
Blaming the Prj Maintainers to do 'their' tasks is not the way to go hrere.
On 03/27/2015 10:00 AM, Dimstar / Dominique Leuenberger wrote: <snip>
Blaming the Prj Maintainers to do 'their' tasks is not the way to go hrere.
Blame in this case is certainly a strong choice of words. I wouldn't go down that direction. There is really no one to blame.
All I am asking for is a little restraint. Give the package maintainer some time to do the job before accepting requests. I am a project maintainer in devel:perl project and make it a point not to accept SRs for packages where I am not also the maintainer unless they are maybe a week old. This gives the package maintainer a chance to take a look at the SR first. And we can certainly argue whether a week is sufficient.
From my point of view that is common sense. As a project maintainer I do
not know the intricacy of all packages in the project. Thus, package maintainers should get a first shot at the review.
I personally find it demotivating when I sign up to maintain a package and then someone else simply pulls the trigger on accepting requests.
Later, Robert
On Friday 2015-03-27 14:42, Adrian Schröter wrote:
- If a package maintainer commits sufficiently to be 'the only
responsible', he should mark himself as reviewer of the package
I do not understand that part, you want to be the maintainer additionaly be reviewer in a package in some devel project? What does this help you? Isn't it more a burden to accept first the review and afterwards the request?
Yes, it is an additional burden. But because the role model in OBS has not been changed despite calls from Robert and others in over three years — and not everybody is a developer, so don't call for patches just yet —, using the role "review" to limit the overwhelming power of the prj-level role "maintainer" is what we are left with.
You see always all open tasks for you in
- the webui on top right (X tasks)
or by running
- osc my
It is a little inconsistent. `osc my pkg` shows only packages where one is explicitly maintainer (i.e. no inheritance), while `osc my rq` shows requests for all packages (maintainer inherited).
Takashi Iwai tiwai@suse.de writes:
What I'd love to see instead is to mark each package whether it's actively maintained by package maintainer, or it's in a loose maintenance mode.
A package maintainer who doesn't actively maintain the package should step down as a package maintainer.
Andreas.
-
Adrian Schröter -
Andreas Schwab -
Dimstar / Dominique Leuenberger -
greg.freemyer＠gmail.com -
Jan Engelhardt -
Johannes Meixner -
Robert Schweikert -
Takashi Iwai