1. TSC@lists.opendaylight.org
  2. Messages
   Date   
Re: OpenDaylight TSC] project names

David Meyer <dmm@...>
 



In discussing this with Phil he pointed out that we need to bring the developer tools admins into this conversation before we make any decisions. Basically we need to know what is possible with our tool chains. In particular, changing existing names and/or creating a naming paradigm that requires changes when a project changes state (e.g.,  bootstrap2core) may cause issues across the various tool chains.

Phil, who are the right people?

--dmm


On Thu, May 2, 2013 at 1:02 PM, Thomas Nadeau <tnadeau@...> wrote:


From: David Meyer <dmm@...>
Date: Thursday, May 2, 2013 2:51 PM
To: "tsc@..." <tsc@...>
Subject: Re: [OpenDaylight TSC] OpenDaylight TSC] project names


Chris,

>> I've been meaning to bring this up for some time now...
>> 
>> I believe we should establish some guidelines on project names.
>> The current bootstrap projects have named themselves in ways
>> that are not appropriate and create confusion.

Thank you for raising this. I too have been thinking about this for some time now and came to similar conclusions.

>> The code under "controller" project is named "OpenDaylight Controller."
>> The code under "net-virt-platform" project is named "OpenDaylight SDN
>> Controller Platform."  While those projects may aspire towards those
>> names, they haven't, IMO, earned those names yet.
>> 
>> I suggest that names should be more like codenames (with appropriate
>> trademark vetting still done).
>> 
>> I suggest that the current names be changed to reflect the above
>> sentiment.
>> 
>> I suggest that the project lifecycle document be updated to take this
>> into account.  Perhaps as part of Graduation review, we'd allocate a
>> ODP-wide name that's no longer just the code name.
>> 
>> So, for example, we'd have proposal named HotSidewalk, which upon Graduation
>> (based on it's functionality) becomes OpenDaylight EggFryer.
>> 
>> Thoughts?

I agree. However,  this does suggest that we need a way to manage names, both initially and after Graduation. As you suggest this should likely be part of the lifecycle document. Others?

Agree. The names should perhaps indicate their status too (I.e.: bootstrap, etc…).  

We should also make sure that project names, and any internal object naming is stripped of any commercially named or licensed names to avoid the obvious issues. I think that is specified in the governing documents, but its ultimately up to the TSC to enforce this policy. 

--Tom

Re: OpenDaylight TSC] project names

Phil Robb
 

The lead administrator for the OpenDaylight tools is Andrew Grimberg (cc-ed).

In short, I would suggest making this a forward looking policy as opposed to an immediate implementation.

I.e. keep the existing names for the code that is already in the repo with a plan of giving the result of our combining/merging/picking a single core-controller code base a new and conforming name.  Andy can perform that name change as per his comments below.  For new code contribution proposals it would be best to pick a name that can persist through the project's life within OpenDaylight.  We should endeavor to make project names changes the exception as opposed to the rule.

Phil.

 --Andrew Grimberg wrote --
1:30 PM (24 minutes ago)


EEK!!! just saying.

I have an "easy" means of doing the name changes.

1) Project names (and descriptions!) are allocated by the TSC
2) Pending changes for projects are completed / merged and no new
commits are accepted for some amount of freeze time
3) I generate the new code repositories (and associated service silos
during the freeze)
4) The current repository is taken out of service (hard freeze, no more
merges allowed)
5) I take a full clone of repository and do a forced import of the
entire commit history into the new repository

This is going to completely kill Gerrit history though and the only
surviving history is the commits themselves in the the git repository.
There's also fallout to Bugzilla bugs as they are going to be referring
to things that may or not exist anymore ;)

