Re: merge reviews
On Sun, 18 Jul 2010 00:45:40 +0100 Richard Fearn richardfe...@gmail.com wrote: I'm a bit late joining this discussion, but did notice a couple of issues relating to review request links. One of the links on spot's Package Review Process page (https://fedoraproject.org/wiki/Package_Review_Process) doesn't work - the Review Tracker equivalent to Packages Currently Under Review (it links to REVIEW.html but that doesn't exist). Odd. it works fine here. Which exact link? http://fedoraproject.org/PackageReviewStatus/REVIEW.html ? Oh, I see... it's not updating. Right. Perhaps someone with more power than me could get this REVIEW.html page working again :-) I can take a look... tibbs is out of country. I just made a couple of tweaks to the Join page: https://fedoraproject.org/w/index.php?title=Join_the_package_collection_maintainersdiff=186902oldid=185877 https://fedoraproject.org/w/index.php?title=Join_the_package_collection_maintainersdiff=186903oldid=186902 which makes the two sections more consistent. There still seems to be unnecessary duplication, though: they both say that you should check that the package is new. I was thinking of getting rid of this duplication - can I go ahead and make this (fairly minor) change? Sounds fine to me. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
Hi, One of the links on spot's Package Review Process page (https://fedoraproject.org/wiki/Package_Review_Process) doesn't work - the Review Tracker equivalent to Packages Currently Under Review (it links to REVIEW.html but that doesn't exist). Odd. it works fine here. Which exact link? http://fedoraproject.org/PackageReviewStatus/REVIEW.html ? That's the one. Oh, I see... it's not updating. Right. I get a 404 when accessing it. The page says Sorry! We couldn't find that file. I was thinking of getting rid of this duplication - can I go ahead and make this (fairly minor) change? Sounds fine to me. OK, I'll do it. Regards, Rich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
I just made a couple of tweaks to the Join page: https://fedoraproject.org/w/index.php?title=Join_the_package_collection_maintainersdiff=186902oldid=185877 https://fedoraproject.org/w/index.php?title=Join_the_package_collection_maintainersdiff=186903oldid=186902 which makes the two sections more consistent. There still seems to be unnecessary duplication, though: they both say that you should check that the package is new. I was thinking of getting rid of this duplication - can I go ahead and make this (fairly minor) change? Sounds fine to me. Now done: https://fedoraproject.org/w/index.php?title=Join_the_package_collection_maintainersdiff=187036oldid=186903 I also moved a couple of items up, as I think it makes sense to check retired packages and forbidden items at the same time as checking existing packages and those being reviewed. Rich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
Michael Schwendt wrote: For each of the packages, assign its package owner(s) to the review ticket, let them perform the review themselves according to Fedora's Review Guidelines and when done, set the fedora-review flag to '?' and move the ticket to a final tracker. In other words, let the owners of these packages indicate that they have (re-)reviewed their own package. Fedora package maintainers must be aware of the packaging guidelines anyway when they touch their package spec files, and they also need to repeat several checks whenever they includes upgrades (e.g. checking for license changes or added code/libs with legal problems). I think such a process would be generally useful, not just for merge reviews (but also for new packages). There must be some group of packagers who we can trust to know the packaging guidelines (provenpackagers? sponsors?), if we can prove that we went through the review checklist for a package, why is it a problem if it was our own package we were reviewing? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Sat, Jul 10, 2010 at 7:19 PM, Kevin Kofler kevin.kof...@chello.at wrote: Michael Schwendt wrote: For each of the packages, assign its package owner(s) to the review ticket, let them perform the review themselves according to Fedora's Review Guidelines and when done, set the fedora-review flag to '?' and move the ticket to a final tracker. In other words, let the owners of these packages indicate that they have (re-)reviewed their own package. Fedora package maintainers must be aware of the packaging guidelines anyway when they touch their package spec files, and they also need to repeat several checks whenever they includes upgrades (e.g. checking for license changes or added code/libs with legal problems). I think such a process would be generally useful, not just for merge reviews (but also for new packages). There must be some group of packagers who we can trust to know the packaging guidelines (provenpackagers? sponsors?), if we can prove that we went through the review checklist for a package, why is it a problem if it was our own package we were reviewing? Reviewing your own package is kind of pointless, the purpose of the review is to have *someone else* to look at the package to spot mistakes that you might have made; being a provenpackager or a sponser does not change the fact that you are a human and humans *do* make mistakes. It is generally easier to spot mistakes in someone else's work than in your own. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Thu, Jul 08, 2010 at 05:23:40PM -0700, Adam Williamson wrote: On Thu, 2010-07-08 at 14:28 -0600, Kevin Fenzi wrote: Greetings Fedora developers... c) Just leave them open and let people pick pick pick away at them a few at a time? We might be done by Fedora20. Or perhaps not. Does the existence of a bunch of open merge reviews cause any actual harm or trouble to anyone besides people who like to compile lists of open bugs and then stare at them glumly? =) If not, then option c) seems perfectly fine to me. To me the problem with the merge reviews has always been when there's no response from the package maintainer. Having the package in the repository and having a merge review open but not seeing any reviewer action is not making anything worse than it already is. But having a reviewer spend time commenting on a merge review and not having the maintainer pick up the changes is discouraging to the reviewers. With that in mind, Kevin's option to kick out packages that don't have a merge review completed has merit; all of a sudden it motivates the package maintainers to pay attention to their merge reviews. However, I think that's a bit too chaotic for producing an orderly distro. Perhaps instead, we should pick a list of packages each Fedora release and kick them out unless their merge reviews are completed. Since we're starting almost at the Alpha for this cycle, perhaps we should either do fewer packages or just leaf packages this time around. A different sort of idea would be to select a list of packages that we want to definitely get reviewed in time for the next release. Then when a reviewer steps up to take the packages, also assign a provenpackager. If the package maintainers aren't active on the merge review, the provenpackager commits the changes to the packages. -Toshio pgpMENkWT1J1i.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On 07/09/2010 03:41 AM, Jussi Lehtola wrote: I started doing merge reviews in late 2008, so far I've finished 24 of them and have 8 reviews currently still open. The biggest problem so far has been the lack of maintainer interest, often nothing has happened after my comments. For the major part a lot of BZ pings and mails to package-ow...@fedoraproject.org has done the trick, but some bugs have been awfully silent. If you are a provenpackager, can't you just make the changes yourself and close the review request? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Thu, 8 Jul 2010 14:28:13 -0600, Kevin wrote: So, here we are today with 242 still open merge reviews: http://fedoraproject.org/PackageReviewStatus/MERGE.html (Plus a few that were closed when they shouldn't have been). Dumb question first: Where could I have found the URL of that page? Several reviewers I know use the cached tracker page, which explicitly does NOT include the old merge reviews: http://fedoraproject.org/PackageReviewStatus/NEW.html And that one is linked directly on the Package Review Process page: https://fedoraproject.org/wiki/Package_Review_Process#Tracking_of_Package_Requests So, what do we do? For each of the packages, assign its package owner(s) to the review ticket, let them perform the review themselves according to Fedora's Review Guidelines and when done, set the fedora-review flag to '?' and move the ticket to a final tracker. In other words, let the owners of these packages indicate that they have (re-)reviewed their own package. Fedora package maintainers must be aware of the packaging guidelines anyway when they touch their package spec files, and they also need to repeat several checks whenever they includes upgrades (e.g. checking for license changes or added code/libs with legal problems). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On 07/09/2010 01:19 AM, Toshio Kuratomi wrote: On Thu, Jul 08, 2010 at 05:23:40PM -0700, Adam Williamson wrote: On Thu, 2010-07-08 at 14:28 -0600, Kevin Fenzi wrote: Greetings Fedora developers... c) Just leave them open and let people pick pick pick away at them a few at a time? We might be done by Fedora20. Or perhaps not. Does the existence of a bunch of open merge reviews cause any actual harm or trouble to anyone besides people who like to compile lists of open bugs and then stare at them glumly? =) If not, then option c) seems perfectly fine to me. To me the problem with the merge reviews has always been when there's no response from the package maintainer. Having the package in the repository and having a merge review open but not seeing any reviewer action is not making anything worse than it already is. But having a reviewer spend time commenting on a merge review and not having the maintainer pick up the changes is discouraging to the reviewers. That's been my biggest problem as well. I currently have several open, many of which used to be F7blockers. Some maintainers are great, responsive, etc. Others. . .nothing. Sometimes ownership will change, and they won't get CCd on the bug. Other times, I'll go into pkgdb, find the new owner, and CC them. Still nothing. I think once I even had a maintainer un-CC themselves from the bug, without comment. I'm a ProvenPackager, but I'm not sure what the call should be on whether we should commit the fixes ourselves. In some cases, I'm not sure what the appropriate fix is, which is why I need maintainer input. The above is why I stopped doing new merge reviews. This is very important work (including the kernel review), but without buy-in from the maintainers it can't get done. If I had a RH org chart I guess I could nag people's supervisors or something, but I really don't want to do that. Is Unresponsive Maintainer a good way to go, possibly? -J With that in mind, Kevin's option to kick out packages that don't have a merge review completed has merit; all of a sudden it motivates the package maintainers to pay attention to their merge reviews. However, I think that's a bit too chaotic for producing an orderly distro. Perhaps instead, we should pick a list of packages each Fedora release and kick them out unless their merge reviews are completed. Since we're starting almost at the Alpha for this cycle, perhaps we should either do fewer packages or just leaf packages this time around. A different sort of idea would be to select a list of packages that we want to definitely get reviewed in time for the next release. Then when a reviewer steps up to take the packages, also assign a provenpackager. If the package maintainers aren't active on the merge review, the provenpackager commits the changes to the packages. -Toshio -- - in your fear, speak only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Thu, 8 Jul 2010 19:47:41 -0400 Jeff Garzik jgar...@pobox.com wrote: Cute re-ordering of events, there. No, after repeated experiences with seeking reviews, including this most recent one mentioned elsewhere on this list, and seeing others on this list repeating review requests, I was inspired to poke around to see why responses were so uneven. IMHO, lack of reviewer manpower and some people dumping large numbers of reviews into the queue without contributing reviews back. Looking at the process with fresh eyes, starting from https://fedoraproject.org/wiki/PackageReviewProcess and moving to https://fedoraproject.org/wiki/PackageMaintainers/ReviewRequests one sees a chaotic mess of package reviews, both assigned and unassigned, not really moving forward at all. Looking closely, you see a lot of packages that seem of worth, but that set is crowded by review requests for ancient packages like redhat-menus or kernel. Yeah, as mentioned, try: http://fedoraproject.org/PackageReviewStatus/ instead. I think I have changed the wiki to point to this instead, but if you spot it still listed, please change it. In an ideal world, every package in fedora/devel would get a full package re-review prior to each release. But with finite resources limiting that, it seemed to me that triaging long-dead bugs for long-merged packages was a reasonable and helpful thing for the Fedora project. By all appearances, nobody else was bothering with these things after several years went by. Yeah, I agree that ideally we would be able to re-review existing packages, but sadly, the manpower is just not there currently. I don't think triaging merge reviews is a good idea though. They aren't harming anyone, and slowly people are doing them, so why not let them stay? If people want these obviously unloved, ignored review requests -- not even an rpmlint or ping in many cases -- to stick around, that's fine with me. I thought I was being helpful, but easy enough to leave things alone as well. Thanks. I would like for us to come up with some kind of plan for these, but nothing is decided yet. It's best IMHO to leave them open for now. My hail review was proceeding, and I wanted to make the process a bit easier for the -next- person wanting a review. Apologies for the ruffled feathers. No worries. The process itself is intimidating, because the wikis demand that a prospective reviewer wade into a completely unorganized swamp (BZ URLs linked-to from above URLs), hundreds of review requests, with next to zero information about where one's review would be most helpful. To an outsider, it must seem like quite a mess, with completely unknown chances for success/failure. Yeah, we could look at organizing some more for sure. There was a Package review sig that tried to start up at one point, but as far as I know it never got anywhere. Perhaps things like using priority/severity would be nice... you could then mark reviews that are needed for new features as high, or things that are leaf nodes as low, etc. Anyhow, more things to try and work on. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Fri, 9 Jul 2010 10:19:14 +0200 Michael Schwendt mschwe...@gmail.com wrote: On Thu, 8 Jul 2010 14:28:13 -0600, Kevin wrote: So, here we are today with 242 still open merge reviews: http://fedoraproject.org/PackageReviewStatus/MERGE.html (Plus a few that were closed when they shouldn't have been). Dumb question first: Where could I have found the URL of that page? Several reviewers I know use the cached tracker page, which explicitly does NOT include the old merge reviews: http://fedoraproject.org/PackageReviewStatus/NEW.html And that one is linked directly on the Package Review Process page: https://fedoraproject.org/wiki/Package_Review_Process#Tracking_of_Package_Requests Yeah, perhaps that should link to http://fedoraproject.org/PackageReviewStatus ? Or both that and NEW? For each of the packages, assign its package owner(s) to the review ticket, let them perform the review themselves according to Fedora's Review Guidelines and when done, set the fedora-review flag to '?' and move the ticket to a final tracker. In other words, let the owners of these packages indicate that they have (re-)reviewed their own package. Interesting idea. I fear we might get some maintainers who just want the merge review to go away to just say reviewed it, everything is great - fedora-review + without really checking anything. Fedora package maintainers must be aware of the packaging guidelines anyway when they touch their package spec files, and they also need to repeat several checks whenever they includes upgrades (e.g. checking for license changes or added code/libs with legal problems). Indeed. Might be worthwhile to try it out... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Fri, 2010-07-09 at 12:55 +0530, Rahul Sundaram wrote: On 07/09/2010 03:41 AM, Jussi Lehtola wrote: I started doing merge reviews in late 2008, so far I've finished 24 of them and have 8 reviews currently still open. The biggest problem so far has been the lack of maintainer interest, often nothing has happened after my comments. For the major part a lot of BZ pings and mails to package-ow...@fedoraproject.org has done the trick, but some bugs have been awfully silent. If you are a provenpackager, can't you just make the changes yourself and close the review request? I asked about this a year(?) ago when I became sponsor. The consensus in FESCo was back then that the reviewer making the changes would go against the whole idea of reviewing, which involves two people (the maintainer and the reviewer) going through the changes. Having a provenpackager replacing the maintainer would be possible in principle, but the merge review may in some cases involve rather drastic changes that should be not made by other people than the maintainer. Besides, it's the maintainer's work anyhow.. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
Jeff Garzik (jgar...@pobox.com) said: Cute re-ordering of events, there. No, after repeated experiences with seeking reviews, including this most recent one mentioned elsewhere on this list, and seeing others on this list repeating review requests, I was inspired to poke around to see why responses were so uneven. OK. I apologize for the insinuation. Looking at the process with fresh eyes, starting from https://fedoraproject.org/wiki/PackageReviewProcess and moving to https://fedoraproject.org/wiki/PackageMaintainers/ReviewRequests one sees a chaotic mess of package reviews, both assigned and unassigned, not really moving forward at all. Looking closely, you see a lot of packages that seem of worth, but that set is crowded by review requests for ancient packages like redhat-menus or kernel. I wonder if a better way to sort this is bottom-up... you could argue that the older the review ticket, the 'less important' the package is (as if it was a critical need, it would have been reviewed.) project. By all appearances, nobody else was bothering with these things after several years went by. Yes, that's a problem. We've had two sets of issues here: 1) No one does the merge reviews 2) Merge reviews that were done were never applied by the maintainers #2 sort of fed #1. In any case, as trying to be part of the solution, I finished off one merge review last night. I'll see if I can manage to do one a week myself... if we could get some group of packagers (sponsors, maybe?) to do the same, we might cut this down pretty quickly. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Thu, Jul 08, 2010 at 02:28:13PM -0600, Kevin Fenzi wrote: c) Just leave them open and let people pick pick pick away at them a few at a time? We might be done by Fedora20. Or perhaps not. f) Make a concerted push to clear the NEEDSPONSOR blocker. Get all those folks sponsored and ask them all to do a few merge reviews. I like these the most. A concerted push to clear NEEDSPONSOR would be good anyhow. Btw. in case someone is looking to sponsor someone but did not find someone who is ready, I would sponsor this one, if I currently had more time to re-familiarize myself with the packaging guidelines: https://bugzilla.redhat.com/show_bug.cgi?id=531544 b) Try and make some kind of concerted effort to get the last 242 done? We would need both people willing to review and maintainers willing to commit changes and get things completed. The problem with this one is that the maintainers are often not that much into reviews. Maybe we can do this and allow provenpackagers to commit the fixes and then have an action week to clear the NEEDSPONSOR blocker and the merge reviews and e.g. another week later an action day to allow provenpackagers to address all unhandled issues. Regards Till pgppPt7E2QuvN.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
Am Thu, 08 Jul 2010 22:51:57 +0200 schrieb Till Maas opensou...@till.name: On Thu, Jul 08, 2010 at 02:28:13PM -0600, Kevin Fenzi wrote: c) Just leave them open and let people pick pick pick away at them a few at a time? We might be done by Fedora20. Or perhaps not. f) Make a concerted push to clear the NEEDSPONSOR blocker. Get all those folks sponsored and ask them all to do a few merge reviews. I like these the most. A concerted push to clear NEEDSPONSOR would be good anyhow. Btw. in case someone is looking to sponsor someone but did not find someone who is ready, I would sponsor this one, if I currently had more time to re-familiarize myself with the packaging guidelines: https://bugzilla.redhat.com/show_bug.cgi?id=531544 b) Try and make some kind of concerted effort to get the last 242 done? We would need both people willing to review and maintainers willing to commit changes and get things completed. The problem with this one is that the maintainers are often not that much into reviews. Maybe we can do this and allow provenpackagers to commit the fixes and then have an action week to clear the NEEDSPONSOR blocker and the merge reviews and e.g. another week later an action day to allow provenpackagers to address all unhandled issues. Big +1. Count me in with helping to review and fix all unhandled issues... Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Thu, Jul 8, 2010 at 4:28 PM, Kevin Fenzi ke...@scrye.com wrote: So, here we are today with 242 still open merge reviews: http://fedoraproject.org/PackageReviewStatus/MERGE.html (Plus a few that were closed when they shouldn't have been). So, what do we do? Some possible options: a) Just close them all, any bugs in spec files in those packages can be filed as bugs against them. /RH employee hat off Fedora contributor hat on After a large survey, it is readily apparent that many of these 242 have been untouched for -years-, for packages that have been merged into Fedora and used happily for -years-. Further hundreds of other reviews outside your 242 are listed as assigned to a reviewer, but making no progress after multiple years. These merges are crowding out new packages that need merging, on bugzilla's list of packages that need a review. As such, getting any package into Fedora requires navigating an informal, ever-changing process, where the chief attributes for success involve (a) knowing a Red Hat employee or (b) public, sometimes repeated begging on fedora devel. The results are highly uneven, and not necessarily directly related to the technical attributes of benefit to the Fedora Project. Closing a 3-year-old merge review of the kernel package is reasonable bug triage. It's not like the kernel package will get un-merged. The proper course of action for already-merged packages is to file bugs against those packages. We have an entire -team- of people looking at kernel bugs, while this silly merge review: kernel sits, ignored, for several years. The current package review system is failing miserably at separating wheat from chaff, is very chaotic, and non-deterministic. Merge review: kernel is pure noise. Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Thu, 2010-07-08 at 14:28 -0600, Kevin Fenzi wrote: So, here we are today with 242 still open merge reviews: http://fedoraproject.org/PackageReviewStatus/MERGE.html (Plus a few that were closed when they shouldn't have been). So, what do we do? Some possible options: a) Just close them all, any bugs in spec files in those packages can be filed as bugs against them. b) Try and make some kind of concerted effort to get the last 242 done? We would need both people willing to review and maintainers willing to commit changes and get things completed. Just a few comments. First of all, option a) is IMHO out of the question. 242 reviews is not that much. Maybe people have not been aware so far that Merge Reviews exist and can be performed by anyone in the packagers group. This discussion should raise awareness about the fact. The work needed for the review depends, though, a lot on the nature of the package. The further down the pile we go, the more work there is per package: the spec files of say gcc, kernel or OpenOffice.org are rather daunting. I started doing merge reviews in late 2008, so far I've finished 24 of them and have 8 reviews currently still open. The biggest problem so far has been the lack of maintainer interest, often nothing has happened after my comments. For the major part a lot of BZ pings and mails to package-ow...@fedoraproject.org has done the trick, but some bugs have been awfully silent. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
Jeff Garzik (jgar...@pobox.com) said: After a large survey, it is readily apparent that many of these 242 have been untouched for -years-, for packages that have been merged into Fedora and used happily for -years-. Further hundreds of other reviews outside your 242 are listed as assigned to a reviewer, but making no progress after multiple years. These merges are crowding out new packages that need merging, on bugzilla's list of packages that need a review. That logically does not follow. If they're not being touched, and not making progress, then there's obviously no review resources being spent on them, which means they're not taking anything away from the review resources for other new packages. (We're still having a good number of new packages approved each week.) As such, getting any package into Fedora requires navigating an informal, ever-changing process, where the chief attributes for success involve (a) knowing a Red Hat employee or (b) public, sometimes repeated begging on fedora devel. ... how is it ever-changing? The review and sponsorship process has been relatively static for a long time. Yes, sometimes you have to request reviewers, or swap reviews, but that's been the case for quite a while. The proper course of action for already-merged packages is to file bugs against those packages. We have an entire -team- of people looking at kernel bugs, while this silly merge review: kernel sits, ignored, for several years. Except you'll need to have some sort of tracking of packages which haven't yet been processed looking for these bugs, so people know what packages to look at first. Which then ends up looking an awful lot like the current merge review list. The current package review system is failing miserably at separating wheat from chaff, is very chaotic, and non-deterministic. Merge review: kernel is pure noise. I'd like not to assume the worst, but given your mass closing of some review bugs, plus your arguments here about why, plus your request for a review swap earlier, I'm having trouble reading this as anything other than a transparent frustration at your package not getting reviewed fast enough for your liking, with an unsaid assertion that it's part of the 'wheat' above. Right now, we have a dearth of review resources. This leads to both merge reviews having no activity, and new package reviews sometimes having no activity. However, if a new package is important enough, someone's going to have enough self-interest to pick up the review, or enough self-interest as maintainer to swap reviews for someone else in the same boat. Frankly, that's the sort of intrinsic motivation common to open source... assuming differently, that there would or should be some sort of nebulous 'review community' sitting there waiting to take on a bunch of new submissions from the mountain seems awfully unrealistic. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Thu, Jul 8, 2010 at 6:26 PM, Bill Nottingham nott...@redhat.com wrote: I'd like not to assume the worst, but given your mass closing of some review bugs, plus your arguments here about why, plus your request for a review swap earlier, I'm having trouble reading this as anything other than a transparent frustration at your package not getting reviewed fast enough for your liking, with an unsaid assertion that it's part of the 'wheat' above. Cute re-ordering of events, there. No, after repeated experiences with seeking reviews, including this most recent one mentioned elsewhere on this list, and seeing others on this list repeating review requests, I was inspired to poke around to see why responses were so uneven. Looking at the process with fresh eyes, starting from https://fedoraproject.org/wiki/PackageReviewProcess and moving to https://fedoraproject.org/wiki/PackageMaintainers/ReviewRequests one sees a chaotic mess of package reviews, both assigned and unassigned, not really moving forward at all. Looking closely, you see a lot of packages that seem of worth, but that set is crowded by review requests for ancient packages like redhat-menus or kernel. In an ideal world, every package in fedora/devel would get a full package re-review prior to each release. But with finite resources limiting that, it seemed to me that triaging long-dead bugs for long-merged packages was a reasonable and helpful thing for the Fedora project. By all appearances, nobody else was bothering with these things after several years went by. If people want these obviously unloved, ignored review requests -- not even an rpmlint or ping in many cases -- to stick around, that's fine with me. I thought I was being helpful, but easy enough to leave things alone as well. My hail review was proceeding, and I wanted to make the process a bit easier for the -next- person wanting a review. Apologies for the ruffled feathers. The process itself is intimidating, because the wikis demand that a prospective reviewer wade into a completely unorganized swamp (BZ URLs linked-to from above URLs), hundreds of review requests, with next to zero information about where one's review would be most helpful. To an outsider, it must seem like quite a mess, with completely unknown chances for success/failure. Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Thu, 2010-07-08 at 14:28 -0600, Kevin Fenzi wrote: Greetings Fedora developers... c) Just leave them open and let people pick pick pick away at them a few at a time? We might be done by Fedora20. Or perhaps not. Does the existence of a bunch of open merge reviews cause any actual harm or trouble to anyone besides people who like to compile lists of open bugs and then stare at them glumly? =) If not, then option c) seems perfectly fine to me. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Thu, 08 Jul 2010 20:29:42 -0400 Jeff Garzik jgar...@pobox.com wrote: On 07/08/2010 08:23 PM, Adam Williamson wrote: On Thu, 2010-07-08 at 14:28 -0600, Kevin Fenzi wrote: Greetings Fedora developers... c) Just leave them open and let people pick pick pick away at them a few at a time? We might be done by Fedora20. Or perhaps not. Does the existence of a bunch of open merge reviews cause any actual harm or trouble to anyone besides people who like to compile lists of open bugs and then stare at them glumly? =) If not, then option c) seems perfectly fine to me. If you're looking for a package to review (perhaps for a review swap :)), Fedora actively directs you to exact those sorts of long lists of open bugs: https://fedoraproject.org/wiki/PackageMaintainers/ReviewRequests Wow. What links to that? You should really be using: http://fedoraproject.org/PackageReviewStatus/ Where they are seperated out and in nice cached lists. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Thu, 2010-07-08 at 18:36 -0600, Kevin Fenzi wrote: On Thu, 08 Jul 2010 20:29:42 -0400 Jeff Garzik jgar...@pobox.com wrote: On 07/08/2010 08:23 PM, Adam Williamson wrote: On Thu, 2010-07-08 at 14:28 -0600, Kevin Fenzi wrote: Greetings Fedora developers... c) Just leave them open and let people pick pick pick away at them a few at a time? We might be done by Fedora20. Or perhaps not. Does the existence of a bunch of open merge reviews cause any actual harm or trouble to anyone besides people who like to compile lists of open bugs and then stare at them glumly? =) If not, then option c) seems perfectly fine to me. If you're looking for a package to review (perhaps for a review swap :)), Fedora actively directs you to exact those sorts of long lists of open bugs: https://fedoraproject.org/wiki/PackageMaintainers/ReviewRequests Wow. What links to that? Thank the magic of mediawiki! https://fedoraproject.org/wiki/Special:WhatLinksHere/PackageMaintainers/ReviewRequests seems several important pages do. So perhaps they should be updated to use the link below.. You should really be using: http://fedoraproject.org/PackageReviewStatus/ Where they are seperated out and in nice cached lists. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Thu, 08 Jul 2010 17:59:44 -0700 Adam Williamson awill...@redhat.com wrote: Thank the magic of mediawiki! https://fedoraproject.org/wiki/Special:WhatLinksHere/PackageMaintainers/ReviewRequests seems several important pages do. So perhaps they should be updated to use the link below.. 2 of them are done. I'm not sure on the ru one. Feel free to adjust further. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
