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

[Matthew D. Fuller]

On Sat, Nov 07, 2009 at 11:09:36PM +1000 I heard the voice of
Ian Clatworthy, and lo! it spake thus:
> Matthew D. Fuller wrote:
> > 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.

True.  But there's a gray area in the middle, where nobody's is
vetoing it, everybody's in favor of it in concept, but one or two
people have concerns that "shouldn't prevent this from landing, but
should be worked out sometime".  If you're a committer and this is
your code, you can go ahead and commit it without bringing down the
wrath of the gods, and deal with the 'later' stuff later.  But if it's
NOT your code, you're unlikely to step forward to commit it in that
situation.  So for us non-committers whose code ends up in that
state...


> > 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. :-(

Sadly, that was my point; I was being ironical   :|

I was actually thinking about 'update -r' at the time I sat down to
work on the DWIM.  But I figured it should only take a day or two to
get the DWIM stuff done, then maybe a week or so of back and forth to
get it landed, and then I'd be all warmed up and ready to try getting
'update -r' finished and merged finally.  Ah, those halcyon days of my
youth!


> 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?

Well, as I mentioend (or at least danced around), a real boost for a
contributor is not getting "here are some things you could fix", or
even "here are some things you can fix, and pseudo-almost-code for how
to fix them", but "here are some things you can fix; if you don't get
to it in the next day or two I'll polish it up and land it".

That's easy if core people are sitting around twiddling their thumbs.
But they're not.  They're busy already doing seriously important
stuff, that we don't want to just back burner.  But perhaps we should
try it; see what happens if, as a core dev, you (generic you) set
aside an afternoon every other week or something and turn a
practically complete but unpolished submission into something ready to
land.

Of course, this then leads to the situation where YOU then polish it
up, stick it in the review queue...  and then it sits around not
getting reviews.  But, y'know...   I don't know any other project that
has such a hard line review-before-commit policy as bzr.  And my OS,
of which I run the head, and which is a whole lot more complicated
than a VCS, doesn't blow up and eat my data.  Maybe there should be a
timeout; if you haven't had a review after 3 days, and you're
reasonably confident in it, just commit the damn thing already.  Why
don't we want to?  Maybe it's broken, but maybe we're just not sure of
the API, and once we land it we feel like we have to stick with it.
Well, leverage our now six-month cycle between stable releases, and
declare that we bloody well will break new API's before pre-release
stabilization.

Every one of these suggestions can have holes punched in it.  That's a
problem.  Everything's a tradeoff, but maybe we can reconsider where
we've got the dial set.  Of course, we've tried that before too, and
the discussions just wander somewhere...


-- 
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.