This is a lot of work of course. The alternative is that I do some weird
git rename bingo and somehow (I don't know how) get all the internal
Gerrit information in sync too. I'm far less sure I can pull this off
than the above steps.

-Andy-


On Fri, May 3, 2013 at 1:16 PM, David Meyer <dmm@...> wrote:


In discussing this with Phil he pointed out that we need to bring the developer tools admins into this conversation before we make any decisions. Basically we need to know what is possible with our tool chains. In particular, changing existing names and/or creating a naming paradigm that requires changes when a project changes state (e.g.,  bootstrap2core) may cause issues across the various tool chains.

Phil, who are the right people?

--dmm


On Thu, May 2, 2013 at 1:02 PM, Thomas Nadeau <tnadeau@...> wrote:


From: David Meyer <dmm@...>
Date: Thursday, May 2, 2013 2:51 PM
To: "tsc@..." <tsc@...>
Subject: Re: [OpenDaylight TSC] OpenDaylight TSC] project names


Chris,

>> I've been meaning to bring this up for some time now...
>> 
>> I believe we should establish some guidelines on project names.
>> The current bootstrap projects have named themselves in ways
>> that are not appropriate and create confusion.

Thank you for raising this. I too have been thinking about this for some time now and came to similar conclusions.

>> The code under "controller" project is named "OpenDaylight Controller."
>> The code under "net-virt-platform" project is named "OpenDaylight SDN
>> Controller Platform."  While those projects may aspire towards those
>> names, they haven't, IMO, earned those names yet.
>> 
>> I suggest that names should be more like codenames (with appropriate
>> trademark vetting still done).
>> 
>> I suggest that the current names be changed to reflect the above
>> sentiment.
>> 
>> I suggest that the project lifecycle document be updated to take this
>> into account.  Perhaps as part of Graduation review, we'd allocate a
>> ODP-wide name that's no longer just the code name.
>> 
>> So, for example, we'd have proposal named HotSidewalk, which upon Graduation
>> (based on it's functionality) becomes OpenDaylight EggFryer.
>> 
>> Thoughts?

I agree. However,  this does suggest that we need a way to manage names, both initially and after Graduation. As you suggest this should likely be part of the lifecycle document. Others?

Agree. The names should perhaps indicate their status too (I.e.: bootstrap, etc…).  

We should also make sure that project names, and any internal object naming is stripped of any commercially named or licensed names to avoid the obvious issues. I think that is specified in the governing documents, but its ultimately up to the TSC to enforce this policy. 

--Tom


_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc




--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
Re: Question about Controller Project's Modules/Bundles and Interfaces Page

Chris Wright <chrisw@...>
 

* Aleksandar Miljusevic (miljusevic@...) wrote:
Is editing of the Controller Project's Modules/Bundles and Interfaces Page
going to be open to the public at some point?
It's editable now. You need to log in.
Perhaps you simply need an account?

thanks,
-chris

Re: Question about Controller Project's Modules/Bundles and Interfaces Page

Chris Wright <chrisw@...>
 

* Chris Wright (chrisw@...) wrote:
* Aleksandar Miljusevic (miljusevic@...) wrote:
Is editing of the Controller Project's Modules/Bundles and Interfaces Page
going to be open to the public at some point?
It's editable now. You need to log in.
Perhaps you simply need an account?
FYI, I updated the wiki landing page to include a pointer to the account
system. The direct link is here:

https://identity.opendaylight.org/

thanks,
-chris

P.S. thanks to Andrew for reminding me of the account system link ;)

Re: Question about Controller Project's Modules/Bundles and Interfaces Page

David Meyer <dmm@...>
 

Thanks Chris. --dmm


On Fri, May 3, 2013 at 1:40 PM, Chris Wright <chrisw@...> wrote:
* Chris Wright (chrisw@...) wrote:
> * Aleksandar Miljusevic (miljusevic@...) wrote:
> > Is editing of the Controller Project's Modules/Bundles and Interfaces Page
> > going to be open to the public at some point?
>
> It's editable now. You need to log in.
> Perhaps you simply need an account?

FYI, I updated the wiki landing page to include a pointer to the account
system.  The direct link is here:

https://identity.opendaylight.org/

thanks,
-chris

P.S. thanks to Andrew for reminding me of the account system link ;)
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
motions and proxy voting proposals

