Merge lp:~vila/bzr/devnotes into lp:~bzr-core/bzr/devnotes

Proposed by Vincent Ladeuil on 2011-05-12
Status: Merged
Merged at revision: 58
Proposed branch: lp:~vila/bzr/devnotes
Merge into: lp:~bzr-core/bzr/devnotes
Diff against target: 0 lines
To merge this branch: bzr merge lp:~vila/bzr/devnotes
Reviewer Review Type Date Requested Status
Jelmer Vernooij (community) code 2011-05-12 Needs Information on 2011-05-18
Review via email: mp+60803@code.launchpad.net

Description of the change

I updated my notes on config to better reflect the actual situation and integrate some discussions.

Feedback welcome.

To post a comment you must log in.
Jelmer Vernooij (jelmer) wrote :

Is it necessary to rename bazaar.conf in ~/.bazaar and /etc/bzr to defaults? It seems like that will be a painful transition, and one of which I wonder if it's really necessary.

Martin Pool (mbp) wrote :

On 13 May 2011 09:39, Jelmer Vernooij <email address hidden> wrote:
> Is it necessary to rename bazaar.conf in ~/.bazaar and /etc/bzr to defaults? It seems like that will be a painful transition, and one of which I wonder if it's really necessary.

+1

lp:~vila/bzr/devnotes updated on 2011-05-13
51. By Vincent Ladeuil on 2011-05-13

Clarify the know problems about compatibility.

Vincent Ladeuil (vila) wrote :

>>>>> Jelmer Vernooij <email address hidden> writes:

    > Is it necessary to rename bazaar.conf in ~/.bazaar and /etc/bzr to
    > defaults?

Well, I thought you agreed during reviews that we should call it 'user'
or where you referring to the internal class names only ?

    > It seems like that will be a painful transition, and one of which
    > I wonder if it's really necessary.

Well, it's supposed to make the transition easier instead ;) Or maybe it
will make *my*/our life easier instead of the user one ?

The idea is that 'defaults' will be preferred over 'bazaar.conf' during a
transition period before 'bazaar.conf' is obsoleted.

This allows changing the definition of the file content while still
allowing both to be used. And this seems to allow using bzr versions
that knows about the new scheme *and*

Whether or not we provide an automatic way to convert bazaar.conf to
defaults is still undecided at this point.

And that's mostly because what needs to be converted is still unclear.

Instead of describing the known and unclear issues here, I'll do that in
a further commit (already done as I forgot to send this mail ;)

Vincent Ladeuil (vila) wrote :

> And this seems to allow using bzr versions
> that knows about the new scheme *and*

And this allows using bzr versions that knows about the new scheme *and* bzr versions that *don't* know about the new features and semantics.

So we get a time period were we (and beta testers) can ensure we don't break stuff but at the same time can use the new features.

lp:~vila/bzr/devnotes updated on 2011-05-13
52. By Vincent Ladeuil on 2011-05-13

One more example

Martin Pool (mbp) wrote :

On 13 May 2011 11:31, Vincent Ladeuil <email address hidden> wrote:
>>>>>> Jelmer Vernooij <email address hidden> writes:
>
>    > Is it necessary to rename bazaar.conf in ~/.bazaar and /etc/bzr to
>    > defaults?
>
> Well, I thought you agreed during reviews that we should call it 'user'
> or where you referring to the internal class names only ?

I for one intended this only for the internal name.

>    > It seems like that will be a painful transition, and one of which
>    > I wonder if it's really necessary.
>
> Well, it's supposed to make the transition easier instead ;) Or maybe it
> will make *my*/our life easier instead of the user one ?
>
> The idea is that 'defaults' will be preferred over 'bazaar.conf' during a
> transition period before 'bazaar.conf' is obsoleted.
>
> This allows changing the definition of the file content while still
> allowing both to be used. And this seems to allow using bzr versions
> that knows about the new scheme *and*
>
> Whether or not we provide an automatic way to convert bazaar.conf to
> defaults is still undecided at this point.
>
> And that's mostly because what needs to be converted is still unclear.
>
> Instead of describing the known and unclear issues here, I'll do that in
> a further commit (already done as I forgot to send this mail ;)

What are the actual benefits of changing the file name?

Martin

Vincent Ladeuil (vila) wrote :

>>>>> Martin Pool <email address hidden> writes:

<snip/>

    > What are the actual benefits of changing the file name?

See the additional commit, but roughly, using different files simplifies
the migration by clarifying the semantic used in each file. It also
allows to migrate progressively from one to the other without having to
address *all* incompatibilities in one go.

lp:~vila/bzr/devnotes updated on 2011-05-17
53. By Vincent Ladeuil on 2011-05-13

Fix typo

54. By Vincent Ladeuil on 2011-05-14

Why DEFAULT is harmful as as section name.

55. By Vincent Ladeuil on 2011-05-16

PathMatcher and bzr config have different goals, don't try to make them use the same order in config files.

Jelmer Vernooij (jelmer) wrote :

19 + and override them in ``branch.conf``. (Allowing sections in 'bazaar.conf'
20 + (or introducing a new 'user.conf' allowing sections) can now address
21 + that.)
Syntax error: Expected ')'

+ configuration options have defined methods, other don't and this is
s/other/others/

+ can be envisioned: limiting the dict to a single level one, with simple
s/one/only ?

87 The option name space is organized as follow:
88
89 -* Bazaar itself defines all its constants as ``bzr.option_name``.
90 -
91 +* Bazaar itself defines all its constants as ``bzr.option_name`` or
92 + ``bzr.topic.option_name``, in short, the ``bzr.`` prefix is reserved
93 + for bzr itself,
94 +
I think having some structure in our option names is useful, but I'm not sure if we should be this strict about it. That said...

