On 2014-06-25 09:43, roger peppe wrote:
About pre-review annotations, I agree with Ian that the code should be
documented
well enough that someone coming to it from scratch can understand it, but
I also wonder if there is a room for review-specific comments, talking about
reasons for the
On 2014-05-30 15:08, roger peppe wrote:
Two: a caller can deal better with some errors, given more detailed
information. You can help by attaching more information to the error (tags,
taxonomy, properties) but only on a best-effort basis. You accept that you
don't know exactly which errors
On 2014-05-29 09:50, roger peppe wrote:
On 29 May 2014 04:03, Tim Penhey tim.pen...@canonical.com wrote:
Errors are worth treating specially here because they're
they pass up through multiple layers, so it's very easy to break abstraction
boundaries by relying on specific error types. I
On 04/11/13 05:11, Tim Penhey wrote:
If the work has been abandoned and is not likely to be landed, mark the
merge proposal as rejected to get it off the list.
It's also good to mark the branch itself as abandoned in that case, so
that it will drop off the default branch listings.
Once you
On 04/10/13 12:26, John Arbash Meinel wrote:
We came to this because the Azure provider was adding the daily
stream to the search path. Which meant that we would find the daily
stream, parse it, not find anything and then stop. Without falling
back to the releases stream which has the actual
On 17/09/13 12:42, Andrew Wilkins wrote:
I don't think many people will disagree that deduplication of code is a
bad idea in general. However, as with database denormalisation, there
are exceptions to the rule. If in the process of deduplicating you make
things considerably more complicated to