Thomas Nadeau <tnadeau@...>
 

I have tried to capture the details of our discussion last week. Please
comment on the proposal below so that we can amend the process as soon as
possible.

--Tom



Email-based or Proxy-based Voting

This proposal amends the existing TSC voting procedures that stipulate
that voting by TSC members must be done "in person" during scheduled
meetings.


Motions

Before being put to a vote, motions presented before the TSC must be
raised publicly on the development mailing-list for a minimum of 4
business days prior to a vote. This will give a chance to the wider
community to express their opinion as well as accommodate the
possibility
that members might not attend a meeting and vote in person. Motions
not posted to the list will not be considered official motions.

TSC members can vote via email positively, negatively, or abstain as is
the case
today, but must voice their votes in writing on the public mailing list.
This
will serve as the official written public record of their vote.
Members or their proxies and designates that do not vote or have their
votes received by the chair via the official mailing list will be counted
as no-vote.

Decisions need more positive votes than negative votes (ties mean the
motion is rejected), and a minimum of positive votes of at least one
third of the total number of TC members (rounded up: in a board with
8PTLs+5 that means a minimum of 5 approvers).


Proxy Delegates

Any Technical Steering Committee (TSC) member may designate a proxy to
attend a meeting in their place. This change must be sent to both the
TSC (private) list as well as the TSC chair in writing at least 1
hour prior to the expiration period of a motion for a vote. This person
may place votes on behalf of the TSC member both in person at a meeting,
or via email in case they cannot attend the meeting for the period
of 1 meeting unless otherwise stipulated.

Re: motions and proxy voting proposals

David Meyer <dmm@...>
 


Thanks Tom. A few questions/comments in line. --dmm


On Fri, May 3, 2013 at 2:25 PM, Thomas Nadeau <tnadeau@...> wrote:

        I have tried to capture the details of our discussion last week. Please
comment on the proposal below so that we can amend the process as soon as
possible.

        --Tom



Email-based or Proxy-based Voting

  This proposal amends the existing TSC voting procedures that stipulate
  that voting by TSC members must be done "in person" during scheduled
  meetings.


Motions

  Before being put to a vote, motions presented before the TSC must be
  raised publicly on the development mailing-list for a minimum of 4
  business days prior to a vote. This will give a chance to the wider
  community to express their opinion as well as accommodate the
possibility
  that members might not attend a meeting and vote in person. Motions
  not posted to the list will not be considered official motions.

  TSC members can vote via email positively, negatively, or abstain as is
the case
  today, but must voice their votes in writing on the public mailing list.

dmm> not sure but what would be (perhaps) useful would be to have a "secret" ballot mechanism such that all of the votes tallied and posted simultaneously with the outcome. This way no one has to have a deciding vote. Just a thought.
 
This
  will serve as the official written public record of their vote.
  Members or their proxies and designates that do not vote or have their
  votes received by the chair via the official mailing list will be counted
  as no-vote.

dmm> if we decide to allow "secret" balloting we'll have to have a look at the previous paragraph. 

  Decisions need more positive votes than negative votes (ties mean the
  motion is rejected), and a minimum of positive votes of at least one
  third of the total number of TC members (rounded up: in a board with
  8PTLs+5 that means a minimum of 5 approvers).

dmm> I didn't understand the parenthetical comment (and what does PTL stand for?)
 

Proxy Delegates

  Any Technical Steering Committee (TSC) member may designate a proxy to
  attend a meeting in their place. This change must be sent to both the
  TSC (private) list as well as the TSC chair in writing at least 1
  hour prior to the expiration period of a motion for a vote. This person
  may place votes on behalf of the TSC member both in person at a meeting,
  or via email in case they cannot attend the meeting for the period
  of 1 meeting unless otherwise stipulated.






_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
Re: motions and proxy voting proposals

Chris Wright <chrisw@...>
 

