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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
