Hi, I would like to propose disallowing packages to be owned by any group owner. Currently I am facing some issues with X packages merge-reviews. I see that some Xgl-maint peoples never cares to reply on bugzilla review where I can see at least one of them in CC'ed to that review bug. I also see pkgdb shows many co-owners for these X packages. I also like to say that there are few peoples(in xgl-maint group) who are really active and helped to finish merge-reviews. Please make such packages to be owned by some real person who should be responsible for changes in package.
On the contrary, I think we're moving towards having more packages that are owned by de-facto groups (such as the KDE sig, or similar.)
Perhaps what we need is to do something different for merge reviews than for package ownership in general?
Ownership vs comaintainership only affects bugzilla at this time. It works into the workflow of some groups which let the initial bugs go to a mailing list, then the bugs are triaged and assigned to specific people.
Merge reviews need to have a person on the other end willing to update the spec files. So maybe we wnat to make sure that all comaintainers are cc'd on the merge review bugs?
Adding meeting keyword to discuss in meeting tomorrow (2010-08-10).
FWIW, pretty much all the KDE packages are de-facto group-owned, even if there's a primary owner set.
I am not against having group as a owner/co-owner for any package as long as there are people to take care of its bugs. But how can package reviewer know who should be blamed (from that group members) for not responding on merge-review bug where I can see these people used to talk on IRC in their own official work timings?
I also see some kind of need to re-visit merge-reviews and update its bugzilla with current real owner and if we have working gitweb then its link to quickly go through devel spec for that package.
How can we say these reviews are not top priority[1] for maintainers who have no time to work on these minor spec cleanup issues but have time to regularly update packages for newer upstream releases?
NOTE:- I don't attend FESCo meetings as it used to happen at my sleeping time :)
[1]https://fedoraproject.org/wiki/Merge_Reviews#What_should_I_do_if_a_maintainer_is_non_responsive.3F
FYI, I also got no response from packages which are owned by one real person. IMHO, we should persuade all packagers to be active on bugzilla, contacting through provate email or IRC is not a easy way for end users.
Please add a policy that person who is reviewer cannot commit changes if maintainer allows him in merge-reviews.
'cannot' or 'can'?
ok here is what I understood that if i am reviewing package and its maintainer asked me to commit the patch provided by me, then I should not commit it as we need second set of eyes on package change.
I think you already said the same thing on devel list right? " Just saying that the person to commit the fixes found in the review should (IMO) not be the reviewer themselves, even if they happen to be a provenpackager. It allows for a having a second set of eyes on the changes in the case where the maintainer may not have responded."
My concern is the case where someone does the review, posts a change, and gets no response from the maintainer. In that case, I'd like another PP to do the commit. If the maintainer looks at the changes and says 'go for it', go for it.
I will certainly yield to FESCo as a whole if they say differently.
If I as the package maintainer review your patch and say it is fine, thats your second pair of eyes right there. At least in my view...
I agree with notting/mclasen. Shall we clarify this at the next meeting and then make sure docs changes are made?
Do FESCo thinks closure of x86info package merge-review without any review is good? yesterday maintainer closed it without any new comment.
No. We have stated that it is NOT ok for maintainers to close merge reviews unless they are finished.
I have re-opened that review.
AGREED: provenpackagers can commit changes to allow merge reviews to progress/be closed, as a courtesy they should post the diff to the merge review and wait a short time for maintainer to ack/commit it.
Does that resolve all the issues here?
Feel free to re-open or clarify if not.
It's really unfortunate that I have to open this ticket as I see FESCo member is committing some changes and closing his own merge-reviews. http://lists.fedoraproject.org/pipermail/package-review/2010-August/179435.html http://lists.fedoraproject.org/pipermail/package-review/2010-August/179437.html http://lists.fedoraproject.org/pipermail/package-review/2010-August/179432.html
I MUST have missed some last few meeting minutes to read on this that will allow owner of package to commit some changes and close merge-reviews(removing completely need of reviewer). Can someone please give me link to that meeting discussion then?
There wasn't anywhere I am aware of that allowed maintainers to close reviews.
I suspect Adam just was closing a bunch of bugs and forgot that these were merge reviews.
I would reopen them, then add a review and use provenpackager powers to clean up any remaining issues and then finish them off.
Parag: Whatever man. You reopened the bugs, you can close them when you think they're reviewed enough. I've closed merge reviews myself before and nobody seemed to care then, I don't know why you're caring now.
Please do review those and close them once they are fedora-review: +.
Thanks.
Dear FESCo, Please help me to find fixed xorg-x11-xauth build by ajax for further review as per his comment in https://bugzilla.redhat.com/show_bug.cgi?id=226648#c7
Replying to [comment:18 ajax]:
Ok so you agree we don't really need to follow any process to complete merge-reviews and still I see you are in oppose for any need of reviewer?
Replying to [comment:20 pnemade]:
Come on, we are not your lackeys. I assume you know how to use koji find-pkg
Replying to [comment:22 mclasen]:
Replying to [comment:20 pnemade]: Dear FESCo, Please help me to find fixed xorg-x11-xauth build by ajax for further review as per his comment in https://bugzilla.redhat.com/show_bug.cgi?id=226648#c7 Come on, we are not your lackeys. I assume you know how to use koji find-pkg
I am sorry for asking above but I actually used this link to see latest builds http://koji.fedoraproject.org/koji/packageinfo?packageID=847
I think koji UI has started behaving strangely for me then as its not showing me fc15 build.
Ok. Let me show you what am I getting for koji cli
koji latest-pkg dist-f15 xorg-x11-xauth Build Tag Built by
xorg-x11-xauth-1.0.2-7.fc12 dist-f14 jkeating
koji latest-pkg dist-f14 xorg-x11-xauth Build Tag Built by
Replying to [comment:21 pnemade]:
Replying to [comment:18 ajax]: Parag: Whatever man. You reopened the bugs, you can close them when you think they're reviewed enough. I've closed merge reviews myself before and nobody seemed to care then, I don't know why you're caring now. Ok so you agree we don't really need to follow any process to complete merge-reviews
Ok so you agree we don't really need to follow any process to complete merge-reviews
I think you have an addiction to formal process that isn't helpful. The important thing is that the packages get fixed. If we don't trust a provenpackager to fix packaging bugs, then who do we trust.
and still I see you are in oppose for any need of reviewer?
Review my work all you like. For that matter I've told you before that you can fix packaging issues in X without my prior consent, and you've even DONE IT. You seem to have forgotten.
Talking to you is an intensely frustrating experience. I'm inclined to stop doing it altogether.
Thanks for the build which I was expecting before closure of that merge-review. I am sorry that you see its frustrating. But yes I am addicted to official processes that fedora wiki taught me to follow.
I too like to stop this discussion now.
Just like to add one, hopefully productive thing to this, many reviewers do the review of a package in multiple steps. The reviewer takes a first look at the package, finds a few obvious mistakes, and adds the problems to the bug. If the package submitter is not active anymore, that's where this ends and the reviewer doesn't spend more of their time identifying more problems with a dead review. If the package submitter is active and quickly posts that the issues have been fixed, the package reviewer responds by doing a full review, knowing that their time is likely to not be wasted.
With this in mind, please take a moment to cool off and realize that you're just stepping on each other's expectations of how to efficiently run reviews rather than being driven by malice or pedantry.
Thanks, your friendly neighborhood be excellent to each other man.
Login to comment on this ticket.