* David Meyer (dmm@...) wrote:
On Fri, May 3, 2013 at 2:25 PM, Thomas Nadeau <tnadeau@...> wrote:
Decisions need more positive votes than negative votes (ties mean the
motion is rejected), and a minimum of positive votes of at least one
third of the total number of TC members (rounded up: in a board with
8PTLs+5 that means a minimum of 5 approvers).
dmm> I didn't understand the parenthetical comment (and what does PTL
stand for?)
That's boilerplate from the original. OpenStack has a TC (Technical
Committee), which is built of PTLs (Project Technical Leads) and 5
community voted representatives (the +5).

thanks,
-chris

Re: motions and proxy voting proposals

Chris Wright <chrisw@...>
 

* Thomas Nadeau (tnadeau@...) wrote:
Motions

Before being put to a vote, motions presented before the TSC must be
raised publicly on the development mailing-list for a minimum of 4
Come to think of it, we don't actually have "the development" list.
We have "the discuss" list, or "the TSC" list. Capturing the spirit here,
it'd be discuss.

business days prior to a vote. This will give a chance to the wider
community to express their opinion
---
as well as accommodate the possibility that members might not attend
a meeting and vote in person.
---
Perhaps we could strike that bit, since we allow for proxy voting.

Motions
not posted to the list will not be considered official motions.
Probably redundant w/ "[motions] must be raised publically"

TSC members can vote via email positively, negatively, or abstain as is
the case
today, but must voice their votes in writing on the public mailing list.
Similarly here, another option is that we vote in the meeting and
require one of:

- member or proxy voting +1, -1, 0
- no show == no vote

The advantage is the simplicity of getting together and voting right
then and there.

This
will serve as the official written public record of their vote.
Members or their proxies and designates that do not vote or have their
votes received by the chair via the official mailing list will be counted
as no-vote.
Why would we count not voting as a "no" vote?

Decisions need more positive votes than negative votes (ties mean the
motion is rejected), and a minimum of positive votes of at least one
third of the total number of TC members (rounded up: in a board with
8PTLs+5 that means a minimum of 5 approvers).
Need to reflect OpenDaylight structure here (TC->TSC, PTL->Project Lead,
and, well, +5...bleh ditch it all and just say "in a board w/ 13member
that means a minimum of 5 approvers). And while I like the spirit,
I think we'll need to change the TSC charter which currently states:

- Simple majority voting should be used for decisions within the TSC,
unless otherwise specified in Development Process.

Proxy Delegates

Any Technical Steering Committee (TSC) member may designate a proxy to
attend a meeting in their place. This change must be sent to both the
TSC (private) list as well as the TSC chair in writing at least 1
hour prior to the expiration period of a motion for a vote. This person
may place votes on behalf of the TSC member both in person at a meeting,
or via email in case they cannot attend the meeting for the period
of 1 meeting unless otherwise stipulated.
I think a proxy designation should go to public list. And I'm leaning
towards voting in the meeting, which would suggest this gets rewritten to:

Any Technical Steering Committee (TSC) member may designate a proxy
to attend a meeting in their place. This change must be sent to both
the TSC mailing list as well as the TSC chair at least 1 hour prior to
meeting during which designate will act as a proxy. This proxy may
represent the opinion of and vote on behalf of the TSC member.

thanks,
-chris

Re: motions and proxy voting proposals

Thomas Nadeau <tnadeau@...>
 

First off, Dave, do you have the editing pen now for this?


* Thomas Nadeau (tnadeau@...) wrote:
Motions

Before being put to a vote, motions presented before the TSC must be
raised publicly on the development mailing-list for a minimum of 4
Come to think of it, we don't actually have "the development" list.
We have "the discuss" list, or "the TSC" list. Capturing the spirit here,
it'd be discuss.

business days prior to a vote. This will give a chance to the wider
community to express their opinion
---
as well as accommodate the possibility that members might not attend
a meeting and vote in person.
---
Perhaps we could strike that bit, since we allow for proxy voting.

Motions
not posted to the list will not be considered official motions.
Probably redundant w/ "[motions] must be raised publically"

