Launchpad reviews (was Re: Patch Pilot report)
Aaron Bentley
aaron at aaronbentley.com
Tue Nov 24 06:10:49 GMT 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin Pool wrote:
> 2009/11/24 Aaron Bentley <aaron at aaronbentley.com>:
>> 'Reviews I have to do'
>
> I guess this heading is absent because there are none of them?
Yes.
> I don't think the terminology is ideal, and I have filed a bug to that
> effect, and I think also one asking that you should document what they
> do mean. But more importantly the emergent behaviour does not align
> with the way you expect it to work: for example
> <https://code.edge.launchpad.net/~vila/bzr/releasing-clarified/+merge/10854>
> is shown in "reviews I can do" but in fact there is nothing useful for
> me to do there.
I'm not sure why there is an outstanding review request for the team.
Normally, Ian's review would automatically be selected as the bzr-core
review. Perhaps two reviews were requested of bzr-core?
Given that there *is* an outstanding review request for a team that
you're on, I hope you'd agree that it should be presented as something
you can review.
> Updating a bug does naturally lead you into changing its state and
> priority, which determine what happens to it next.
I don't follow. Changing the state and priority have an impact on
humans, who determine what to do next based on the project's
conventions. The "what's next" part isn't Launchpad per se.
>>> * I will do the changes and land it
>> I think that would be best expressed by creating your own branch and
>> creating a new merge proposal that supersedes this one. The 'supersede'
>> part isn't something we currently support.
>>
>>> * I want someone to do the changes and land it, but not me
>>> * I want the submitter to do the changes and land it (not sure what
>>> status this is)
>> "needs-fixing"
>
> These three cases have quite different implications for the next
> action, and I think the fact they're conflated causes some churn.
Which three cases are conflated?
>
>>> * I want the submitter to do the changes and resubmit it (I guess
>>> this is 'needs fixing'?)
>> It is "resubmit".
>
> Perhaps this changed, but 'resubmit' used to have the special
> behaviour of creating a new mp, not asking someone to resubmit.
The "resubmit" vote has never had that effect. There used to be a
"resubmit" entry in the status selector, but that has been turned into
the "resubmit proposal" action.
> I've been involved with this for something over four years
Presumably, you're including Bundle Buggy, which also used "resubmit"
for the purpose?
> and I've
> done probably over a hundred reviews in the new system. I'm not being
> intentionally bloody minded. So if I'm not sure what the statuses
> mean, and apparently most other bzr core team members don't either, I
> think there is a real problem.
I think you have a lot of opportunities to find out about the system, so
if you don't understand it now, you haven't taken advantage of them.
>> The code review system is not intended to enforce a particular workflow;
>> it's meant to provide enough flexibility to enable teams to use it as
>> they see fit.
>
> Let's be clear, I'm not asking for you to enforce a particular
> workflow or to remove any generality. I don't dispute that it's
> technically possible to use it. It's also possible to do reviews on
> the mailing list or by attaching them to bugs. The whole point of the
> review system is to help with workflow, so user feedback that it does
> not support their workflow well is pretty important.
But the significance of that feedback also depends on the degree of
understanding demonstrated by the user. The critique of a user who does
not thoroughly understand the system may simply indicate a need for
documentation or education.
> The specific changes I'd like to see are:
(These are a lot more palatable than the "suggest a next action out of
these 10 or so" thing that I was responding to)
> * document the headings in the overview (either in help or inline)
> * document the votes and statuses
> * address the problem of people creating reviews as themselves when
> they want to review on behalf of a team
I'm not sure what you mean. You mean that when there is a review
request for bzr-core, and you perform a review, that review request
isn't converted into a review request for Martin Pool? Or do you mean
that when you perform such a review, you want it to be attributed to the
team? As well as yourself?
> * add a field to the review form to set the new status of the mp
I don't think we want something that general. We wouldn't want people
voting "disapprove" and selecting "approve" as the status, for example.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAksLeOUACgkQ0F+nu1YWqI3gAwCdGe/BWVqvIxz0RNI+R/Eje4cV
9xIAn3oh9LCrFeE35xqcaFE8oVc5HsSk
=oDwi
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list