users overservations on the plugin handling

[Martin Pool]

2009/8/25 Ian Clatworthy <ian.clatworthy at canonical.com>:
> timmichelsen at gmx-topmail.de wrote:
>>> At a minimum, it would be great to have your above thoughts recorded in
>>> our bug tracking system. Creating a blueprint would be better still.
>> Please give me feedback whether you want it as blueprint of single bugs items. See also the other mail.
>
> I wish I could say all the core developers agree on this but we don't.
>
> *I* find blueprint a useful way of collecting my thoughts and presenting
> one or more candidate designs for proposed new features. By "blueprint",
> I mean a Wiki page following a general template: it may or may not have
> a linked blueprint in Launchpad for tracking purposes. We don't use the
> latter much if at all in Bazaar development currently.

I think we need to distinguish several phases that the Launchpad
blueprint concept fuses together.

When people want to gradually put up their feature ideas as something
to take into account in the future then a wiki page is a good idea.
It lets them see or respond to what's already been said.  If you look
at the content filtering page (as I did today) then it does this
reasonably well.

I don't think wiki pages are a great place to have a conversation, or
to have a report of the current status, or to have an expression that
we've agreed to do something a particular way.

If we want to agree on a design so that someone can confidently go
ahead with implementations then that's probably better done through
either an rfc list thread or a merge proposal.

It's good to use bugs for things that can be solved atomically.  If
there are many bugs that will be solved by addition or redesign or a
whole system then it becomes a bit unwieldy.  It may still be worth
keeping the bugs but you need something that gives a bigger picture.

The big advantage of a wiki page is that it lets people see what's
already been said in one place more easily than for a list archive or
a bundle of bugs.  So it lets people see what they have to add that's
new quickly and efficiently.

> See http://bazaar-vcs.org/DraftSpecs/BetterNewUserUI for a high level
> blueprint example including links to numerous smaller ones.
>

It's good that this is fairly clearly marked as draft, because people
have been confused in the past about whether something's been done.
It's very easy for wiki pages to be out of date.

> So my *suggestion* is this:
>
> 1. Write up your thoughts as a blueprint wiki page using the above
>   blueprints as a guide w.r.t. headings, etc.

Surely there is already a spec for this, so find that first and update it.

> 2. Create a bug (for tracking purposes) and reference the Wiki page
>   from there.

Don't file a bug like "bzr should have a better plugin system" because
it's atomic: it's not clear when it can be closed.  A bug like "want a
builtin facility to upgrade plugins" or "bzr should support loading
plugins from eggs" is actionable.  (There may be bugs for those two
already.)

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