Re: Let's close the remaining merge reviews
I've proposed discussing this at the next FESCo meeting: https://fedorahosted.org/fesco/ticket/1269 If you have opinions on the matter, please consider attending. Thanks, Cole On 03/24/2014 04:41 PM, Cole Robinson wrote: Hi all, In case readers don't know, this page describes what a merge review is: https://fedoraproject.org/wiki/Merge_Reviews In short: when fedora core and extras merged, a Package Review was opened for every package in core. The idea was that every core package would be reviewed to ensure it met with the extras packaging guidelines. It has never blocked anything, it's just a best effort 'we should do this one day'. Since 1 year ago (2013-03-24), 8 merge reviews have been closed as either RAWHIDE, CURRENTRELEASE, or NEXTRELEASE. There's currently 126 open merge reviews. Of those, since 2013-03-24, 8 have received new comments. The breakdown is: Not related to any progress on the merge review (account closings mostly): 226640, 226497 Related to the merge review but not indicative of any progress being made (pings, 'what is this bug for', ...): 225755, 226425 Varying amounts of attempted review (4 bugs): 225989, 226209, 225708, 226140 So in the past 12 months, there's been some positive activity on 12 merge reviews. But 116 have sat totally dormant. Many have not been touched for over five years. Keeping these reviews open has a real cost: - Developer confusion in the form of 'what is this bug, why should I care' (there's lots of that in the comments of these reviews from over the years). - Reviewer confusion when they go to this page: http://fedoraproject.org/PackageReviewStatus/I experienced this when I first went to the page, and had to go read up on it. - Reviewer energy, for those folks that make a valiant attempt only for repeated pings to go unanswered. And yet I don't blame maintainers for not caring much about a merge review. And they are easy to ignore: personally I don't track bugs assigned to me so much as I track bugs belonging to the packages I care about, so I'm sure many maintainers don't even know these open bugs exist, since the component is 'Package Review'. - Bugzilla search times on open bugs (okay that's probably a stretch :) ) I suggest we just close all these bugs. I'm happy to do the autoclosing, add myself to the CC, and handle any follow up comments. I propose a message like this: We've decided to close all merge reviews: link to this thread If there is any in-progress work lingering, or if anyone is interested in completing this review, please reopen this bug and reassign the bug to the actual component. An alternative would be to reassign every open merge review to the component in question, and let maintainers handle it as they like. Thoughts? Thanks, Cole -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Let's close the remaining merge reviews
- Original Message - On Tue, Mar 25, 2014 at 9:15 AM, Matthew Miller mat...@fedoraproject.org wrote: On Mon, Mar 24, 2014 at 05:07:35PM -0700, Toshio Kuratomi wrote: Alternative idea -- maybe identify all packages which are not ciritcal and have an open merge review. Take those packages out of the repository. Then revisit the list and formulate a plan on what to do with thoes (even if the plan is then, these were critical enough to leave in so we'll give them a pass on going through a formal review). I like the idea of actually revisiting the list and deciding what to do, although pulling them out of the repository seems unnecessarily drastic. This always winds up being the suggestion. Nobody actually does anything about it. I'd only be supportive of this on two conditions: 1) Actual bugs impacting actual people as a result of an improper spec file were present 2) One of the bodies responsible for packages in Fedora (FESCo, FPC, ?) agreed to conduct audits across all packages for guideline adherence at regular intervals. I'd be willing to not require item 1 if item 2 were actually done. It never has been, and if it had it would already suffice for the purpose the merge review tickets would serve today. We have a lot of guidelines. Enough that it can be rather daunting to a new packager to even start packaging something. What we have always lacked is enforcement and accountability on those guidelines _after_ something is in the distro. + unlimited to the last paragraph. Jaroslav Fix that problem and everything else relating to it will be solved. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Let's close the remaining merge reviews
On Wed, Mar 26, 2014 at 08:13:24AM +0530, Parag N(पराग़) wrote: If those packages are still not following current packaging guidelines then they should not be closed otherwise what is the use of FPC and their work, meetings, updating wiki pages all these efforts will be of no use then for existing packages in Fedora. FPC work will remain only for newer package submissions. The presence of these bugs tells you nothing about the quality of those packages. Also it doesn't tell you about other packages that might have passed the review 5+ years ago, but since then fallen out of compliance with the guidelines. This is where having some sort of automated testing of all packages would be good (perhaps running fedora-review over packages, as was suggested in this thread already). FWIW, Debian does this already: http://lintian.debian.org/ Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Let's close the remaining merge reviews
Hi, On Wed, Mar 26, 2014 at 5:38 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Mar 26, 2014 at 08:13:24AM +0530, Parag N(पराग़) wrote: If those packages are still not following current packaging guidelines then they should not be closed otherwise what is the use of FPC and their work, meetings, updating wiki pages all these efforts will be of no use then for existing packages in Fedora. FPC work will remain only for newer package submissions. The presence of these bugs tells you nothing about the quality of those packages. Also it doesn't tell you about other packages that might have passed the review 5+ years ago, but since then fallen out of compliance with the guidelines. This looks like a general opinion on package reviews and not about merge-reviews. Why can't we consider them like as a new reviews? and why people so against merge-review just because we got those packages already in Fedora? This is where having some sort of automated testing of all packages would be good (perhaps running fedora-review over packages, as was suggested in this thread already). That will be a welcome move but again will maintainers read those reviews and work on to fix any reported issues? FWIW, Debian does this already: http://lintian.debian.org/ Those who want to see all the automated work, keep looking into https://fedoraproject.org/wiki/Env_and_Stacks/Changes_Drafts/Automated_packages_review_tools Regards, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Let's close the remaining merge reviews
On 03/26/2014 08:46 AM, Parag N(पराग़) wrote: Hi, On Wed, Mar 26, 2014 at 5:38 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Mar 26, 2014 at 08:13:24AM +0530, Parag N(पराग़) wrote: If those packages are still not following current packaging guidelines then they should not be closed otherwise what is the use of FPC and their work, meetings, updating wiki pages all these efforts will be of no use then for existing packages in Fedora. FPC work will remain only for newer package submissions. The presence of these bugs tells you nothing about the quality of those packages. Also it doesn't tell you about other packages that might have passed the review 5+ years ago, but since then fallen out of compliance with the guidelines. This looks like a general opinion on package reviews and not about merge-reviews. Why can't we consider them like as a new reviews? and why people so against merge-review just because we got those packages already in Fedora? This is where having some sort of automated testing of all packages would be good (perhaps running fedora-review over packages, as was suggested in this thread already). That will be a welcome move but again will maintainers read those reviews and work on to fix any reported issues? FWIW, Debian does this already: http://lintian.debian.org/ Those who want to see all the automated work, keep looking into https://fedoraproject.org/wiki/Env_and_Stacks/Changes_Drafts/Automated_packages_review_tools Regards, Parag. I don't care much about Merge reviews. From my POV it doesn't make sense to do them, when we have a lot of packages, which went through Merge review years ago and can be against Guidelines again. I would rather invest our free time on automation. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Let's close the remaining merge reviews
On Tue, Mar 25, 2014 at 1:07 AM, Toshio Kuratomi a.bad...@gmail.com wrote: On Mon, Mar 24, 2014 at 04:41:29PM -0400, Cole Robinson wrote: An alternative would be to reassign every open merge review to the component in question, and let maintainers handle it as they like. Thoughts? Alternative idea -- maybe identify all packages which are not ciritcal and have an open merge review. Take those packages out of the repository. That's a bit harsh ... we have been shipping those packages for years, why suddenly drop them? What problem does this solve? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Let's close the remaining merge reviews
- Original Message - On Tue, Mar 25, 2014 at 1:07 AM, Toshio Kuratomi a.bad...@gmail.com wrote: On Mon, Mar 24, 2014 at 04:41:29PM -0400, Cole Robinson wrote: An alternative would be to reassign every open merge review to the component in question, and let maintainers handle it as they like. Thoughts? Alternative idea -- maybe identify all packages which are not ciritcal and have an open merge review. Take those packages out of the repository. That's a bit harsh ... we have been shipping those packages for years, why suddenly drop them? What problem does this solve? Yep, it's really too strict. Also setting the bar how much package is critical sounds weird. For reviews - I'd say most of the review requests bugs are already obsolete. What would actually help making Fedora better would be regular fedora- review (*) runs - even I'm again a bit sceptical we would be able to go through it same as for merge reviews. But for more active maintainers it could help them to make SPECs better. (*) not full review, much more easier tool to check basic sanity of SPECs... Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Let's close the remaining merge reviews
On 03/24/2014 08:07 PM, Toshio Kuratomi wrote: On Mon, Mar 24, 2014 at 04:41:29PM -0400, Cole Robinson wrote: An alternative would be to reassign every open merge review to the component in question, and let maintainers handle it as they like. Thoughts? Alternative idea -- maybe identify all packages which are not ciritcal and have an open merge review. Take those packages out of the repository. What does that solve? How does that benefit anybody? Then revisit the list and formulate a plan on what to do with thoes (even if the plan is then, these were critical enough to leave in so we'll give them a pass on going through a formal review). The original premise of these tickets makes sense. But here we are 7+ years later. The spec we would review today is in many cases nothing like the spec when the bug was filed. Why should these packages be subject to a review _now_ when there's a thousand packages in the repo that saw an initial review, and are then left entirely alone for 6 years? Because 7 years ago we merged core and extras? I'm not convinced. The bottom line IMO is that these bugs are generating very little benefit, and are actively detrimental. They shouldn't be given any extra weight for history's sake. - Cole -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Let's close the remaining merge reviews
On Mon, Mar 24, 2014 at 05:07:35PM -0700, Toshio Kuratomi wrote: Alternative idea -- maybe identify all packages which are not ciritcal and have an open merge review. Take those packages out of the repository. Then revisit the list and formulate a plan on what to do with thoes (even if the plan is then, these were critical enough to leave in so we'll give them a pass on going through a formal review). I like the idea of actually revisiting the list and deciding what to do, although pulling them out of the repository seems unnecessarily drastic. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Let's close the remaining merge reviews
On Tue, Mar 25, 2014 at 9:15 AM, Matthew Miller mat...@fedoraproject.org wrote: On Mon, Mar 24, 2014 at 05:07:35PM -0700, Toshio Kuratomi wrote: Alternative idea -- maybe identify all packages which are not ciritcal and have an open merge review. Take those packages out of the repository. Then revisit the list and formulate a plan on what to do with thoes (even if the plan is then, these were critical enough to leave in so we'll give them a pass on going through a formal review). I like the idea of actually revisiting the list and deciding what to do, although pulling them out of the repository seems unnecessarily drastic. This always winds up being the suggestion. Nobody actually does anything about it. I'd only be supportive of this on two conditions: 1) Actual bugs impacting actual people as a result of an improper spec file were present 2) One of the bodies responsible for packages in Fedora (FESCo, FPC, ?) agreed to conduct audits across all packages for guideline adherence at regular intervals. I'd be willing to not require item 1 if item 2 were actually done. It never has been, and if it had it would already suffice for the purpose the merge review tickets would serve today. We have a lot of guidelines. Enough that it can be rather daunting to a new packager to even start packaging something. What we have always lacked is enforcement and accountability on those guidelines _after_ something is in the distro. Fix that problem and everything else relating to it will be solved. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Let's close the remaining merge reviews
Hi, On Tue, Mar 25, 2014 at 6:59 PM, Josh Boyer jwbo...@fedoraproject.org wrote: On Tue, Mar 25, 2014 at 9:15 AM, Matthew Miller mat...@fedoraproject.org wrote: On Mon, Mar 24, 2014 at 05:07:35PM -0700, Toshio Kuratomi wrote: Alternative idea -- maybe identify all packages which are not ciritcal and have an open merge review. Take those packages out of the repository. Then revisit the list and formulate a plan on what to do with thoes (even if the plan is then, these were critical enough to leave in so we'll give them a pass on going through a formal review). I like the idea of actually revisiting the list and deciding what to do, although pulling them out of the repository seems unnecessarily drastic. This always winds up being the suggestion. Nobody actually does anything about it. This is also what I have seen. We have seen many discussions on merge-review closure since last few years but no one step forward to work on it. Why to discuss such things if we all contributors can review packages and help maintainers to have their packages as per current packaging guidelines? The only problem I have seen while working on such reviews is that some maintainers find them low priority and did not respond. Sometime ago I decided to work on this and also wanted to clean spec myself and review the same package myself but our policies does not allow this. So I occasionally visit merge-reviews and try to finish them with the help of current package owner. Regards, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Let's close the remaining merge reviews
On Tue, Mar 25, 2014 at 9:43 AM, Matthew Miller mat...@fedoraproject.org wrote: On Tue, Mar 25, 2014 at 09:29:12AM -0400, Josh Boyer wrote: I like the idea of actually revisiting the list and deciding what to do, although pulling them out of the repository seems unnecessarily drastic. This always winds up being the suggestion. Nobody actually does anything about it. I'd only be supportive of this on two conditions: Well, I was looking through the list there are some important packages in here, including gcc, nss, samba, httpd, and a lot more. And tcp_wrappers. :) Many of these really deserve the attention. I find that difficult to believe given that they haven't had said attention in 7 years and stuff is still working. 1) Actual bugs impacting actual people as a result of an improper spec file were present 2) One of the bodies responsible for packages in Fedora (FESCo, FPC, ?) agreed to conduct audits across all packages for guideline adherence at regular intervals. I'd be willing to not require item 1 if item 2 were actually done. It never has been, and if it had it would already suffice for the purpose the merge review tickets would serve today. I don't think that we need to do it across *all* packages. I'd like to see it done initially for all packages that end up part of the base design. That's a more manageable chunk and will focus the effort where it will have the most benefit. Under the premise that some is better than none, OK. I have doubts that regularly scheduled _recurring_ audits will actually be done at all for any set of packages though. The argument is always lack of people doing it. The solution is automation. The argument against _that_ is lack of people doing it and complexity to do it properly in an automated fashion. Vicious cycles are vicious. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Let's close the remaining merge reviews
On Tue, Mar 25, 2014 at 2:43 PM, Matthew Miller mat...@fedoraproject.org wrote: On Tue, Mar 25, 2014 at 09:29:12AM -0400, Josh Boyer wrote: I like the idea of actually revisiting the list and deciding what to do, although pulling them out of the repository seems unnecessarily drastic. This always winds up being the suggestion. Nobody actually does anything about it. I'd only be supportive of this on two conditions: Well, I was looking through the list there are some important packages in here, including gcc, nss, samba, httpd, and a lot more. And tcp_wrappers. :) Many of these really deserve the attention. Others maybe not so much. tix? Pyrex? (Also I notice festival is in there -- that's partly package and based on long-ago work I did before the merge and I *know* it needs an update... *sigh*) 1) Actual bugs impacting actual people as a result of an improper spec file were present 2) One of the bodies responsible for packages in Fedora (FESCo, FPC, ?) agreed to conduct audits across all packages for guideline adherence at regular intervals. I'd be willing to not require item 1 if item 2 were actually done. It never has been, and if it had it would already suffice for the purpose the merge review tickets would serve today. I don't think that we need to do it across *all* packages. I'd like to see it done initially for all packages that end up part of the base design. That's a more manageable chunk and will focus the effort where it will have the most benefit. The benefit would be? We shouldn't waste so much time and resources for a questionable gain. If there are issues with some packages file bugs (with patches) or better just fix it and be done with it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Let's close the remaining merge reviews
On Tue, Mar 25, 2014 at 09:29:12AM -0400, Josh Boyer wrote: I like the idea of actually revisiting the list and deciding what to do, although pulling them out of the repository seems unnecessarily drastic. This always winds up being the suggestion. Nobody actually does anything about it. I'd only be supportive of this on two conditions: Well, I was looking through the list there are some important packages in here, including gcc, nss, samba, httpd, and a lot more. And tcp_wrappers. :) Many of these really deserve the attention. Others maybe not so much. tix? Pyrex? (Also I notice festival is in there -- that's partly package and based on long-ago work I did before the merge and I *know* it needs an update... *sigh*) 1) Actual bugs impacting actual people as a result of an improper spec file were present 2) One of the bodies responsible for packages in Fedora (FESCo, FPC, ?) agreed to conduct audits across all packages for guideline adherence at regular intervals. I'd be willing to not require item 1 if item 2 were actually done. It never has been, and if it had it would already suffice for the purpose the merge review tickets would serve today. I don't think that we need to do it across *all* packages. I'd like to see it done initially for all packages that end up part of the base design. That's a more manageable chunk and will focus the effort where it will have the most benefit. We have a lot of guidelines. Enough that it can be rather daunting to a new packager to even start packaging something. What we have always lacked is enforcement and accountability on those guidelines _after_ something is in the distro. Fix that problem and everything else relating to it will be solved. +1 -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Let's close the remaining merge reviews
On 03/25/2014 08:42 AM, Cole Robinson wrote: On 03/24/2014 08:07 PM, Toshio Kuratomi wrote: On Mon, Mar 24, 2014 at 04:41:29PM -0400, Cole Robinson wrote: An alternative would be to reassign every open merge review to the component in question, and let maintainers handle it as they like. Thoughts? Alternative idea -- maybe identify all packages which are not ciritcal and have an open merge review. Take those packages out of the repository. What does that solve? How does that benefit anybody? Then revisit the list and formulate a plan on what to do with thoes (even if the plan is then, these were critical enough to leave in so we'll give them a pass on going through a formal review). The original premise of these tickets makes sense. But here we are 7+ years later. The spec we would review today is in many cases nothing like the spec when the bug was filed. Why should these packages be subject to a review _now_ when there's a thousand packages in the repo that saw an initial review, and are then left entirely alone for 6 years? Because 7 years ago we merged core and extras? I'm not convinced. The bottom line IMO is that these bugs are generating very little benefit, and are actively detrimental. They shouldn't be given any extra weight for history's sake. - Cole I concur. Let's close those bugs. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Let's close the remaining merge reviews
Hi, On Tue, Mar 25, 2014 at 7:13 PM, Marcela Mašláňová mmasl...@redhat.com wrote: On 03/25/2014 08:42 AM, Cole Robinson wrote: On 03/24/2014 08:07 PM, Toshio Kuratomi wrote: On Mon, Mar 24, 2014 at 04:41:29PM -0400, Cole Robinson wrote: An alternative would be to reassign every open merge review to the component in question, and let maintainers handle it as they like. Thoughts? Alternative idea -- maybe identify all packages which are not ciritcal and have an open merge review. Take those packages out of the repository. What does that solve? How does that benefit anybody? Then revisit the list and formulate a plan on what to do with thoes (even if the plan is then, these were critical enough to leave in so we'll give them a pass on going through a formal review). The original premise of these tickets makes sense. But here we are 7+ years later. The spec we would review today is in many cases nothing like the spec when the bug was filed. Why should these packages be subject to a review _now_ when there's a thousand packages in the repo that saw an initial review, and are then left entirely alone for 6 years? Because 7 years ago we merged core and extras? I'm not convinced. The bottom line IMO is that these bugs are generating very little benefit, and are actively detrimental. They shouldn't be given any extra weight for history's sake. - Cole I concur. Let's close those bugs. If those packages are still not following current packaging guidelines then they should not be closed otherwise what is the use of FPC and their work, meetings, updating wiki pages all these efforts will be of no use then for existing packages in Fedora. FPC work will remain only for newer package submissions. Regards, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Let's close the remaining merge reviews
Hi all, In case readers don't know, this page describes what a merge review is: https://fedoraproject.org/wiki/Merge_Reviews In short: when fedora core and extras merged, a Package Review was opened for every package in core. The idea was that every core package would be reviewed to ensure it met with the extras packaging guidelines. It has never blocked anything, it's just a best effort 'we should do this one day'. Since 1 year ago (2013-03-24), 8 merge reviews have been closed as either RAWHIDE, CURRENTRELEASE, or NEXTRELEASE. There's currently 126 open merge reviews. Of those, since 2013-03-24, 8 have received new comments. The breakdown is: Not related to any progress on the merge review (account closings mostly): 226640, 226497 Related to the merge review but not indicative of any progress being made (pings, 'what is this bug for', ...): 225755, 226425 Varying amounts of attempted review (4 bugs): 225989, 226209, 225708, 226140 So in the past 12 months, there's been some positive activity on 12 merge reviews. But 116 have sat totally dormant. Many have not been touched for over five years. Keeping these reviews open has a real cost: - Developer confusion in the form of 'what is this bug, why should I care' (there's lots of that in the comments of these reviews from over the years). - Reviewer confusion when they go to this page: http://fedoraproject.org/PackageReviewStatus/I experienced this when I first went to the page, and had to go read up on it. - Reviewer energy, for those folks that make a valiant attempt only for repeated pings to go unanswered. And yet I don't blame maintainers for not caring much about a merge review. And they are easy to ignore: personally I don't track bugs assigned to me so much as I track bugs belonging to the packages I care about, so I'm sure many maintainers don't even know these open bugs exist, since the component is 'Package Review'. - Bugzilla search times on open bugs (okay that's probably a stretch :) ) I suggest we just close all these bugs. I'm happy to do the autoclosing, add myself to the CC, and handle any follow up comments. I propose a message like this: We've decided to close all merge reviews: link to this thread If there is any in-progress work lingering, or if anyone is interested in completing this review, please reopen this bug and reassign the bug to the actual component. An alternative would be to reassign every open merge review to the component in question, and let maintainers handle it as they like. Thoughts? Thanks, Cole -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Let's close the remaining merge reviews
On Mon, Mar 24, 2014 at 04:41:29PM -0400, Cole Robinson wrote: An alternative would be to reassign every open merge review to the component in question, and let maintainers handle it as they like. Thoughts? Alternative idea -- maybe identify all packages which are not ciritcal and have an open merge review. Take those packages out of the repository. Then revisit the list and formulate a plan on what to do with thoes (even if the plan is then, these were critical enough to leave in so we'll give them a pass on going through a formal review). -Toshio pgpwZkb5_xTPH.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
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
merge reviews
Greetings Fedora developers... First some background for folks that were not around back in the day: There used to be a Fedora Core and a Fedora Extras. Fedora Core was maintained internally inside Red Hat by Red Hat employees. Fedora Extras was maintained by community folks much in the way Fedora is now. After Fedora Core 6 was released, Fedora Core and Fedora Extras were merged into Fedora. This was pretty much done by moving all the Fedora Core Packages into the external/community Extras infrastructure. During this merge, it was noted that the Fedora Extras packages had all passed a review of some kind and in general were more in line with packaging guidelines and such, while the Core packages had not had reviews and in many cases were created long before the current guidelines were in place or known. So, Merge review tickets were filed on all the formerly Core packages so they could get reviewed and checked for compliance with the current guidelines. There was an initial push to review this packages and try and get them all done, but several factors combined to make this not happen: lack of reviewers, lack of response from maintainers who feel review is cosmetic and low priority, etc. 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. 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. d) Require new package submissions to the review queue to show that they reviewed a merge review before their package could be reviewed. e) Stop allowing non merge review packages into the collection until the merge reviews were all done. 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. g) Your clever idea here Thoughts? 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, 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