TSC members can vote via email positively, negatively, or abstain as
is
the case
today, but must voice their votes in writing on the public mailing
list.
Similarly here, another option is that we vote in the meeting and
require one of:

- member or proxy voting +1, -1, 0
- no show == no vote

The advantage is the simplicity of getting together and voting right
then and there.
Right, no vote == abstain.

This
will serve as the official written public record of their vote.
Members or their proxies and designates that do not vote or have their
votes received by the chair via the official mailing list will be
counted
as no-vote.
Why would we count not voting as a "no" vote?
You need some default state. It seems the most obvious route is no vote
== abstain to me.


Decisions need more positive votes than negative votes (ties mean the
motion is rejected), and a minimum of positive votes of at least one
third of the total number of TC members (rounded up: in a board with
8PTLs+5 that means a minimum of 5 approvers).
Need to reflect OpenDaylight structure here (TC->TSC, PTL->Project Lead,
and, well, +5...bleh ditch it all and just say "in a board w/ 13member
that means a minimum of 5 approvers). And while I like the spirit,
I think we'll need to change the TSC charter which currently states:

- Simple majority voting should be used for decisions within the TSC,
unless otherwise specified in Development Process.

Proxy Delegates

Any Technical Steering Committee (TSC) member may designate a proxy to
attend a meeting in their place. This change must be sent to both the
TSC (private) list as well as the TSC chair in writing at least 1
hour prior to the expiration period of a motion for a vote. This
person
may place votes on behalf of the TSC member both in person at a
meeting,
or via email in case they cannot attend the meeting for the period
of 1 meeting unless otherwise stipulated.
I think a proxy designation should go to public list. And I'm leaning
towards voting in the meeting, which would suggest this gets rewritten to:

Any Technical Steering Committee (TSC) member may designate a proxy
to attend a meeting in their place. This change must be sent to both
the TSC mailing list as well as the TSC chair at least 1 hour prior to
meeting during which designate will act as a proxy. This proxy may
represent the opinion of and vote on behalf of the TSC member.
Cool.

--Tom




thanks,
-chris
Re: motions and proxy voting proposals

David Meyer <dmm@...>
 

On Mon, May 6, 2013 at 7:21 AM, Thomas Nadeau <tnadeau@...> wrote:

First off, Dave, do you have the editing pen now for this?
No, not unless you need me to take it. --dmm


* Thomas Nadeau (tnadeau@...) wrote:
Motions

Before being put to a vote, motions presented before the TSC must be
raised publicly on the development mailing-list for a minimum of 4
Come to think of it, we don't actually have "the development" list.
We have "the discuss" list, or "the TSC" list. Capturing the spirit here,
it'd be discuss.

business days prior to a vote. This will give a chance to the wider
community to express their opinion
---
as well as accommodate the possibility that members might not attend
a meeting and vote in person.
---
Perhaps we could strike that bit, since we allow for proxy voting.

Motions
not posted to the list will not be considered official motions.
Probably redundant w/ "[motions] must be raised publically"

TSC members can vote via email positively, negatively, or abstain as
is
the case
today, but must voice their votes in writing on the public mailing
list.
Similarly here, another option is that we vote in the meeting and
require one of:

- member or proxy voting +1, -1, 0
- no show == no vote

The advantage is the simplicity of getting together and voting right
then and there.
Right, no vote == abstain.

This
will serve as the official written public record of their vote.
Members or their proxies and designates that do not vote or have their
votes received by the chair via the official mailing list will be
counted
as no-vote.
Why would we count not voting as a "no" vote?
You need some default state. It seems the most obvious route is no vote
== abstain to me.


Decisions need more positive votes than negative votes (ties mean the
motion is rejected), and a minimum of positive votes of at least one
third of the total number of TC members (rounded up: in a board with
8PTLs+5 that means a minimum of 5 approvers).
Need to reflect OpenDaylight structure here (TC->TSC, PTL->Project Lead,
and, well, +5...bleh ditch it all and just say "in a board w/ 13member
that means a minimum of 5 approvers). And while I like the spirit,
I think we'll need to change the TSC charter which currently states:

