user-oriented news

[Vincent Ladeuil]

>>>>> Martin Pool <mbp at canonical.com> writes:

    > On 12 October 2010 00:51, John Arbash Meinel <john at arbash-meinel.com> wrote:
    >> I don't think I've ever heard this advice before. Especially the
    >> "quoting the error you get" part.

    > You may well be right.

    > Do you think it's a reasonable policy?  If so, I'll see about
    > describing it more clearly in the docs.

Sounds like a good plan.

    >> These were also never clearly defined to me. I always felt that Internal
    >> changes were a bit unclear and just put everything into Compatibility.
    >> Certainly that has always been the advice on Merge Proposals ("that
    >> needs a section in Compatibility", never "that needs a section in
    >> Internals")
    >> 
    >> I think I only used Internals for *new* apis. Stuff that people might
    >> want to use, but not stuff that might 'break'.

    > I think internals should be "things people developing bzr or plugins
    > would want to know about", perhaps changes in the way we do things.
    > Even then perhaps that's better put into updates to the developer
    > guide.

    > Looking back over the entries under "internals" that exist today, most
    > do not have much value.  They are either too small, or they're really
    > bug fixes or performance improvements, or api breaks.  Therefore
    > perhaps we should delete it.


    >> Maybe it was covered in HACKING, I'll certainly admit that I don't
    >> really read that document, vs just using experience-to-date from being
    >> part of the project.

    > That particular document is too big, but also people doing ongoing
    > work aren't likely to sit down and read it just to see what's new...

bzr diff -rbzr-2.2.1 ./doc/developers

is quite good at telling you what's new from a dev pov and the knob
pretty easy to use with tags (and dwim revspecs).

   Vincent