> On Mar 2, 2015, at 1:13 PM, James E. Blair <cor...@inaugust.com> wrote: > > Stefano branched this thread from an older one to talk about > auto-abandon. In the previous thread, I believe I explained my > concerns, but since the topic split, perhaps it would be good to > summarize why this is an issue. > > 1) A core reviewer forcefully abandoning a change contributed by someone > else can be a very negative action. It's one thing for a contributor to > say "I have abandoned this effort", it's very different for a core > reviewer to do that for them. It is a very strong action and signal, > and should not be taken lightly.
I'm not arguing against better tooling, queries, or additional comment warnings. All of those are good things. But I think some of the push back in this thread is challenging this notion that abandoning is negative, which you seem to be treating as a given. I don't. At all. And I don't think I'm alone. I also don't understand your point that the review becomes invisible, since it's a simple gerrit query to see closed reviews, and your own contention is that gerrit queries solve this in the other direction, so it can't be too hard in this one, either. I've done that many times to find mine and others abandoned reviews, the most recent example being resurrecting all of the lbaas v2 reviews after it slipped out of juno and eventually was put into it's own repo. Some of those reviews were abandoned, others not, and it was roughly equivalent to find them, open or not, and then re-tool those for the latest changes to master. Back to your question of what queries are most useful, I already answered, but to give you an idea of how we directed folks to find reviews relevant to kilo-2, I'll share this monster, which didn't even include targeted bugs we wanted looked at. Some tighter integration with launchpad (or storyboard) would likely be necessary for this to be sane. Neutron, kilo-2 blueprints: https://review.openstack.org/#/q/project:openstack/neutron+status:open+(topic:bp/wsgi-pecan-switch+OR+topic:bp/plugin-interface-perestroika+OR+topic:bp/reorganize-unit-test-tree+OR+topic:bp/restructure-l2-agent+OR+topic:bp/rootwrap-daemon-mode+OR+topic:bp/retargetable-functional-testing+OR+topic:bp/refactor-iptables-firewall-driver+OR+topic:bp/vsctl-to-ovsdb+OR+topic:bp/lbaas-api-and-objmodel-improvement+OR+topic:bp/restructure-l3-agent+OR+topic:bp/neutron-ovs-dvr-vlan+OR+topic:bp/allow-specific-floating-ip-address+OR+topic:bp/ipset-manager-refactor+OR+topic:bp/agent-child-processes-status+OR+topic:bp/extra-dhcp-opts-ipv4-ipv6+OR+topic:bp/ipsec-strongswan-driver+OR+topic:bp/ofagent-bridge-setup+OR+topic:bp/arp-spoof-patch-ebtables+OR+topic:bp/report-ha-router-master+OR+topic:bp/conntrack-in-security-group+OR+topic:bp/allow-mac-to-be-updated+OR+topic:bp/specify-router-ext-ip+OR+topic:bp/a10-lbaas-v2-driver+OR+topic:bp/brocade-vyatta-fwaas-plugin+OR+topic:bp/netscaler-lbaas-v2-driver+O R+topic:bp/ofagent-sub-driver+OR+topic:bp/ml2-cisco-nexus-mechdriver-providernet+OR+topic:bp/ofagent-flow-based-tunneling+OR+topic:bp/ml2-ovs-portsecurity+OR+topic:bp/fwaas-cisco+OR+topic:bp/freescale-fwaas-plugin+OR+topic:bp/rpc-docs-and-namespace),n,z Thanks, doug > > 2) Many changes become "inactive" due to no fault of their authors. For > instance, a change to nova that missed a freeze deadline might need to > be deferred for 3 months or more. It should not be automatically > abandoned. > > 3) Abandoned changes are not visible by their authors. Many > contributors will not see the abandoned change. Many contributors use > their list of open reviews to get their work done, but if you abandon > their changes, they will no longer see that there is work for them to be > done. > > 4) Abandoned changes are not visible to other contributors. Other > people contributing to a project may see a change that they could fix up > and get merged. However, if the change is abandoned, they are unlikely > to find it. > > 5) Abandoned changes are not able to be resumed by other contributors. > Even if they managed to find changes despite the obstacles imposed by > #3, they would be unable to restore the change and continue working on > it. > > In short, there are a number of negative impacts to contributors, core > reviewers, and maintainers of projects caused by automatically > abandoning changes. These are not hypothetical; I have seen all of > these negative impacts on projects I contribute to. > > Now this is the most important part -- I can not emphasize this enough: > > Whatever is being achieved by auto-abandoning can be achieved through > other, less harmful, methods. > > Core reviewers should not have to wade through lots of extra changes. > They should not be called upon to deal with drive-by changes that people > are not willing to collaborate on. Abandoning changes is an imperfect > solution to a problem, and we can find a better solution. > > We have tools that can filter out changes that are not active so that > core reviewers are not bothered by them. In fact, the auto-abandon > script itself is built on one or two exceedingly simple queries which, > when reversed, will show you only the changes it would not abandon. > > What I hope to gain by this conversation is to identify where the gaps > in our tooling are. If you feel strongly that you do not want to see > inactive changes, please tell me what query, dashboard, tool, page, > etc., that you use to find changes to review. We can help make sure > that it is structured to filter out changes you are not interested in, > and helps surface changes you want to work on. > > Thanks, > > Jim > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