- Simple majority voting should be used for decisions within the TSC,
unless otherwise specified in Development Process.

Proxy Delegates

Any Technical Steering Committee (TSC) member may designate a proxy to
attend a meeting in their place. This change must be sent to both the
TSC (private) list as well as the TSC chair in writing at least 1
hour prior to the expiration period of a motion for a vote. This
person
may place votes on behalf of the TSC member both in person at a
meeting,
or via email in case they cannot attend the meeting for the period
of 1 meeting unless otherwise stipulated.
I think a proxy designation should go to public list. And I'm leaning
towards voting in the meeting, which would suggest this gets rewritten to:

Any Technical Steering Committee (TSC) member may designate a proxy
to attend a meeting in their place. This change must be sent to both
the TSC mailing list as well as the TSC chair at least 1 hour prior to
meeting during which designate will act as a proxy. This proxy may
represent the opinion of and vote on behalf of the TSC member.
Cool.

--Tom




thanks,
-chris

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
TSC Members vote on meeting time

Phil Robb
 

Hello TSC Members:

Please indicate below what times work for you for an added weekly TSC meeting.  You can put an "X", a "Y", or "Yes".. whatever you prefer under *ALL* of the times that would work for you.

Tuesdays at 9:00am PDT / 12:00pm EDT


Tuesdays at 10:00am PDT / 1:00pm EDT


Tuesdays at 11:00am PDT / 2:00pm EDT


Tuesdays at 12:00pm PDT / 3:00pm EDT


Tuesdays at 2:00pm PDT/5:00pm EDT


Extend the Thursday meetings to 2 hours  (10:00am - 12:00pm PDT / 1:00pm - 3:00pm EDT)



So as not to spam the list too badly, please just send your responses to me and do not reply all.

Again, this email survey is to only be completed by the members of the OpenDaylight Technical Steering Committee.

Thanks,

Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
is there any progress that the "controller" and "net-virt-platform" folks have done around a resolution plan can be reported on?

David Meyer <dmm@...>
 

All,

Since I have asked the "controller" and "net-virt-platform" teams to
look at a resolution proposal, I'm looking for a progress report (if
any).

Thnx,

--dmm

Re: is there any progress that the "controller" and "net-virt-platform" folks have done around a resolution plan can be reported on?

Rob Sherwood
 

Colin and Dave are going to pitch their merged plan in about 40 minutes.  I'm still trying to understand the details but it seems to have some strong points.

- Rob
.


On Mon, May 6, 2013 at 11:58 AM, David Meyer <dmm@...> wrote:
All,

Since I have asked the "controller" and "net-virt-platform" teams to
look at a resolution proposal, I'm looking for a progress report (if
any).

Thnx,

--dmm
Re: is there any progress that the "controller" and "net-virt-platform" folks have done around a resolution plan can be reported on?

David Meyer <dmm@...>
 

On Mon, May 6, 2013 at 12:23 PM, Rob Sherwood
<rob.sherwood@...> wrote:
Colin and Dave are going to pitch their merged plan in about 40 minutes.
I'm still trying to understand the details but it seems to have some strong
points.
Understand that, was wondering if there were other proposals that were
equally details

--dmm


- Rob
.


On Mon, May 6, 2013 at 11:58 AM, David Meyer <dmm@...> wrote:

All,

Since I have asked the "controller" and "net-virt-platform" teams to
look at a resolution proposal, I'm looking for a progress report (if
any).

Thnx,

--dmm
Re: is there any progress that the "controller" and "net-virt-platform" folks have done around a resolution plan can be reported on?

Rob Sherwood
 

OK -- just so it's said, I consider Colin and Dave's proposal to be simply a more well thought out and detailed version of my proposal that I pitched on discuss.


- Rob
.


