Things to remove for 2.0

[Matthew D. Fuller]

On Sat, Jul 25, 2009 at 07:58:24AM +1000 I heard the voice of
Martin Pool, and lo! it spake thus:
> 
> getting rid of 'ci --local' and everything associated with it would
> take some more work.  Possibly if we agree we'll go that way just
> removing that one option would be a start, and would stop people
> creating new data in that form, and then we can gradually work
> through the consequences.

I did mean just removing the option.  i.e., just

=== modified file 'bzrlib/builtins.py'
-             Option('local',
-                    help="Perform a local commit in a bound "
-                         "branch.  Local commits are not pushed to "
-                         "the master branch until a normal commit "
-                         "is performed."
-                    ),

(well, probably a few other lines of code will need to be touched to
excise it, but roughly that)

Depending on how you broadly construe it, "everything associated with
it" can pretty much mean "distributed development capability", and I
don't think we want to remove that before 2.0.  Maybe after   ;-}

There are any number of ways to end up in the situation you get to
after ci --local.  The most obvious is unbind ; commit ; bind.  I'm
not nearly so worried about problems coming from that, because running
unbind is an easily understood explicit statement that you now want to
work on a branch independently of $BOUNDLOC.  Having the
command/option "ci --local" makes it too easy to DO that without
necessarily THINKING that's what you're doing, and that's how trouble
starts.


> Is this a good time in particular?  I don't think we have a very
> clear sense of a cycle longer than monthly releases, and perhaps we
> should.  Within a release, we tend to say that disruptive changes
> should go in near the start of the cycle.

Well, I raise them because IMO, this sort of thing is [relatively]
easy to get away with when you $MAJOR_VERSION++, and very hard to do
otherwise.  So doing them in 1.18 wouldn't be great, but doing them in
2.1 would be bad too.  So if we don't do it as we release 2.0, we
can't do it before 3.0 (and in the case of clone, ideally we'd have
its new meaning in 3.0, which makes it REALLY nasty).  Code-wise,
removing a command alias or option is trivial, so I don't think
there's any actual programmatic risk.  The risk is all higher in the
stack in bzr itself, but beginning/end of cycle doesn't make that much
difference on that.  The people it would affect mostly either read the
list, or won't see it 'till it's released anyway.



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