Hi!

Important chagesets are supposed to have bugs (or blueprints) assigned
to them, so, even if the CS is abandoned, its description still
remains on Launchpad in one form or another, so we will not loose it
from general project's backlog. And if the changeset didn't have a
bug/blueprint specified, then it either does not represent a real use
case at all (or its owner didn't bother to document it anyway, so
keeping the changeset most probably will not help to understand the
use case)

So I like the proposal in general.

However, it has a little issue: imagine a patchset which receives a -1
from some random reviewer. The owner may reply to that -1 with a
reasonable counterargument, and in this situation it is up to the
initial reviewer to either agree with that counterargument and revoke
the -1 or to continue the discussion and persuade the owner to change
the code. However, I've seen situations when the reviewers do not
react to such replies and the changesets remain idle with a single -1
which are in fact addressed but not removed. It would be a bad
practice if we abandon such commits just because their initial
reviewers have lost any interest in continuing the discussion with
owners.

Probably we should keep such situations in mind when defining "inactive".

--
Regards,
Alexander Tivelkov


On Fri, Feb 13, 2015 at 5:17 PM, Kuvaja, Erno <kuv...@hp.com> wrote:
> Hi Boris,
>
>
>
> Thanks for your input. I do like the idea of picking up the changes that
> have not been active. Do you have resources in mind to dedicate for this?
>
>
>
> My personal take is that if some piece of work has not been touched for a
> month, it’s probably not that important after all and the community should
> use the resources to do some work that has actual momentum. The changes
> itself will not disappear the owner is still able to revive it if felt that
> there is right time to continue it. The cleanup will just make it easier for
> people to focus on things that are actually moving. It also will make bug
> tracking bit easier when one will see on the bug report that the patch got
> abandoned due to inactivity and indicates that the owner of that bug might
> not be working on it after all.
>
>
>
> -          Erno
>
>
>
> From: Boris Pavlovic [mailto:bpavlo...@mirantis.com]
> Sent: Friday, February 13, 2015 1:25 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [glance] Cleanout of inactive change proposals
> from review
>
>
>
> Hi,
>
>
>
> I believe that keeping review queue clean is the great idea.
>
> But I am not sure that set of these rules is enough to abandon patches.
>
>
>
> Recently I wrote blogpost related to making OpenStack community more user
> friendly:
>
> http://boris-42.me/thoughts-on-making-openstack-community-more-user-friendly/
>
>
>
> tl;dr;
>
>
>
> Patches on review are great source of information what is missing in
> project.
>
> Removing them from queue means losing this essential information. The result
>
> of such actions is that project doesn't face users requirements which is
> quite bad...
>
>
>
> What if that project team continue work on all "abandoned" patches  that are
> covering
>
> valid use cases and finish them?
>
>
>
> Best regards,
>
> Boris Pavlovic
>
>
>
>
>
>
>
> On Fri, Feb 13, 2015 at 3:52 PM, Flavio Percoco <fla...@redhat.com> wrote:
>
> On 13/02/15 11:06 +0000, Kuvaja, Erno wrote:
>
> Hi all,
>
> We have almost year old (from last update) reviews still in the queue for
> glance. The discussion was initiated on yesterday’s meeting for adopting
> abandon policy for stale changes.
>
> The documentation can be found from https://etherpad.openstack.org/p/
> glance-cleanout-of-inactive-PS and any input would be appreciated. For your
> convenience current state below:
>
>
> Thanks for putting this together. I missed the meeting yday and this
> is important.
>
> Glance - Cleanout of inactive change proposals from review
>
>
> We Should start cleaning out our review list to keep the focus on changes
> that
> has momentum. Nova is currently abandoning change proposals that has been
> inactive for 4 weeks.
>
>
>
> Proposed action (if all of the following is True, abandon the PS):
>
> 1. The PS has -1/-2 (including Jenkins)
>
>
> I assume you're talking about voting -1/-2 and not Workflow, right?
> (you said jenkins afterall but just for the sake of clarity).
>
> 2. The change is proposed to glance, glance_store or python-glanceclient;
>    specs should not be abandoned as their workflow is much slower
>
> 3. No activity for 28 days from Author/Owner after the -1/-2
>
>
> I'd reword this in "No activity". This includes comments, feedback,
> discussions and or other committers taking over a patch.
>
> 4. There has been  query made to the owner to update the patch between 5 and
>    10 days  before abandoning (comment on PS/Bug or something similar)
>
>  ● Let's be smart on this. Flexibility is good on holiday seasons, during
>    feature freeze, etc.
>
>
> +2 to the above, I like it.
>
> Thanks again,
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __________________________________________________________________________
> 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
>

__________________________________________________________________________
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

Reply via email to