supplement open--port/close-port with ensure-these-and-only-these-ports?

[Gustavo Niemeyer]

Reminding people of everything they should *not be doing *to get a feature
to be listed in the release notes is very ineffective.

What should they *be doing* instead, and why will the process work in the
future when it clearly has failed before, despite the assumed good
intention we should assume all trusted developers to have?


On Mon Nov 03 2014 at 1:20:30 PM Curtis Hovey-Canonical <
curtis at canonical.com> wrote:

> On Sat, Nov 1, 2014 at 2:08 PM, Kapil Thangavelu
> <kapil.thangavelu at canonical.com> wrote:
> >
> >
> > On Sat, Nov 1, 2014 at 12:58 PM, John Meinel <john at arbash-meinel.com>
> wrote:
> >>
> >> I believe there is already "opened-ports" to tell you what ports Juju is
> >> currently tracking.
> >
> >
> > That's cool and news to me, it looks like it landed in trunk earlier on
> > october 2nd (ie 1.21) and hasn't made release notes or docs yet.
> Especially
> > for charm environment changes we really need corresponding docs as charm
> env
> > changes are not easily discover-able otherwise. Really great to see that
> > land as its been a common issue for charms and one that previously forced
> > them into state management.
>
> :( How will anything get into the release notes if engineers don't
> announce the new feature when it merges? It is not the not release
> note because engineers haven't described it.
>
> Asking questions to this list to discover new features isn't very
> efficient.
>
>
> --
> Curtis Hovey
> Canonical Cloud Development and Operations
> http://launchpad.net/~sinzui
>
> --
> 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/20141103/33ef647e/attachment.html>