[RFC] Releases planning

[Stephen J. Turnbull]

Martin Pool writes:

 > The big difference is that calling it rc1 would imply we will make no
 > more changes other than critical bug fixes, whereas in practice it
 > seems ok to make safe non-api-breaking fixes to lower priority bugs
 > between the last beta and the .0.

I don't understand what kind of problem you're trying to fix here.

AIUI, the proposal was mainly to codify current practice.  Are users
complaining about delays, in terms of specific bugs that should have
been fixed?  If not, OK, maybe you can do fewer betas, but the
practice of having RCs has been working.  AFAIK, your users are
incredibly loyal.  I believe this is mainly due to (1) a design that
fundamentally works for them, and (2) regular, large improvements that
arrive on schedule.  Not a plethora of minor bug fixes.  I don't see
where your release process needs *immediate* improvement.

I don't think you need to compete with git or Mercurial on incremental
content of each release.  Especially not in the context of your recent
report that the number of pending bugs is actually going down.  While
I think that's the result of some excellent changes in process
(especially the patch pilot initiative) that have helped address those
bugs, I don't think in the current competitive environment further
reducing pending bugs is a good idea.  You want them going *up*
(slowly, especially RFEs), because that means you're getting new
users, new use cases, and your newer features are being exercised in
ways you hadn't thought of.  This kind of bug is often not so easy to
resolve, so they linger for a while.

IMO, you should take this progress on the pending bug front as a
signal to shift resources toward some of the "big picture" stuff: the
2GB limit, still excessive (in terms of common hardware) resource
usage, better large binary handling (perhaps including more generic
features like a plugin architecture for diff and merge operations,
along with a collection of useful plugins, and interfaces to allow
configuring the right diff/merge for different kinds of content),
better handling of modularized projects (scmproj et amis) and
education of users about the great improvement in colocated branch
handling.  These are the kinds of things that I see every day on
bazaar at canonical, and the users are saying that they can't get them
from hg or git either (so there's no point in putting up with the git
UI ;-).  Of course those take more time, but a couple of months lead
over git/hg on any of those features means more, and solid, market
share.

And yes, documentation (hi, Eli!)  Especially for some of the advanced
user plugins like looms and pipelines.  But also in general the
implications of things like branch binding for update vs pull are not
intuitive for most users yet (and may never be -- the semantics of
such commands also differ substantially from both CVCSes and other
DVCSes), while "bzr help" basically assumes that the implications are
understood.

But for the release process, I think you should stick with what
clearly *is* working until (a) it's been formalized and documented,
and (b) a need for change or a strategic opportunity that can be
addressed by a process change is identified.