#1269 Closing all 'Merge Review' bugs
Closed None by crobinso. Opened 4 years ago by crobinso.

I started a discussion on devel@ about closing all merge review tickets:

https://lists.fedoraproject.org/pipermail/devel/2014-March/197087.html

Since the discussion wasn't unanimous, I figured it's better to let fesco vote on whether to do this or not. Please consider discussing this at the next meeting.


Adding meeting keyword. Also cc'ing pknirsh as FESCo liason for Base Design.

-1 to close merge-reviews. But yes we can make some improvements like

1) Add current dist-git master URL to point current branch contents

2) Assign the merge-review to current package owner but keep the component PackageReview as its a review request bug.

As already asked on the list why people want to make difference between merge-reviews and new package reviews? Don't we want changing/updated packaging guidelines to be applied on master branch? These reviews still misses some updated guidelines to follow.

We have now many provenpackagers and contributors and we all can finish them collaboratively by providing review comments/fixes on merge-review bugs. The only issue since many years I observed is that those package maintainers find these bugs of no use as they are not blocking any functionality of that package.

Replying to [comment:2 paragn]:

As already asked on the list why people want to make difference between merge-reviews and new package reviews?

Because they are different.

  • Merge Reviews are reviewing a moving target. A traditional package review can sit in the tracker for 4 years and the spec file might not change that entire time. A 'merge review' is really more like a bug against an existing package, the solution just happens to be a package review.

  • Package reviews are opt in with a high barrier to entry, typically package submitters are motivated to finish the review so they can get their package into Fedora. On the other side, merge reviews have consistently shown to either confuse the owner of the package ('what is this bug? I'm closing it.') or be completely ignored. (I'm not saying it should be this way, but it happens, just pick any review at random and you'll find plenty of examples.)

  • A regular package review can expire (the package submitter disappears). Merge reviews exist indefinitely.

Don't we want changing/updated packaging guidelines to be applied on master branch? These reviews still misses some updated guidelines to follow.

Doing the review would generate some usefulness, for sure. But after 7 years, the pool of open merge reviews is a pretty arbitrary set of packages to hold that re-review standard against.

There were several people in the devel@ thread that talked about a larger process of re-reviewing packages, like some automated system, maybe follow up with them. I'm all for larger process improvements that work on the whole package set.

We have now many provenpackagers and contributors and we all can finish them collaboratively by providing review comments/fixes on merge-review bugs. The only issue since many years I observed is that those package maintainers find these bugs of no use as they are not blocking any functionality of that package.

As mentioned on the list by other folks, this is always the rationale that is brought up, and nothing ever changes. If you want to try to organize an effort to do these reviews, I encourage it. But then let's reassign all the bugs to component=$packagename version=rawhide, so if the maintainers are uninterested they can opt out, and if things aren't fixed for a year they will be EOL autoclosed. And the reviews will stop gunking up the package review tracker.

+1 to paragn's proposals. (ie -1 to closing.) additionally, nirik and I found that one of the policies that was intended to help with merge reviews was never moved out of draft phase on the wiki (although it <strike>afterward tip</strike>''appears to''(edited for autocorrect stupidity) have passed in fesco) https://fedoraproject.org/wiki/Merge_Reviews

we should make it apparent that is fesco policy.

we could also call out the fact that we want proven packagers to step in and apply changes if the package maintainer is not responsive on tickets. what that probably bills down to is committing to support provenpackagers if they make changes to a package and a maintainer complains about those changes(as long as the maintainer was given the opportunity to review the changes in the merge review and failed to act.)

I liked the suggestion made by several people in the thread on devel list
to focus future effort on an "rpm lintian" app monitoring the quality of current
packages: this could at least provide useful live package feedback to packager owners.

It still seems good to complete most merge reviews, specially those for core/base packages.

From the last week FESCo meeting:

agreed tell provenpackagers to just fix things and make sure they know we'll support them if an unresponsive package maintainer suddenly wakes up and complains that the provenpackager did what we asked them to do. organise a vfad to get them done in a a day. (6+1 0-1)

Leaving open but removing the meeting keyword.

Any news here on a VFAD?

dgilmore was going to try and setup one?

Any further news here? Is there still interest in a VFAD? Or should we revisit the approach here?

I'm still interested in helping with a VFAD. Possibly sometime after F21 is gold but before we're in full swing with F22? There's never a good time; that's the problem. :)

Yes, there's never a good a time. There's never been a good time, it's 'yeah we'll get to those eventually' for many years.

Can we come up with a hard deadline here? Like, if no VFAD has happened by F22 branch, we just close the merge reviews, or take it back to FESCo, or reassign all merge reviews to Fedora->$component->rawhide so they will at least have a natural time limit of closing in the future and stop polluting the package review tracker.

Let me help with some of merge-reviews in coming days

AGREED: dgilmore and mattdm to talk out of meeting and coordinate time (probably january) for vfad (+6, 1, -0) (sgallagh, 17:24:35)

So it's past january, no VFAD has been organized AFAICT. Since the last time this was discussed, only one of these merge reviews has been legitimately closed (based on a review that pre-dated the fesco meeting). I propose reassigning all merge reviews to their component, version=rawhide, with this comment:

Mass reassigning all merge reviews to their component. For more details, see this FESCO ticket:

https://fedorahosted.org/fesco/ticket/1269

If you don't know what merge reviews are about, please see:

https://fedoraproject.org/wiki/Merge_Reviews

How to handle this bug is left to the discretion of the package maintainer.

The best solution I can see is that ask the SIG/team/co-maintainer members of those packages to review them by F22 Beta freeze and ask them to provide some review on review tickets (not just say looks good and approved). We can then have no merge-review left by F22 final release.

In my experience even if I review any such package, either provide review comment or directly give patch, sometimes maintainers do not respond or accept the proposed changes and then no further work happens. So, its best to get them reviewed by known people to that (merge-review) package owner.

This ticket will be discussed in the FESCo meeting on Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net.

I'm +1 to the proposal from crobinso in comment 16.

From today’s FESCo meeting:

Bugs mass reassigned now. See the kernel merge review as an example:

https://bugzilla.redhat.com/show_bug.cgi?id=225969

As expected we got here first merge-review (kernel package) closed as WONTFIX.

Login to comment on this ticket.

Metadata