No subject

very important something 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.

Lacking tests are probably the largest single block in this area, but
I don't think that covers the majority of cases.  Patches get
responses like "this is good, but X, Y, and Z", which may be
capricious but certainly aren't always, or even usually.  But that's
the END of it; the submitter either fixes it themselves, or it'll sit
there until doomsday.  It's not the common case at all that somebody
fixes part of a problem, or gets it working but rough, and that's
taken and fixed up as necessary and dropped in.

For people who are to become committers or heavy contributors, that's
just peachy; they LEARN the expected standards for the code, and a
feel for how it should be structured, yada yada.  But it's a *VERY*
*BAD* thing for casual contributors, who wrote a patch to scratch an
itch they had with bzr, rather than to improve bzr generally.  It's a
great way to teach them "don't bother trying to give us patches, we're
too busy with our own stuff", and they won't next time.  And while it
doesn't really have anything to do with "Canonical ownership", it's a
impression that dovetails very strongly with "bzr is a Canonical
project" into a doubly whammy of demotivation.

          ---------------------------------------------------

Certainly _my_ experiences in contributing code haven't done anything
to motivate me to do more of it.  I'll never be a committer or
top-tier contributor, because I already have a list longer than my arm
of things nearer to my heart and technically better fit to my
predilections to work on, and not near enough time for them.  I'll
only ever be a casual contributor.  And acting that position is no fun
at all in bzr.

I don't feel like anybody has any animus against me specifically, or
that there's a cabal of insiders working against outsiders generally.
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; far more so than the whole thing up to then.

First, I'll submit it.  I'll either get a few reviews in the first ~24
hours, or I'll wait a few weeks, then pester a bunch of people for a
while, and eventually someone will get to it.  That review will list
several issues, often minor (which isn't to say unimportant; they
often are things that SHOULD be dealt with before landing it).  Then I
wait for the next block of time I can commit to bzr work.  Repeat
about 5 times, until nobody has any significant complaints, and at
least one person is enthusiastic enough about it to actually LAND it.


Easy example; DWIM revspecs.  Here's a blow by blow:

I posted the patch on July 25, explicitly with detailed known issues
needing fixing, asking for feedback.  In particular, I asked for help
on the doc-related changes (were totally untested, and wording could
probably be improved), and feedback on what to do with some testing
issues.  One mailed response from a dev saying "I haven't looked at
the changes, but the general idea sounds OK to me", one or two similar
things heard on IRC, over the next ~24 hours.  After that: nothing at
all.

Next block of time I get to work on bzr stuff (just under a month
later), I carefully read and evaluate the no-feedback, and based on
that I make wild guesses about how to address my outstanding
questions, do those fixups (minor test cleanup), and submit it again
on August 18th.  This time, insofar as I can tell, it's ready for
merging, and claim it so.  About 2 weeks after that, there's a
response suggesting an additional capability that would be nice to
have with it, though stipulating that it need not block anything
happening now.  But hey, it didn't need to block however important it
was, because what happened: zero.


Well, now we sit around until I once again have time to poke at it.  I
bring it up to date with bzr.dev changes, make one more substantive
change (adding a test which may be unnecessary, but occured to me as
part of a category of things to be protected against regression), and
submit it again.  Ah!  THIS time I finally hit gold.  4 days later, I
get a review that brings up some questions and issues.  We discuss
them on IRC and mostly get them cleared up, except for one point of
disagreement.  That gets shunted to a list discussion hopefully come
up with a concensus (rather fails at doing so; it just ends up with
the same disagreement, with more people on both sides.  Oh well  ;).
But it's a fairly minor point; practically everybody on either side
expresses opinions like "I prefer X, but it's probably not a huge
deal, and I wouldn't block ~X".

A day or so into that, another review is asserting "No, this isn't IMO
acceptable as-is, it should be redone <this other way>".  Well...  OK,
it's not an unreasonable position, and the other way does have
advantages.  But, y'know, couldn't you have mentioned that 3 bloody
months ago when I specifically asked for comments?  Or 2 months ago
when I said it was finished and asked for it to be merged?  Some
discussion follows, and in the end the reviewer's position is encoded
as roughly "This should be the end state, but I'm OK with it being a
future enhancement".

This lands us in exactly the situation I talk about way above in my
second paragraph; if I were a committer, at this point I would have
Just Committed it.  And I wouldn't have been strongarming or breeching
ettiquette in doing so; I had essentially universal agreement in
general, mild non-blocking disagreement on a single point, and
preferences for future direction on another.  But I'm not a committer;
I can't Just Commit it.  And because of the lack of universal "yay, go
ahead", it's not something another committer is going to go ahead and
Just Commit on the strength of its technical approval; they'd have to
be directly and personally interested in it to put their name behind
it.

And eventually, that happened; about a week down the line, a committer
DID personally adopt it, made the changes that covered that future
enhancement (and far better and easier than I would have been able
to).  That was submitted, and still sat around for the better part of
a week (demonstrating that even with the imprimatur of the Vatica^W^Wa
committer, things don't just hop skip and jump right in), and then in
a flurry of discussion it was merged.  Phew.

If it HADN'T been adopted, I'm confident that, despite approval
sufficient to land, it wouldn't have landed yet.  I know I wouldn't
have had time yet to do the extra work to take it from "reserved
approval" to "unreserved adulation", which would have been necessary
for an unadopted commit.  It would probably be next year at the
earliest.  It may well have been never, exciting and motivating as the
experience was.  And the resulting code wouldn't have been as good
either.


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"!

          ---------------------------------------------------

It ties into the same champion scenario as above, actually; either get
a committer to take ownership of it and help drive it through that
last 10% of the work and 90% of the time, or resign yourself to a long
series of back and forths.  And the phrasing is intentional; you have
to *GET* a committer to take it, rather than a committer *TAKING* it.

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.  The stuff that needs to be done takes
manpower, and there's no manpower left.  But it's a vicious circle.
The shortage of developer cycles to make contributors feel welcome in
the strongest way (by sucking up the contributions and getting them
jammed in as quickly as humanly possible) discourages random casual
contribution.  Casual contribution are major contribution are not
indepedent variables, so you get less random major contribution.  That
leads to a shortage of developer cycles.  Rinse, repeat.

But if you want more contribution, you NEED committers ready to pick
up incomplete submissions, complete them, and GET THEM IN.  There's no
substitute.  Really.

          ---------------------------------------------------

There are 3 positions people can have regarding bzr being a
Canonical-owned project (whether it IS in fact, whatever that may
mean, is irrelevant, only the perception, and I don't think it's
arguable that the perception exists both among people who know nothing
of bzr and those closely following it).  It can be a turn-on, a
turn-off, or generally irrelevant.

To me, it's not in and of itself too relevant.  I'm a BSD guy, not a
GNU guy; we LIKE companies paying programmers  8-}.  But I very much
think that, of the groups occupying the other two positions, the group
for which it's a turn-off are *MUCH* more likely than those to whom
it's a turn-on, to spawn people who become developers who can throw
cycles into these holes.  THAT (to allude to the major point of the
thread rather than straight hijacking it) is a way in which a
perception of being a Canonical project rather than a community one is
a serious ill in the long term.  And I think if we want to discuss
whether it's a plus or minus, concentrating on that particular point
is the most fruitful way to head in the rough direction of a
conclusion.



-- 
Matthew Fuller     (MF4839)   |  fullermd at over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.