"environment" vs "model" in the code

[William Reade]

On Wed, Jan 20, 2016 at 4:19 AM, Ian Booth <ian.booth at canonical.com> wrote:

> I'm a firm -1 to using old terminology for new work.
>
> Doing anything other than using the new terminology for new work is simply
> kicking the can down the road. We don't have time for re-work. We are
> currently
> undetaking the rename of CLI, associated text, api parameters etc - the
> outwardly facing artifacts. I'm sure we can all deal with a little
> inconsistency
> for a short time. There will be inconsistency anyway with the current in
> progress work.
>

Yeah, we can't dodge some degree of inconsistency, whatever we do; and
every env-thing in the code might *already* refer to either an environment
(which should be renamed) or an environ (which should not). Let's start as
we mean to go on and use "model" wherever we can.

Cheers
William


>
> On 18/01/16 10:35, Menno Smits wrote:
> > +1 to what Roger said. New features always require changes to existing
> code
> > so inconsistency is unavoidable if we take a piecemeal approach.
> >
> > Given that a big rename is planned at some point, and that renaming can
> be
> > largely automated, continuing to use "environment" internally until the
> big
> > rename happens may make more sense in terms of maintainability.
> >
> > Thoughts?
> >
> >
> >
> > On 15 January 2016 at 21:05, roger peppe <roger.peppe at canonical.com>
> wrote:
> >
> >> On 15 January 2016 at 06:03, Ian Booth <ian.booth at canonical.com> wrote:
> >>>
> >>>
> >>> On 15/01/16 10:16, Menno Smits wrote:
> >>>> Hi all,
> >>>>
> >>>> We've committed to renaming "environment" to "model" in Juju's CLI and
> >> API
> >>>> but what do we want to do in Juju's internals? I'm currently adding
> >>>> significant new model/environment related functionality to the state
> >>>> package which includes adding new database collections, structs and
> >>>> functions which could include either "env/environment" or "model" in
> >> their
> >>>> names.
> >>>>
> >>>> One approach could be that we only use the word "model" at the edges -
> >> the
> >>>> CLI, API and GUI - and continue to use "environment" internally. That
> >> way
> >>>> the naming of environment related things in most of Juju's code and
> >>>> database stays consistent.
> >>>>
> >>>> Another approach is to use "model" for new work[1] with a hope that
> >> it'll
> >>>> eventually become the dominant name for the concept. This will however
> >>>> result in a long period of widespread inconsistency, and it's unlikely
> >> that
> >>>> things we'll ever completely get rid of all uses of "environment".
> >>>>
> >>>> I think we need arrive at some sort of consensus on the way to tackle
> >> this.
> >>>> FWIW, I prefer the former approach. Having good, consistent names for
> >>>> things is important[2].
> >>>>
> >>>
> >>> Using "model" for new work is the correct approach - new chunks of work
> >> will be
> >>> internally consistent with the use of their terminology. And we will be
> >> looking
> >>> to migrate existing internal code once we tackle the external facing
> >> stuff for
> >>> 2.0. We don't want to add to our tech debt and make our future selves
> >> sad by
> >>> introducing obsoleted terminology for new work.
> >>
> >> The other side of this coin is that, as Menno says, now the code base
> >> will be harder to read because it will be inconsistent throughout (and
> >> not consistently inconsistent either, because the new work is bound to
> >> cross domain boundaries).
> >>
> >> Given that it's not hard to make automated source code changes in Go
> >> (given gofmt, gorename, gofix etc), I wonder if doing it this way might
> >> just be making things harder for people maintaining the code without
> >> actually making things significantly easier in the long run.
> >>
> >>   cheers,
> >>     rog.
> >>
> >> --
> >> Juju-dev mailing list
> >> Juju-dev at lists.ubuntu.com
> >> Modify settings or unsubscribe at:
> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >>
> >
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160120/be1035e2/attachment-0001.html>