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
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
On Tue, Mar 25, 2014 at 1:07 AM, Toshio Kuratomi a.badger@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?
----- Original Message -----
On Tue, Mar 25, 2014 at 1:07 AM, Toshio Kuratomi a.badger@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
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
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
Hi,
On Tue, Mar 25, 2014 at 7:13 PM, Marcela Mašláňová mmaslano@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.
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.
Hi,
On Wed, Mar 26, 2014 at 5:38 PM, Richard W.M. Jones rjones@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_packa...
Regards, Parag.
On 03/26/2014 08:46 AM, Parag N(पराग़) wrote:
Hi,
On Wed, Mar 26, 2014 at 5:38 PM, Richard W.M. Jones rjones@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_packa...
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
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.
On Tue, Mar 25, 2014 at 9:15 AM, Matthew Miller mattdm@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
Hi,
On Tue, Mar 25, 2014 at 6:59 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Mar 25, 2014 at 9:15 AM, Matthew Miller mattdm@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.
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*)
- 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
On Tue, Mar 25, 2014 at 9:43 AM, Matthew Miller mattdm@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.
- 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
On Tue, Mar 25, 2014 at 2:43 PM, Matthew Miller mattdm@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*)
- 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.
----- Original Message -----
On Tue, Mar 25, 2014 at 9:15 AM, Matthew Miller mattdm@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:
- 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
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