1.6 plans

[Martin Pool]

On Fri, Jul 18, 2008 at 11:05 AM, Ian Clatworthy
<ian.clatworthy at canonical.com> wrote:
> Martin Pool wrote:
>
>> Is there anything else, or any objection to the above?
>
> I'd actually like the content filtering stuff to land in 1.6 *if
> possible* because that would then allow various plugins (like eol)
> to begin to appear. I'm not sure though if we're close enough to
> agreement in order to land it and for everyone to be happy, so
> the right thing to do socially is to delay it. OTOH, if the changes
> needs to land it are small, it would be a shame if it missed the cut.
>
> There are two primary issues IMO:
>
> 1. the API plugin authors use to register filters
> 2. what impact the changes make when no filters are enabled.
>
> I'm happy with the abstraction in place for the first, though it
> may be more abstraction than needed.

I think John and I had some further comments on that patch, but you
may now have dealt with them.  Changing the API in future is certainly
possible.

> I'm yet to measure the latter. IIRC, the "don't bother checking
> the SHAs because we know the sizes differ" optimisation in iter_changes
> will no longer apply. I wonder how much difference that will make
> in practice?

I think it would be good to land it.  I do think we should at least
measure some typical operations on a large tree in the branch with the
api and without to make sure there is no substantial performance
impact.

Based on our discussion the other day I think removing that check of
the sizes will not be significant.

> We've made some great progress on win32 support this release. Adding
> the content filtering to the core so that an eol plugin can be tried
> out by early adopters would be well received by many I think. I
> appreciate that my content filtering patch isn't production
> strength yet. If we think the impact on those not using filters is
> acceptable though, I think it's worthy of inclusion as an experimental
> feature.



-- 
Martin <http://launchpad.net/~mbp/>