Everything in bazaar.conf will be related to bzr, so I'm not convinced it is all that useful to have that as a prefix.

Some things span multiple plugins or are generic, even if they currently live in a plugin. E.g. the branch status that we recently discussed seems generic enough that it could just be "branch.status". From a users point of view it shouldn't really matter what plugin it lives in.

Could we perhaps just require options to be prefixed with a relevant section if there is one? That section could happen to have the same name as a plugin, but could also be different.

+Since options values are text-only, and to avoid clashing with other option
s/options/option/

+bzr behavior, as well as the objects it acts upon, are configured
s/are configured/is configured

review: Needs Information (code)
lp:~vila/bzr/devnotes updated on 2011-05-19
56. By Vincent Ladeuil on 2011-05-19

More thoughts about name spaces based on jelmer's review.

Vincent Ladeuil (vila) wrote :

Thanks for the review !

>>>>> Jelmer Vernooij <email address hidden> writes:

    > Review: Needs Information code
    > 19 + and override them in ``branch.conf``. (Allowing sections in 'bazaar.conf'
    > 20 + (or introducing a new 'user.conf' allowing sections) can now address
    > 21 + that.)
    > Syntax error: Expected ')'

?
(Allowing ... (or introducing...)... that.)

<snip/>

    > I think having some structure in our option names is useful, but
    > I'm not sure if we should be this strict about it. That said...

    > Everything in bazaar.conf will be related to bzr, so I'm not
    > convinced it is all that useful to have that as a prefix.

Hmm, no, the plan is to allow plugins to put their options there without
having to introduce their own config files (in fact, some plugins
already put their options there). And the 'bzr' prefix indicates bzrlib
or bzr-core options as opposed to plugin specific ones.

    > Some things span multiple plugins or are generic, even if they
    > currently live in a plugin. E.g. the branch status that we
    > recently discussed seems generic enough that it could just be
    > "branch.status". From a users point of view it shouldn't really
    > matter what plugin it lives in.

True, but this leaves the door open for independent plugins to introduce
options that will collide only when both plugins are used and configured
which nobody may notice until very late in the game.

Hmm, maybe I'm overcautious again and proposing a solution instead of
listing the known problems :-)

    > Could we perhaps just require options to be prefixed with a
    > relevant section if there is one? That section could happen to
    > have the same name as a plugin, but could also be different.

Strictly speaking I wasn't planning to enforce any rule there, just
relying on the registry to detect the collisions (hmm, this addresses my
concern above... installing plugins with conflicting option names will
be detected quite early in fact ;)

Ok, more updates pushed.

Jelmer Vernooij (jelmer) wrote :

On Thu, 2011-05-19 at 08:42 +0000, Vincent Ladeuil wrote:
> >>>>> Jelmer Vernooij <email address hidden> writes:
>
> > Review: Needs Information code
> > 19 + and override them in ``branch.conf``. (Allowing sections in 'bazaar.conf'
> > 20 + (or introducing a new 'user.conf' allowing sections) can now address
> > 21 + that.)
> > Syntax error: Expected ')'

> ?
> (Allowing ... (or introducing...)... that.)
Sorry, as discussed IRL.. probably a bug in my parser... ;-)

> <snip/>
>
> > I think having some structure in our option names is useful, but
> > I'm not sure if we should be this strict about it. That said...
>
> > Everything in bazaar.conf will be related to bzr, so I'm not
> > convinced it is all that useful to have that as a prefix.
> Hmm, no, the plan is to allow plugins to put their options there without
> having to introduce their own config files (in fact, some plugins
> already put their options there). And the 'bzr' prefix indicates bzrlib
> or bzr-core options as opposed to plugin specific ones.
If the plugin options already have a prefix then we can distinguish the
bzrlib options from them because they don't have a prefix.

> > Some things span multiple plugins or are generic, even if they
> > currently live in a plugin. E.g. the branch status that we
> > recently discussed seems generic enough that it could just be
> > "branch.status". From a users point of view it shouldn't really
> > matter what plugin it lives in.
> True, but this leaves the door open for independent plugins to introduce
> options that will collide only when both plugins are used and configured
> which nobody may notice until very late in the game.
>
> Hmm, maybe I'm overcautious again and proposing a solution instead of
> listing the known problems :-)
I don't think this will actually be a big risk; and even if it ends up
being a problem we can simply rename one or the other.

Similarly, we don't require plugin commands to have a specific prefix.

> > Could we perhaps just require options to be prefixed with a
> > relevant section if there is one? That section could happen to
> > have the same name as a plugin, but could also be different.
> Strictly speaking I wasn't planning to enforce any rule there, just
> relying on the registry to detect the collisions (hmm, this addresses my
> concern above... installing plugins with conflicting option names will
> be detected quite early in fact ;)
Yeah, that would be a nice way to detect collisions.

Cheers,

Jelmer

lp:~vila/bzr/devnotes updated on 2011-05-28
57. By Vincent Ladeuil on 2011-05-28

Summarize the consensus reached with jelmer which seems to satisfy everybody.

58. By Vincent Ladeuil on 2011-05-28

Nit.

Vincent Ladeuil (vila) wrote :

I've summarize the points raised here and at the sprint and will land this, the discussion is by no means closed ! I'm still all ears, here, on the mailing list or on IRC.

Preview Diff

Empty

Subscribers

People subscribed via source and target branches

to all changes: