Defining specific problems and handwaving at solutions (was Re: What's Canonical thinking about Bazaar?)

[John Arbash Meinel]

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

Matthew D. Fuller wrote:
> On Sat, Nov 07, 2009 at 11:09:36PM +1000 I heard the voice of
> Ian Clatworthy, and lo! it spake thus:
>> Anything remotely complex (like content filtering) is a nightmare to
>> get landed if no-one else is *passionate* about improving that area.
> 
> So here's another idea.  Use an ADVANTAGE of that "everybody's
> Canonical" status, so it can be declared by fiat "OK, look, this week
> EVERYBODY is thinking about and working on X".  Content filtering and
> its dependancies like per-branch/tree config could desperately benefit
> from this.  So could nested trees.
> 
> It may be that the biggest problem with these complex things is that
> everybody's pretty much working on different things, so anything
> that's going to require broad buy-in is toast.  Everybody cares about
> it, everybody has good and important input, and everybody puts in half
> a day on it, but they're all scattered a month apart.  Batch
> processing FTW!
> 
> 
> Yep, I know that won't work either, because all the different things
> everybody's working on are desperately important too.  Sigh.
> Manpower.
> 
> 

Actually, Martin outlined that as a specific point a while back. Namely
"major changes like content filtering should be done as a focus group".
Like was done with the --2a format. It started with one and then a
couple devs, and then it became a focus where pretty much all of us were
working on it in some fashion.

I think it would be good to spend some time with at least a few people
focused on content filtering. I think Martin has a very valid concern
that right now content filters are "ad hoc". In that you have to teach
all the code that touches files about filters. Rather than having it
abstracted at an appropriate layer.

I think the last time we did something like that was Stacked Branches,
and we *still* suffer from it[1]. Because it isn't abstracted nicely,
you can't just add a permutation to the test suite and know that
everything works correctly.
Instead, you have to write a whole new set of tests that cover
everything the test suite already covers, plus this new permutation.


That sort of change is sufficiently large that I think it really does
benefit significantly from a large number of developers, making sure the
API is reasonable, etc. (Stacked Branches also suffered and languished
from being done by one developer who handed-off at the last minute,
rather than a focused dev by a few of us.)

John
=:->



[1] I should also caveat that Stacked Branches were implemented using an
abstraction in the VersionedFiles layer (so that if you asked for
something from branch X stacked on Y that it didn't have, it would make
the request to Y for you, so you didn't have to think about it.) And
then the smart server changes basically broke that abstraction
(accessing X via bzr+ssh no longer tells it to access Y). Which means
that failures are only seen when accessing a stacked branch via a remote
action, because the abstractions we *do* have leak like a sieve.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr1phUACgkQJdeBCYSNAAOG2wCgnf4kgS9oQthhtLUo9AM5tJ6u
PPYAoM+whhbUV6S18In3bd5EIU4EwMhT
=nudY
-----END PGP SIGNATURE-----