Personal experiences/anecdotes of the bzr review processes

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Hammond wrote:
>> I don't think that's accurate.  See:
>> http://bundlebuggy.aaronbentley.com/project/bzr/request/<011301c90e83%2
>> 43d0d0d60%24b7272820%24%40com.au>
>> http://thread.gmane.org/gmane.comp.version-control.bazaar-
>> ng.general/45924/focus=46623
> 
> I'm sorry, but that link is currently offering:

> AttributeError: ("'NoneType' object has no attribute 'project_id'", <bound
> method Root.default of <bundlebuggy.controllers.Root object at 0x8fade8c>>)

You need to use the complete URL from "http:" to the last ">".  It does
work for me.  I'll fix that to give a 404 instead of an error.

>> John definitely approved the Sept 4 patch that Ian voted resubmit on.
> 
> Hrm -
> http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/45924/f
> ocus=46623 doesn't show any such approval.

Yes, it does.  It includes
http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/46718

> Are we expected to manually
> check the status of bundlebuggy for manual approvals for each patch we
> submit via the mailing list?

No.  Votes performed on the web UI are automatically mailed to the list.

> But even then, I'm surprised BB didn't pick up the second approval from Ian
> and merge it automatically.  I must be missing some part of the process?

Bundle Buggy doesn't merge anything, it only handles the patch tracking
and voting.  PQM handles the merging, and BB has no control over it.
Most of the reviewers also have the ability to submit to PQM.

Ian's approval was on a new submission, not the one John approved, so
John's vote didn't carry forward onto it.  We could discuss changing
that.  The drawback is that the changes in a new version might
invalidate an approval.

>> Also, I don't think it would have been out of line for you to ask Ian
>> to submit it.
> 
> I'm a little confused then as to why you didn't pick up that same state
> then?

I didn't realize that John had voted on a previous version.  Ian might
have, since he did vote on that previous version.  As the submitter,
you'd be paying closer attention than me.

>> Well, I didn't vote either way because I wanted your comments.  You
>> could say you think the issues I pointed out aren't worth fixing, and I
>> might well vote Approve.
> 
> I hope I did.  Does that mean you will?  It would be appreciated.

Yes, I think I will, on the assumption that John would have approved
this new version, and so I wouldn't have had a chance to review it.

>> I'm sorry that's been your experience.  We definitely want to improve
>> the process.  Do you have any suggestions?
> 
> I'd also suggest that a formal "style guide" (aka pep8 with bzr specific
> requirements) be adopted

I'm not sure what you're saying.  The "Coding Style Guidelines" section
of HACKING is meant to support this.  Do you mean:
- - It's not complete enough?
- - It's not formal enough?
- - It needs to be split out into a separate document?

> and if a patch is technically correct (ie, fixes
> the bug/correctly implements the feature) and doesn't violate a *specific*
> requirement in that style-guide, then all style related
> issues/suggestions/color-selections be dealt with independently of the
> technical issue being addressed.

We're currently discussing reducing the strength of the requirement for
"design clarity", and perhaps style issues should be addressed the same way.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI2Pm/0F+nu1YWqI0RAi5iAJ0bgAoaROjpf8gKfBRWtWEFmGr59gCgiTcn
MniV6Ll20CgIx5TxnflPQRQ=
=TQMk
-----END PGP SIGNATURE-----