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

[Ian Clatworthy]

Hi Matthew,

Thank-you for caring enough to outline your frustrations. You're
certainly not alone, nor an isolated case. I know of several
contributors who make huge contributions to Bazaar's ecosystem but can't
be bothered submitting patches to the core because the experience can
be, and frequently is, so unrewarding.

Personally, I think this is the biggest issue we need to get sorted out.
I hope your email proves a catalyst for that.

Matthew D. Fuller wrote:

> I certainly know that it's not the case that committers have an easy
> free ride on getting their patches in either.  But committers by
> virtue of their position have an advantage in that they can just
> COMMIT it.

Actually we can't. We still need to find someone else to approve it and
for no-one else to veto it. Anything remotely complex (like content
filtering) is a nightmare to get landed if no-one else is *passionate*
about improving that area.

>> I'm willing to point directly at as a
> deficiency in the Process.  To put it shortly and bluntly:
> 
>     If you don't essentially FINISH your entire contribution yourself,
>     it will never become part of bzr.

I agree this is the core of the process problem.

> Certainly _my_ experiences in contributing code haven't done anything
> to motivate me to do more of it.

And that's how projects become second rate: one contributor at a time.

> But I know that getting the code from the "works fine" point to the
> "in bzr.dev" point is going to be a long, miserable, exhausting
> process

Part of the problem is that "works fine" means different things to
different people. Most people submitting patches care mostly about the
"business value" of their code: it solves a bug or requirement and is
therefore "good enough". Rightly or wrongly, stuff like API design and
testability are less important to the majority of submitters. OTOH, the
core contributors *must* care about these or the overall technical debt
gets out of control.

The effect is predictable: only really simple patches, or those with a
champion, get through in a timely manner. The base still evolves but not
necessarily as rapidly as it could. The majority of innovation moves to
the plugin layer.

Maybe we care too much about the internals? Maybe we ought to take a
more pragmatic view on whether code should land or not? If a patch
clearly fixes a bug and doesn't have all the tests it ought to, should
we still land it? There's no right answer, despite how fiercely
developers argue about these things.

> Elapsed time; just over 3 months.  Time I spent on the code and tests:
> 4 or 5 hours, maybe?  Probably 2 or 3 hours on list and IRC discussion
> about it.  *I'M* sure all fired up and totally want to do more with
> this project now; aren't you?  Why, heck, it was even easier and
> quicker than the cakewalk that was landing "update -r"!

IIUIC, "update -r" hasn't landed and doesn't currently have a champion. :-(

> It's not easy to solve.  It's not like the committers are sitting
> around twiddling their thumbs, being all "Gee, I wish somebody would
> give me some code to get integrated"; they're up to their teeth
> already in WORKING on the code.

All teams suffer from the "there's too much to do and not enough
resources" problem though.

Let's be brutally honest ... Bazaar is *Python* and a tool by developers
for (mostly) developers. Contributing to it *ought* to be a pleasure.
Please step forward with your ideas on how we can make it that. How do
other successful open source projects solve this? What can we learn from
others?

Ian C.