You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Hadrian Zbarcea <hz...@gmail.com> on 2015/11/24 14:59:19 UTC
[VOTE] Create repo for new deliverable: CLI
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
Re: [VOTE] Create repo for new deliverable: CLI
Posted by Ciprian Ciubotariu <ch...@gmx.net>.
+1 brooklyn-client
On Wednesday 25 November 2015 17:37:58 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 <da...@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 <al...@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>*
Re: [VOTE] Create repo for new deliverable: CLI
Posted by Robert Moss <ro...@cloudsoftcorp.com>.
sorry, Hadrian, just read your message on [DISCUSS] I'll not confuse things
with a "+0"
+1 brooklyn-cli
On 26 November 2015 at 17:13, Robert Moss <ro...@cloudsoftcorp.com>
wrote:
> +1 new repo
> +0 named brooklyn-client
>
> On 26 November 2015 at 10:32, Guglielmo Nigri <
> guglielmo.nigri@cloudsoftcorp.com> wrote:
>
>> +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 <hz...@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 <al...@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
>> > >*
>> > > >>>>>>
>> > > >>>>>>
>> > > >>>
>> > >
>> > >
>> >
>>
>
>
Re: [VOTE] Create repo for new deliverable: CLI
Posted by Robert Moss <ro...@cloudsoftcorp.com>.
+1 new repo
+0 named brooklyn-client
On 26 November 2015 at 10:32, Guglielmo Nigri <
guglielmo.nigri@cloudsoftcorp.com> wrote:
> +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 <hz...@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 <al...@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
> > >*
> > > >>>>>>
> > > >>>>>>
> > > >>>
> > >
> > >
> >
>
Re: [VOTE] Create repo for new deliverable: CLI
Posted by Guglielmo Nigri <gu...@cloudsoftcorp.com>.
+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 <da...@cloudsoftcorp.com>
> > wrote:
> > >
> > > +1 for the change to brooklyn-client
> > >
> > > On 25 November 2015 at 17:55, Hadrian Zbarcea <hz...@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 <al...@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
> >*
> > >>>>>>
> > >>>>>>
> > >>>
> >
> >
>
Re: [VOTE] Create repo for new deliverable: CLI
Posted by Mike Zaccardo <mi...@cloudsoftcorp.com>.
+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 <da...@cloudsoftcorp.com>
> wrote:
> >
> > +1 for the change to brooklyn-client
> >
> > On 25 November 2015 at 17:55, Hadrian Zbarcea <hz...@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 <al...@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>*
> >>>>>>
> >>>>>>
> >>>
>
>
Re: [VOTE] Create repo for new deliverable: CLI
Posted by Geoff Macartney <ge...@cloudsoftcorp.com>.
+ 1 on separate repo
+1 for brooklyn-client
————————————————————
Gnu PGP key - http://is.gd/TTTTuI
> On 25 Nov 2015, at 20:57, David Lloyd <da...@cloudsoftcorp.com> wrote:
>
> +1 for the change to brooklyn-client
>
> On 25 November 2015 at 17:55, Hadrian Zbarcea <hz...@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 <da...@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 <al...@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>*
>>>>>>
>>>>>>
>>>
Re: [VOTE] Create repo for new deliverable: CLI
Posted by David Lloyd <da...@cloudsoftcorp.com>.
+1 for the change to brooklyn-client
On 25 November 2015 at 17:55, Hadrian Zbarcea <hz...@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 <da...@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 <al...@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>*
>>>>>
>>>>>
>>
Re: [DISCUSS] Create repo for new deliverable: CLI <- client project
name and language binding discussion
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
@Robert-
Thx for explanation. For me it's about emphasis. The message of this
proposal for code-browsers is:
* brooklyn-client is *the* main client you should use; look at it and
you'll see it's a cli, and it happens to be written in go, but that's
not relevant at a high level
* there is also a ui, obviously at brooklyn-ui
* there is a rest client binding for java but currently it's buried;
these might be promoted at some point but they'd never be the main
client project; I expect they'd be called something like
brooklyn-client-rest-bindings
I think we sometimes overcomplicate things for people when we try to
precisely describe everything rather than taking a stand. #toomanyphds
@Hadrian- I had no intention to close the VOTE; I was simply
redirecting discussion off the VOTE thread. +1 to reaching consensus in
which case I think the process should be Robert replying to the VOTE
thread indicating so.
Best
Alex
On 26/11/2015 16:53, Robert Moss wrote:
> My original vote (+1 separate repo named brooklyn-cli) still stands. I was
> raising the question since an amendment to the name was raised, whether we
> should take into account that other clients exist i.e the the Java rest
> client, and consider the possibility of reflecting this with e.g
> brooklyn-go-client and brooklyn-java-client repos, and any other language
> bindings in future following the same pattern. It just so happens that the
> brooklyn-go-client would have a CLI inside it.
>
> On 26 November 2015 at 16:36, Hadrian Zbarcea <hz...@gmail.com> wrote:
>
>> Alex moved this to a discuss, which I think is a bit confusing. I would
>> prefer to keep the vote open even if it takes longer.
>>
>> Robert, since you are the one objecting, do you disagree with:
>> a. The fact that we need a separate repo for the go client
>> b. Don't like the name
>>
>> What we put it in the repo is up to us, we can discuss at length later.
>> Infra won't create the repo with the given name unless we ask for it. If
>> you object to a), I will cancel the thread, if you object to b) hopefully
>> we can reach a quick agreement and keep the vote on track. If it's
>> something else, it should not be discussed during the [vote].
>>
>> My $0.02,
>> Hadrian
>>
>>
>> On 11/26/2015 06:09 AM, Robert Moss wrote:
>>
>>> It was, in fact, language bindings I was talking about. The go client has
>>> both language bindings and a CLI in one project. The Java client I was
>>> referring to was the rest client not the server CLI, which is just
>>> bindings. What I was alluding to was that it might be good to have
>>> several
>>> language bindings in separate repos and a distinction made between client
>>> and CLI.
>>>
>>> On 26 November 2015 at 10:51, Alex Heneveld <
>>> alex.heneveld@cloudsoftcorp.com
>>>
>>>> wrote:
>>>>
>>>
>>>> // moving from VOTE to DISCUSS thread
>>>>
>>>> *Re what will happen to the existing java client:*
>>>>
>>>> The Java CLI is for running the *server*. It will live in server
>>>>
>>>>
>>>> *Re 'brooklyn-client' or 'brooklyn-client-cli' (or
>>>> ***'brooklyn-go-client'
>>>> or 'brooklyn-cli' which I don't like):**
>>>>
>>>> The important thing to differentiate in the repo name (ie the top level I
>>>> think) is whether something is for the server, for the CLI client, for
>>>> the
>>>> UI, etc. Language isn't important so I don't like `go-client` --
>>>> although
>>>> it's nice that the top-level usage/role/repo distinctions do align with
>>>> language distinctions!
>>>>
>>>> Where the language *is* relevant in the name if we're making language
>>>> bindings e.g. to facility client code using the REST API. We have this
>>>> currently for Java and only in the "rest-client" project. This could be
>>>> renamed "rest-client-java-bindings". (On a side note it is proposed that
>>>> this go into brooklyn-server for now; semantically this is wrong as it
>>>> isn't server code ... but to do otherwise would result in a lot of
>>>> cross-project PR's. I don't think it's worth tidying this now; maybe if
>>>> we
>>>> have lots of language bindings then maybe it would be -- e.g. a
>>>> `brooklyn-client-rest-bindings` top-level repo.)
>>>>
>>>> It would be more descriptive for the CLI repo to have
>>>> `brooklyn-client-cli` and I'm not opposed to that but it seems
>>>> long-winded
>>>> for a project name. When I hear "client" as a devops context my default
>>>> is
>>>> a client command-line tool; if it's any other type of client -- eg a UI
>>>> or
>>>> language binding -- it would typically be named differently. As in
>>>> `brooklyn-ui` and `brooklyn-client-rest-bindings`.
>>>>
>>>>
>>>> *Code-gen:*
>>>>
>>>> I really like Swagger codegen for creating language bindings / client
>>>> stub
>>>> libraries. With the recent Swagger upgrade I think we do now generate
>>>> compliant JSON, exposed through the REST API, and so I think it would be
>>>> a
>>>> simple matter to auto-generate binding stubs for most languages. I've
>>>> not
>>>> tried this with Brooklyn but if someone does, and wants to add a page to
>>>> the docs that would be fantastic. (And maybe in future we auto-gen
>>>> `brooklyn-rest-client-bindings` for many languages; but not a high
>>>> priority.)
>>>>
>>>> Best
>>>> Alex
>>>>
>>>>
>>>> On 26/11/2015 10:05, Andrea Turli wrote:
>>>>
>>>> I agree with Robert, that's why I still `+1` `brooklyn-cli` over
>>>>> `brooklyn-client`
>>>>>
>>>>> I'm tempted to suggest `brooklyn-go-client`. What happens to the
>>>>> existing
>>>>>
>>>>> Java client, which is not a CLI? Does it deserve its own repo too?
>>>>>> What
>>>>>> about future language clients?
>>>>>>
>>>>>> If the brooklyn rest API will be fully Swagger compliant I think a good
>>>>>>
>>>>> documentation on how how to generate clients in different languages
>>>>> starting from the same YAML spec using swagger-codegen will be enough, I
>>>>> think. This will offer a good integration with other ecosystems and it
>>>>> will
>>>>> not require brooklyn community to support all the languages available
>>>>> out
>>>>> there.
>>>>>
>>>>> Cheers,
>>>>> Andrea
>>>>>
>>>>>
>>>>>
Re: [DISCUSS] Create repo for new deliverable: CLI <- client project
name and language binding discussion
Posted by Hadrian Zbarcea <hz...@gmail.com>.
That's perfectly fine. So where do you stand on the amended proposal,
keeping in mind that we could create new repos or add content to the
repo at will in the future.
For clarity:
[+1] brooklyn-cli (create repo with this name: a heneveld proposal)
[+1] brooklyn-commons-cli (use this name: mzaccardo proposal)
[+1] brooklyn-client (use this name: aheneveld proposal)
[-1] we do not need a separate repo
The way I plan to close this vote is:
* at least 1 negative (-1) vote cancels the proposal
* simple majority on the name wins (only last vote is counted for those
who voted multiple times, e.g. aheneveld's name change proposal.
(and I just realized I don't know what to do with non PMC votes, I need
to think about this one).
The vote is extended until Sun, 11/29/15, 4pm GMT. Plenty of time to
think and decide.
Hadrian
On 11/26/2015 11:53 AM, Robert Moss wrote:
> My original vote (+1 separate repo named brooklyn-cli) still stands. I was
> raising the question since an amendment to the name was raised, whether we
> should take into account that other clients exist i.e the the Java rest
> client, and consider the possibility of reflecting this with e.g
> brooklyn-go-client and brooklyn-java-client repos, and any other language
> bindings in future following the same pattern. It just so happens that the
> brooklyn-go-client would have a CLI inside it.
>
> On 26 November 2015 at 16:36, Hadrian Zbarcea <hz...@gmail.com> wrote:
>
>> Alex moved this to a discuss, which I think is a bit confusing. I would
>> prefer to keep the vote open even if it takes longer.
>>
>> Robert, since you are the one objecting, do you disagree with:
>> a. The fact that we need a separate repo for the go client
>> b. Don't like the name
>>
>> What we put it in the repo is up to us, we can discuss at length later.
>> Infra won't create the repo with the given name unless we ask for it. If
>> you object to a), I will cancel the thread, if you object to b) hopefully
>> we can reach a quick agreement and keep the vote on track. If it's
>> something else, it should not be discussed during the [vote].
>>
>> My $0.02,
>> Hadrian
>>
>>
>> On 11/26/2015 06:09 AM, Robert Moss wrote:
>>
>>> It was, in fact, language bindings I was talking about. The go client has
>>> both language bindings and a CLI in one project. The Java client I was
>>> referring to was the rest client not the server CLI, which is just
>>> bindings. What I was alluding to was that it might be good to have
>>> several
>>> language bindings in separate repos and a distinction made between client
>>> and CLI.
>>>
>>> On 26 November 2015 at 10:51, Alex Heneveld <
>>> alex.heneveld@cloudsoftcorp.com
>>>
>>>> wrote:
>>>>
>>>
>>>
>>>> // moving from VOTE to DISCUSS thread
>>>>
>>>> *Re what will happen to the existing java client:*
>>>>
>>>> The Java CLI is for running the *server*. It will live in server
>>>>
>>>>
>>>> *Re 'brooklyn-client' or 'brooklyn-client-cli' (or
>>>> ***'brooklyn-go-client'
>>>> or 'brooklyn-cli' which I don't like):**
>>>>
>>>> The important thing to differentiate in the repo name (ie the top level I
>>>> think) is whether something is for the server, for the CLI client, for
>>>> the
>>>> UI, etc. Language isn't important so I don't like `go-client` --
>>>> although
>>>> it's nice that the top-level usage/role/repo distinctions do align with
>>>> language distinctions!
>>>>
>>>> Where the language *is* relevant in the name if we're making language
>>>> bindings e.g. to facility client code using the REST API. We have this
>>>> currently for Java and only in the "rest-client" project. This could be
>>>> renamed "rest-client-java-bindings". (On a side note it is proposed that
>>>> this go into brooklyn-server for now; semantically this is wrong as it
>>>> isn't server code ... but to do otherwise would result in a lot of
>>>> cross-project PR's. I don't think it's worth tidying this now; maybe if
>>>> we
>>>> have lots of language bindings then maybe it would be -- e.g. a
>>>> `brooklyn-client-rest-bindings` top-level repo.)
>>>>
>>>> It would be more descriptive for the CLI repo to have
>>>> `brooklyn-client-cli` and I'm not opposed to that but it seems
>>>> long-winded
>>>> for a project name. When I hear "client" as a devops context my default
>>>> is
>>>> a client command-line tool; if it's any other type of client -- eg a UI
>>>> or
>>>> language binding -- it would typically be named differently. As in
>>>> `brooklyn-ui` and `brooklyn-client-rest-bindings`.
>>>>
>>>>
>>>> *Code-gen:*
>>>>
>>>> I really like Swagger codegen for creating language bindings / client
>>>> stub
>>>> libraries. With the recent Swagger upgrade I think we do now generate
>>>> compliant JSON, exposed through the REST API, and so I think it would be
>>>> a
>>>> simple matter to auto-generate binding stubs for most languages. I've
>>>> not
>>>> tried this with Brooklyn but if someone does, and wants to add a page to
>>>> the docs that would be fantastic. (And maybe in future we auto-gen
>>>> `brooklyn-rest-client-bindings` for many languages; but not a high
>>>> priority.)
>>>>
>>>> Best
>>>> Alex
>>>>
>>>>
>>>> On 26/11/2015 10:05, Andrea Turli wrote:
>>>>
>>>> I agree with Robert, that's why I still `+1` `brooklyn-cli` over
>>>>> `brooklyn-client`
>>>>>
>>>>> I'm tempted to suggest `brooklyn-go-client`. What happens to the
>>>>> existing
>>>>>
>>>>> Java client, which is not a CLI? Does it deserve its own repo too?
>>>>>> What
>>>>>> about future language clients?
>>>>>>
>>>>>> If the brooklyn rest API will be fully Swagger compliant I think a good
>>>>>>
>>>>> documentation on how how to generate clients in different languages
>>>>> starting from the same YAML spec using swagger-codegen will be enough, I
>>>>> think. This will offer a good integration with other ecosystems and it
>>>>> will
>>>>> not require brooklyn community to support all the languages available
>>>>> out
>>>>> there.
>>>>>
>>>>> Cheers,
>>>>> Andrea
>>>>>
>>>>>
>>>>>
>>>>
>>>
>
Re: [DISCUSS] Create repo for new deliverable: CLI <- client project
name and language binding discussion
Posted by Robert Moss <ro...@cloudsoftcorp.com>.
My original vote (+1 separate repo named brooklyn-cli) still stands. I was
raising the question since an amendment to the name was raised, whether we
should take into account that other clients exist i.e the the Java rest
client, and consider the possibility of reflecting this with e.g
brooklyn-go-client and brooklyn-java-client repos, and any other language
bindings in future following the same pattern. It just so happens that the
brooklyn-go-client would have a CLI inside it.
On 26 November 2015 at 16:36, Hadrian Zbarcea <hz...@gmail.com> wrote:
> Alex moved this to a discuss, which I think is a bit confusing. I would
> prefer to keep the vote open even if it takes longer.
>
> Robert, since you are the one objecting, do you disagree with:
> a. The fact that we need a separate repo for the go client
> b. Don't like the name
>
> What we put it in the repo is up to us, we can discuss at length later.
> Infra won't create the repo with the given name unless we ask for it. If
> you object to a), I will cancel the thread, if you object to b) hopefully
> we can reach a quick agreement and keep the vote on track. If it's
> something else, it should not be discussed during the [vote].
>
> My $0.02,
> Hadrian
>
>
> On 11/26/2015 06:09 AM, Robert Moss wrote:
>
>> It was, in fact, language bindings I was talking about. The go client has
>> both language bindings and a CLI in one project. The Java client I was
>> referring to was the rest client not the server CLI, which is just
>> bindings. What I was alluding to was that it might be good to have
>> several
>> language bindings in separate repos and a distinction made between client
>> and CLI.
>>
>> On 26 November 2015 at 10:51, Alex Heneveld <
>> alex.heneveld@cloudsoftcorp.com
>>
>>> wrote:
>>>
>>
>>
>>> // moving from VOTE to DISCUSS thread
>>>
>>> *Re what will happen to the existing java client:*
>>>
>>> The Java CLI is for running the *server*. It will live in server
>>>
>>>
>>> *Re 'brooklyn-client' or 'brooklyn-client-cli' (or
>>> ***'brooklyn-go-client'
>>> or 'brooklyn-cli' which I don't like):**
>>>
>>> The important thing to differentiate in the repo name (ie the top level I
>>> think) is whether something is for the server, for the CLI client, for
>>> the
>>> UI, etc. Language isn't important so I don't like `go-client` --
>>> although
>>> it's nice that the top-level usage/role/repo distinctions do align with
>>> language distinctions!
>>>
>>> Where the language *is* relevant in the name if we're making language
>>> bindings e.g. to facility client code using the REST API. We have this
>>> currently for Java and only in the "rest-client" project. This could be
>>> renamed "rest-client-java-bindings". (On a side note it is proposed that
>>> this go into brooklyn-server for now; semantically this is wrong as it
>>> isn't server code ... but to do otherwise would result in a lot of
>>> cross-project PR's. I don't think it's worth tidying this now; maybe if
>>> we
>>> have lots of language bindings then maybe it would be -- e.g. a
>>> `brooklyn-client-rest-bindings` top-level repo.)
>>>
>>> It would be more descriptive for the CLI repo to have
>>> `brooklyn-client-cli` and I'm not opposed to that but it seems
>>> long-winded
>>> for a project name. When I hear "client" as a devops context my default
>>> is
>>> a client command-line tool; if it's any other type of client -- eg a UI
>>> or
>>> language binding -- it would typically be named differently. As in
>>> `brooklyn-ui` and `brooklyn-client-rest-bindings`.
>>>
>>>
>>> *Code-gen:*
>>>
>>> I really like Swagger codegen for creating language bindings / client
>>> stub
>>> libraries. With the recent Swagger upgrade I think we do now generate
>>> compliant JSON, exposed through the REST API, and so I think it would be
>>> a
>>> simple matter to auto-generate binding stubs for most languages. I've
>>> not
>>> tried this with Brooklyn but if someone does, and wants to add a page to
>>> the docs that would be fantastic. (And maybe in future we auto-gen
>>> `brooklyn-rest-client-bindings` for many languages; but not a high
>>> priority.)
>>>
>>> Best
>>> Alex
>>>
>>>
>>> On 26/11/2015 10:05, Andrea Turli wrote:
>>>
>>> I agree with Robert, that's why I still `+1` `brooklyn-cli` over
>>>> `brooklyn-client`
>>>>
>>>> I'm tempted to suggest `brooklyn-go-client`. What happens to the
>>>> existing
>>>>
>>>> Java client, which is not a CLI? Does it deserve its own repo too?
>>>>> What
>>>>> about future language clients?
>>>>>
>>>>> If the brooklyn rest API will be fully Swagger compliant I think a good
>>>>>
>>>> documentation on how how to generate clients in different languages
>>>> starting from the same YAML spec using swagger-codegen will be enough, I
>>>> think. This will offer a good integration with other ecosystems and it
>>>> will
>>>> not require brooklyn community to support all the languages available
>>>> out
>>>> there.
>>>>
>>>> Cheers,
>>>> Andrea
>>>>
>>>>
>>>>
>>>
>>
Re: [DISCUSS] Create repo for new deliverable: CLI <- client project
name and language binding discussion
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Alex moved this to a discuss, which I think is a bit confusing. I would
prefer to keep the vote open even if it takes longer.
Robert, since you are the one objecting, do you disagree with:
a. The fact that we need a separate repo for the go client
b. Don't like the name
What we put it in the repo is up to us, we can discuss at length later.
Infra won't create the repo with the given name unless we ask for it. If
you object to a), I will cancel the thread, if you object to b)
hopefully we can reach a quick agreement and keep the vote on track. If
it's something else, it should not be discussed during the [vote].
My $0.02,
Hadrian
On 11/26/2015 06:09 AM, Robert Moss wrote:
> It was, in fact, language bindings I was talking about. The go client has
> both language bindings and a CLI in one project. The Java client I was
> referring to was the rest client not the server CLI, which is just
> bindings. What I was alluding to was that it might be good to have several
> language bindings in separate repos and a distinction made between client
> and CLI.
>
> On 26 November 2015 at 10:51, Alex Heneveld <alex.heneveld@cloudsoftcorp.com
>> wrote:
>
>>
>> // moving from VOTE to DISCUSS thread
>>
>> *Re what will happen to the existing java client:*
>>
>> The Java CLI is for running the *server*. It will live in server
>>
>>
>> *Re 'brooklyn-client' or 'brooklyn-client-cli' (or ***'brooklyn-go-client'
>> or 'brooklyn-cli' which I don't like):**
>>
>> The important thing to differentiate in the repo name (ie the top level I
>> think) is whether something is for the server, for the CLI client, for the
>> UI, etc. Language isn't important so I don't like `go-client` -- although
>> it's nice that the top-level usage/role/repo distinctions do align with
>> language distinctions!
>>
>> Where the language *is* relevant in the name if we're making language
>> bindings e.g. to facility client code using the REST API. We have this
>> currently for Java and only in the "rest-client" project. This could be
>> renamed "rest-client-java-bindings". (On a side note it is proposed that
>> this go into brooklyn-server for now; semantically this is wrong as it
>> isn't server code ... but to do otherwise would result in a lot of
>> cross-project PR's. I don't think it's worth tidying this now; maybe if we
>> have lots of language bindings then maybe it would be -- e.g. a
>> `brooklyn-client-rest-bindings` top-level repo.)
>>
>> It would be more descriptive for the CLI repo to have
>> `brooklyn-client-cli` and I'm not opposed to that but it seems long-winded
>> for a project name. When I hear "client" as a devops context my default is
>> a client command-line tool; if it's any other type of client -- eg a UI or
>> language binding -- it would typically be named differently. As in
>> `brooklyn-ui` and `brooklyn-client-rest-bindings`.
>>
>>
>> *Code-gen:*
>>
>> I really like Swagger codegen for creating language bindings / client stub
>> libraries. With the recent Swagger upgrade I think we do now generate
>> compliant JSON, exposed through the REST API, and so I think it would be a
>> simple matter to auto-generate binding stubs for most languages. I've not
>> tried this with Brooklyn but if someone does, and wants to add a page to
>> the docs that would be fantastic. (And maybe in future we auto-gen
>> `brooklyn-rest-client-bindings` for many languages; but not a high
>> priority.)
>>
>> Best
>> Alex
>>
>>
>> On 26/11/2015 10:05, Andrea Turli wrote:
>>
>>> I agree with Robert, that's why I still `+1` `brooklyn-cli` over
>>> `brooklyn-client`
>>>
>>> I'm tempted to suggest `brooklyn-go-client`. What happens to the existing
>>>
>>>> Java client, which is not a CLI? Does it deserve its own repo too? What
>>>> about future language clients?
>>>>
>>>> If the brooklyn rest API will be fully Swagger compliant I think a good
>>> documentation on how how to generate clients in different languages
>>> starting from the same YAML spec using swagger-codegen will be enough, I
>>> think. This will offer a good integration with other ecosystems and it
>>> will
>>> not require brooklyn community to support all the languages available out
>>> there.
>>>
>>> Cheers,
>>> Andrea
>>>
>>>
>>
>
Re: [DISCUSS] Create repo for new deliverable: CLI <- client project
name and language binding discussion
Posted by Robert Moss <ro...@cloudsoftcorp.com>.
It was, in fact, language bindings I was talking about. The go client has
both language bindings and a CLI in one project. The Java client I was
referring to was the rest client not the server CLI, which is just
bindings. What I was alluding to was that it might be good to have several
language bindings in separate repos and a distinction made between client
and CLI.
On 26 November 2015 at 10:51, Alex Heneveld <alex.heneveld@cloudsoftcorp.com
> wrote:
>
> // moving from VOTE to DISCUSS thread
>
> *Re what will happen to the existing java client:*
>
> The Java CLI is for running the *server*. It will live in server
>
>
> *Re 'brooklyn-client' or 'brooklyn-client-cli' (or ***'brooklyn-go-client'
> or 'brooklyn-cli' which I don't like):**
>
> The important thing to differentiate in the repo name (ie the top level I
> think) is whether something is for the server, for the CLI client, for the
> UI, etc. Language isn't important so I don't like `go-client` -- although
> it's nice that the top-level usage/role/repo distinctions do align with
> language distinctions!
>
> Where the language *is* relevant in the name if we're making language
> bindings e.g. to facility client code using the REST API. We have this
> currently for Java and only in the "rest-client" project. This could be
> renamed "rest-client-java-bindings". (On a side note it is proposed that
> this go into brooklyn-server for now; semantically this is wrong as it
> isn't server code ... but to do otherwise would result in a lot of
> cross-project PR's. I don't think it's worth tidying this now; maybe if we
> have lots of language bindings then maybe it would be -- e.g. a
> `brooklyn-client-rest-bindings` top-level repo.)
>
> It would be more descriptive for the CLI repo to have
> `brooklyn-client-cli` and I'm not opposed to that but it seems long-winded
> for a project name. When I hear "client" as a devops context my default is
> a client command-line tool; if it's any other type of client -- eg a UI or
> language binding -- it would typically be named differently. As in
> `brooklyn-ui` and `brooklyn-client-rest-bindings`.
>
>
> *Code-gen:*
>
> I really like Swagger codegen for creating language bindings / client stub
> libraries. With the recent Swagger upgrade I think we do now generate
> compliant JSON, exposed through the REST API, and so I think it would be a
> simple matter to auto-generate binding stubs for most languages. I've not
> tried this with Brooklyn but if someone does, and wants to add a page to
> the docs that would be fantastic. (And maybe in future we auto-gen
> `brooklyn-rest-client-bindings` for many languages; but not a high
> priority.)
>
> Best
> Alex
>
>
> On 26/11/2015 10:05, Andrea Turli wrote:
>
>> I agree with Robert, that's why I still `+1` `brooklyn-cli` over
>> `brooklyn-client`
>>
>> I'm tempted to suggest `brooklyn-go-client`. What happens to the existing
>>
>>> Java client, which is not a CLI? Does it deserve its own repo too? What
>>> about future language clients?
>>>
>>> If the brooklyn rest API will be fully Swagger compliant I think a good
>> documentation on how how to generate clients in different languages
>> starting from the same YAML spec using swagger-codegen will be enough, I
>> think. This will offer a good integration with other ecosystems and it
>> will
>> not require brooklyn community to support all the languages available out
>> there.
>>
>> Cheers,
>> Andrea
>>
>>
>
[DISCUSS] Create repo for new deliverable: CLI <- client project name
and language binding discussion
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
// moving from VOTE to DISCUSS thread
*Re what will happen to the existing java client:*
The Java CLI is for running the *server*. It will live in server
*Re 'brooklyn-client' or 'brooklyn-client-cli' (or
***'brooklyn-go-client' or 'brooklyn-cli' which I don't like):**
The important thing to differentiate in the repo name (ie the top level
I think) is whether something is for the server, for the CLI client, for
the UI, etc. Language isn't important so I don't like `go-client` --
although it's nice that the top-level usage/role/repo distinctions do
align with language distinctions!
Where the language *is* relevant in the name if we're making language
bindings e.g. to facility client code using the REST API. We have this
currently for Java and only in the "rest-client" project. This could be
renamed "rest-client-java-bindings". (On a side note it is proposed
that this go into brooklyn-server for now; semantically this is wrong as
it isn't server code ... but to do otherwise would result in a lot of
cross-project PR's. I don't think it's worth tidying this now; maybe if
we have lots of language bindings then maybe it would be -- e.g. a
`brooklyn-client-rest-bindings` top-level repo.)
It would be more descriptive for the CLI repo to have
`brooklyn-client-cli` and I'm not opposed to that but it seems
long-winded for a project name. When I hear "client" as a devops
context my default is a client command-line tool; if it's any other type
of client -- eg a UI or language binding -- it would typically be named
differently. As in `brooklyn-ui` and `brooklyn-client-rest-bindings`.
*Code-gen:*
I really like Swagger codegen for creating language bindings / client
stub libraries. With the recent Swagger upgrade I think we do now
generate compliant JSON, exposed through the REST API, and so I think it
would be a simple matter to auto-generate binding stubs for most
languages. I've not tried this with Brooklyn but if someone does, and
wants to add a page to the docs that would be fantastic. (And maybe in
future we auto-gen `brooklyn-rest-client-bindings` for many languages;
but not a high priority.)
Best
Alex
On 26/11/2015 10:05, Andrea Turli wrote:
> I agree with Robert, that's why I still `+1` `brooklyn-cli` over
> `brooklyn-client`
>
> I'm tempted to suggest `brooklyn-go-client`. What happens to the existing
>> Java client, which is not a CLI? Does it deserve its own repo too? What
>> about future language clients?
>>
> If the brooklyn rest API will be fully Swagger compliant I think a good
> documentation on how how to generate clients in different languages
> starting from the same YAML spec using swagger-codegen will be enough, I
> think. This will offer a good integration with other ecosystems and it will
> not require brooklyn community to support all the languages available out
> there.
>
> Cheers,
> Andrea
>
Re: [VOTE] Create repo for new deliverable: CLI
Posted by Andrea Turli <an...@cloudsoftcorp.com>.
I agree with Robert, that's why I still `+1` `brooklyn-cli` over
`brooklyn-client`
I'm tempted to suggest `brooklyn-go-client`. What happens to the existing
> Java client, which is not a CLI? Does it deserve its own repo too? What
> about future language clients?
>
If the brooklyn rest API will be fully Swagger compliant I think a good
documentation on how how to generate clients in different languages
starting from the same YAML spec using swagger-codegen will be enough, I
think. This will offer a good integration with other ecosystems and it will
not require brooklyn community to support all the languages available out
there.
Cheers,
Andrea
Re: [VOTE] Create repo for new deliverable: CLI
Posted by Robert Moss <ro...@cloudsoftcorp.com>.
I'm tempted to suggest `brooklyn-go-client`. What happens to the existing
Java client, which is not a CLI? Does it deserve its own repo too? What
about future language clients?
On 26 November 2015 at 09:31, Aled Sage <al...@gmail.com> wrote:
> +1
>
>
>
> On 25/11/2015 17:55, Hadrian Zbarcea 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 <al...@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>*
>>>>>>
>>>>>>
>>>
>
Re: [VOTE] Create repo for new deliverable: CLI
Posted by Aled Sage <al...@gmail.com>.
+1
On 25/11/2015 17:55, Hadrian Zbarcea 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
>>> <da...@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 <al...@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>*
>>>>>
>>
Re: [VOTE] Create repo for new deliverable: CLI
Posted by Hadrian Zbarcea <hz...@gmail.com>.
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 <da...@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 <al...@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>*
>>>>
>
Re: [VOTE] Create repo for new deliverable: CLI
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
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 <da...@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 <al...@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>*
>>>
Re: [VOTE] Create repo for new deliverable: CLI
Posted by Andrea Turli <an...@cloudsoftcorp.com>.
+1 brooklyn-cli
On Tue, 24 Nov 2015 at 15:59 David Lloyd <da...@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 <al...@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>*
> >
>
Re: [VOTE] Create repo for new deliverable: CLI
Posted by David Lloyd <da...@cloudsoftcorp.com>.
+1 brooklyn-cli
On 24 November 2015 at 14:05, Mark McKenna <ma...@cloudsoftcorp.com>
wrote:
> +1: brooklyn-cli
>
> On Tue, 24 Nov 2015 at 14:04 Aled Sage <al...@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>*
>
Re: [VOTE] Create repo for new deliverable: CLI
Posted by Mark McKenna <ma...@cloudsoftcorp.com>.
+1: brooklyn-cli
On Tue, 24 Nov 2015 at 14:04 Aled Sage <al...@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>*
Re: [VOTE] Create repo for new deliverable: CLI
Posted by Aled Sage <al...@gmail.com>.
+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
[RESULT][VOTE] Create repo for new deliverable: CLI
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Vote passes with the following result:
[3] +1 brooklyn-cli (rmoss, mmkenna, aturli)
[0] +1 brooklyn-commons-cli ()
[7] +1 brooklyn-client (aheneveld, asage, hadrian, dlloyd, gmacartney,
mzaccardo, cipi)
[0] -1 we do not need a separate repo
In fairness, I counted contributors votes as well, not just PMC, but any
way you count, the result is the same.
I will open an issue with infra@ requesting a separate 'brookly-client'
repo.
Thanks to all who expressed their thoughts and voted.
Hadrian
On 11/24/2015 08:59 AM, 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
Re: [VOTE] Create repo for new deliverable: CLI
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
+1 brooklyn-cli
--a
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
Re: [VOTE] Create repo for new deliverable: CLI
Posted by Robert Moss <ro...@cloudsoftcorp.com>.
+1 brooklyn-cli
On 24 November 2015 at 14:01, Geoff Macartney <
geoff.macartney@cloudsoftcorp.com> wrote:
> +1 brooklyn-cli
>
>
> ————————————————————
> Gnu PGP key - http://is.gd/TTTTuI
>
>
> > On 24 Nov 2015, at 13:59, Hadrian Zbarcea <hz...@gmail.com> 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
>
>
Re: [VOTE] Create repo for new deliverable: CLI
Posted by Geoff Macartney <ge...@cloudsoftcorp.com>.
+1 brooklyn-cli
————————————————————
Gnu PGP key - http://is.gd/TTTTuI
> On 24 Nov 2015, at 13:59, Hadrian Zbarcea <hz...@gmail.com> 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