> On Mar 2, 2015, at 11:44 AM, James E. Blair <cor...@inaugust.com> wrote: > > Duncan Thomas <duncan.tho...@gmail.com> writes: > >> Why do you say auto-abandon is the wrong tool? I've no problem with the 1 >> week warning if somebody wants to implement it - I can see the value. A >> change-set that has been ignored for X weeks is pretty much the dictionary >> definition of abandoned, and restoring it is one mouse click. Maybe put >> something more verbose in the auto-abandon message than we have been, >> encouraging those who feel it shouldn't have been marked abandoned to >> restore it (and respond quicker in future) but other than that we seem to >> be using the right tool to my eyes > > Why do you feel the need to abandon changes submitted by other people? > Why do you feel the need to keep them? Do your regularly look at older patches? Do you know anyone that does?
Speaking as a contributor, I personally vastly prefer clicking 'Restore' to having gerrit being a haystack of cruft. I have/had many frustrations trying to become a useful contributor. Abandoned patches was never one of them. > Is it because you have a list of changes to review, and they persist on > that list? If so, let's work on making a better list for you. We have > the tools. What query/page/list/etc are you looking at where you see > changes that you don't want to see? When I was starting out, hearing that the best thing I could help out was to "do some reviews", I'd naively browse to gerrit and look for something "easy" to get started with. The default query ("status:open") means that there is about a 110% (hyperbole added) chance that I'll pick something to review that's a waste of time. A default query that edited out old, jenkins failing, and -2 stuff would be helpful. A default or easy query that highlighted things relevant to the current milestone's blueprints and bugs would be SUPER useful to guiding folks towards the most useful reviews to be doing for a given project. The current system does not do a good job of intuitively guiding folks towards the right answer. You have to know the tribal knowledge first, and/or which of six conflicting wiki pages has the right info to get started with (more hyperbole added.) Thanks, doug > > -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