[MERGE/RFC] Userdoc Driven Design on the Bazaar 2.0 UI
mbp at canonical.com
Tue Jun 9 07:55:30 BST 2009
Martin Pool has voted reject.
Status is now: Vetoed
(I'm trying to clear out the BB queue, so want to concretely decide
about this one way or the other.)
I don't think we should merge this to bzr.dev as it stands (so I'll vote
reject), but there are several separately useful bits in it, and I'm not
rejecting the work that went into them.
Part of it is a tutorial for how to use different workflows at the
moment, and I think that's pretty clear. I really wouldn't want to add
another new document describing that though; it would just increase the
proliferation of overlapping documents. Perhaps it could merge into the
existing tutorials. Maybe you want to put up a different proposal that
> +Wouldn't it be neat if
I think this document is a little too enthusiastic in tone.
> +The feature branching model works like this:
I don't think "feature branching" means what you say it means here,
which is using stacked branches. To me, feature branches means that you
develop each bug or fix in a branch and then merge them together.
+**This is a new proposed feature. Please consider the idea and send
+your feedback to the mailing list.**
I'm not sure what the optimum place to cultivate new design ideas is,
but I don't think it's best to do it in documentation delivered to the
end user. I think at most there we should put a reference like "we're
thinking about better ways to handle X, see http://bazaar-vcs.org/blah".
My current theory is that the best thing is to put these in devnotes and
then alternate that with list threads or irc or voice conversations
about it. So that way we do have a more organized record than a mail
thread, but it doesn't clutter releases. If we want use input about one
proposal, we can probably ask for it on the list or blog or something.
As I said elsewhere, I think making checkouts lightweight would be good.
For details, see:
More information about the bazaar