brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guglielmo Nigri <guglielmo.ni...@cloudsoftcorp.com>
Subject Re: [VOTE] Create repo for new deliverable: CLI
Date Thu, 26 Nov 2015 10:32:30 GMT
+1 separate repo for the go language CLI




On 26 November 2015 at 01:56, Mike Zaccardo <mike.zaccardo@cloudsoftcorp.com
> wrote:

> +1 brooklyn-client in a sep. repo
>
> On Wed, Nov 25, 2015 at 4:01 PM Geoff Macartney <
> geoff.macartney@cloudsoftcorp.com> wrote:
>
> > + 1 on separate repo
> > +1 for brooklyn-client
> >
> >
> > ————————————————————
> > Gnu PGP key - http://is.gd/TTTTuI
> >
> >
> > > On 25 Nov 2015, at 20:57, David Lloyd <david.lloyd@cloudsoftcorp.com>
> > wrote:
> > >
> > > +1 for the change to brooklyn-client
> > >
> > > On 25 November 2015 at 17:55, Hadrian Zbarcea <hzbarcea@gmail.com>
> > wrote:
> > >
> > >> There are two parts for this vote, one the creation of a *separate*
> > repo,
> > >> second the *name* of the repo. The name of the repo matters less than
> > the
> > >> name of the delivered artifact and I agree that brooklyn-client is
> > slightly
> > >> more expressive than cli.
> > >>
> > >> +1 on the change. Agree we don't need another vote, unless the change
> > will
> > >> create contention, which is not likely imho, given the nature of the
> > >> amendment.
> > >>
> > >> Cheers,
> > >> Hadrian
> > >>
> > >>
> > >>
> > >>
> > >> On 11/25/2015 12:37 PM, Alex Heneveld wrote:
> > >>
> > >>>
> > >>> Changing vote:
> > >>>
> > >>>     +1 brooklyn-client
> > >>>
> > >>> If you've voted and you like this please consider changing!
> > >>>
> > >>> I know there are other types of clients (jsgui, stubs) but there are
> > >>> other CLI's also (e.g. server-cli).  brooklyn-client-cli would be
> > >>> possible, but I think the CLI is what we want to emphasise, and in
> the
> > >>> interest of simplicity the following feels pretty good and has a nice
> > >>> symmetry:
> > >>>
> > >>> * brooklyn-server
> > >>> * brooklyn-client
> > >>> * brooklyn-ui
> > >>>
> > >>> (Detailed updated discuss and vote for repos to follow.)
> > >>>
> > >>> Best
> > >>> Alex
> > >>>
> > >>>
> > >>> On 24/11/2015 15:00, Andrea Turli wrote:
> > >>>
> > >>>> +1 brooklyn-cli
> > >>>>
> > >>>> On Tue, 24 Nov 2015 at 15:59 David Lloyd <
> > david.lloyd@cloudsoftcorp.com>
> > >>>> wrote:
> > >>>>
> > >>>> +1 brooklyn-cli
> > >>>>>
> > >>>>> On 24 November 2015 at 14:05, Mark McKenna
> > >>>>> <mark.mckenna@cloudsoftcorp.com
> > >>>>> wrote:
> > >>>>>
> > >>>>> +1: brooklyn-cli
> > >>>>>>
> > >>>>>> On Tue, 24 Nov 2015 at 14:04 Aled Sage <aled.sage@gmail.com>
> wrote:
> > >>>>>>
> > >>>>>> +1: brooklyn-cli
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On 24/11/2015 13:59, Hadrian Zbarcea wrote:
> > >>>>>>>
> > >>>>>>>> Brooklyners,
> > >>>>>>>>
> > >>>>>>>> Given the feedback on the [HEADS-UP] thread to
David and Geoff's
> > >>>>>>>> proposal, I move to starting a vote for the creation
of a
> separate
> > >>>>>>>>
> > >>>>>>> git
> > >>>>>
> > >>>>>> repo: brooklyn-cli. Tthe vote is both for the creation
of the
> repo,
> > >>>>>>>> and its name. The name with the largest number
of vote wins,
> > unless
> > >>>>>>>> strong objections will send us back to the drawing
board. This
> > vote
> > >>>>>>>>
> > >>>>>>> is
> > >>>>>
> > >>>>>> *not* for the name of the executable (br or bk).
> > >>>>>>>>
> > >>>>>>>> [+1] brooklyn-cli (create repo with this name:
a heneveld
> > proposal)
> > >>>>>>>> [+1] brooklyn-commons-cli (create repo with this
name: mzaccardo
> > >>>>>>>> proposal)
> > >>>>>>>> [-1] we do not need a separate repo
> > >>>>>>>>
> > >>>>>>>> Please cast your vote. The vote is open for 72+
hours.
> > >>>>>>>>
> > >>>>>>>> Cheers,
> > >>>>>>>> Hadrian
> > >>>>>>>>
> > >>>>>>> --
> > >>>>>>>
> > >>>>>> *Mark McKenna*
> > >>>>>>
> > >>>>>> *Twitter :: @m4rkmckenna <https://twitter.com/m4rkmckenna>*
> > >>>>>>
> > >>>>>> *PGP :: public-key
> > >>>>>> <https://pgp.mit.edu/pks/lookup?op=get&search=0x2B5DC759B1EB76A7
> >*
> > >>>>>>
> > >>>>>>
> > >>>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message