On Mon, May 6, 2013 at 12:39 PM, David Meyer <dmm@...> wrote:
On Mon, May 6, 2013 at 12:23 PM, Rob Sherwood
<rob.sherwood@...> wrote:
> Colin and Dave are going to pitch their merged plan in about 40 minutes.
> I'm still trying to understand the details but it seems to have some strong
> points.

Understand that, was wondering if there were other proposals that were
equally details

--dmm

>
> - Rob
> .
>
>
> On Mon, May 6, 2013 at 11:58 AM, David Meyer <dmm@...> wrote:
>>
>> All,
>>
>> Since I have asked the "controller" and "net-virt-platform" teams to
>> look at a resolution proposal, I'm looking for a progress report (if
>> any).
>>
>> Thnx,
>>
>> --dmm
>
>
Re: is there any progress that the "controller" and "net-virt-platform" folks have done around a resolution plan can be reported on?

David Meyer <dmm@...>
 

On Mon, May 6, 2013 at 12:44 PM, Rob Sherwood
<rob.sherwood@...> wrote:
OK -- just so it's said, I consider Colin and Dave's proposal to be simply a
more well thought out and detailed version of my proposal that I pitched on
discuss.

https://lists.opendaylight.org/pipermail/discuss/2013-April/000044.html
Actually both your proposal and whether or not what Colin/David are
suggesting is the same thing as you have proposed are items for
discussion.

--dmm


- Rob
.


On Mon, May 6, 2013 at 12:39 PM, David Meyer <dmm@...> wrote:

On Mon, May 6, 2013 at 12:23 PM, Rob Sherwood
<rob.sherwood@...> wrote:
Colin and Dave are going to pitch their merged plan in about 40 minutes.
I'm still trying to understand the details but it seems to have some
strong
points.
Understand that, was wondering if there were other proposals that were
equally details

--dmm


- Rob
.


On Mon, May 6, 2013 at 11:58 AM, David Meyer <dmm@...> wrote:

All,

Since I have asked the "controller" and "net-virt-platform" teams to
look at a resolution proposal, I'm looking for a progress report (if
any).

Thnx,

--dmm
Re: motions and proxy voting proposals

Chris Wright <chrisw@...>
 

* Thomas Nadeau (tnadeau@...) wrote:
* Thomas Nadeau (tnadeau@...) wrote:
Motions

Before being put to a vote, motions presented before the TSC must be
raised publicly on the development mailing-list for a minimum of 4
Come to think of it, we don't actually have "the development" list.
We have "the discuss" list, or "the TSC" list. Capturing the spirit here,
it'd be discuss.

business days prior to a vote. This will give a chance to the wider
community to express their opinion
---
as well as accommodate the possibility that members might not attend
a meeting and vote in person.
---
Perhaps we could strike that bit, since we allow for proxy voting.

Motions
not posted to the list will not be considered official motions.
Probably redundant w/ "[motions] must be raised publically"

TSC members can vote via email positively, negatively, or abstain as
is
the case
today, but must voice their votes in writing on the public mailing
list.
Similarly here, another option is that we vote in the meeting and
require one of:

- member or proxy voting +1, -1, 0
- no show == no vote

The advantage is the simplicity of getting together and voting right
then and there.
Right, no vote == abstain.

This
will serve as the official written public record of their vote.
Members or their proxies and designates that do not vote or have their
votes received by the chair via the official mailing list will be
counted
as no-vote.
Why would we count not voting as a "no" vote?
You need some default state. It seems the most obvious route is no vote
== abstain to me.
Sorry, that's just me not being able to read. I read "no-vote" as a vote
for "no" rather than not voting.

thanks,
-chris

Agenda for the 05/09 TSC meeting

David Meyer <dmm@...>
 

Rob, now that we've heard what Colin and David have come up with....

David Meyer <dmm@...>
 

Can you restate what your proposal is and how it fits into the
framework we just heard from Colin and David (if indeed it does)? IMO
this would be very helpful for the community and would help us gauge
where we are with the merge proposal(s).

Thanks,

--dmm

101 - 120 of 14384