Re: Veto! Veto?

2015-03-23 Thread Pierre Smits
When it comes to people, consensus (acceptance by unanimity) is the best
thing to have. But if the ASF has as its principle that no vetoes are
allowed, how can it be the remit of a project's PMC have it as its policy?

Best regards,


Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Sun, Mar 22, 2015 at 3:17 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Le 22/03/2015 14:42, jan i a écrit :
>
>> On 22 March 2015 at 14:35, Pierre Smits  wrote:
>>
>>  HI Bertrand,
>>>
>>> Thanks for the clarification regarding
>>> http://community.apache.org/newcommitter.html
>>>
>>> Shouldn't http://www.apache.org/foundation/voting.html then also
>>> explicitly
>>> reflect that vetoes aren't allowed when it comes to on- and ofboarding
>>> contributors as committer and PMC member? That would surely bring
>>> clarity.
>>>
>>>  I would be very unhappy with "aren´t allowed", that is something the
>> individual PMCs should decide !
>>
>
> Yes indeed that's PMCs 's remit; we just need to clarify the ASF default.
>
> Jacques
>
>
>
>> rgds
>> jan I.
>>
>>
>>  Best regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM *
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Sun, Mar 22, 2015 at 2:25 PM, Bertrand Delacretaz <
>>> bdelacre...@apache.org
>>>
 wrote:
 On Sun, Mar 22, 2015 at 2:17 PM, Jacques Le Roux
  wrote:

> ...Thanks for the clarification Bertrand, this was also unclear to me.
>
 Should

> we not amend the newcommitter page?..
>
 That would be great, I don't have time right now myself.
 -Bertrand




Re: Veto! Veto?

2015-03-23 Thread jan i
On 23 March 2015 at 09:02, Pierre Smits  wrote:

> When it comes to people, consensus (acceptance by unanimity) is the best
> thing to have. But if the ASF has as its principle that no vetoes are
> allowed, how can it be the remit of a project's PMC have it as its policy?
>

I think it is a matter of wording, I do not think it is a ASF Principle
(actually not sure how that relates to "policy") that veto is not allowed,
Consensus is the ASF Principle. We all want to avoid Vetos, for many good
reasons, but that it not the same as not being allowed.

As a Foundation we try to have very few rules and policies, and let the
communities handle how they want to do it, this here is surely
a case where we do not a foundation wide rule.

I would have no problem, if the wording on the page was something like "it
is recommended not to use Veto"

Pierre@ maybe just for my understanding, why would ASF be better, if we
make this rule foundation wide, instead of leaving it up to
the single community ?

rgds
jan I.


> Best regards,
>
>
> Pierre Smits
>
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Sun, Mar 22, 2015 at 3:17 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Le 22/03/2015 14:42, jan i a écrit :
> >
> >> On 22 March 2015 at 14:35, Pierre Smits  wrote:
> >>
> >>  HI Bertrand,
> >>>
> >>> Thanks for the clarification regarding
> >>> http://community.apache.org/newcommitter.html
> >>>
> >>> Shouldn't http://www.apache.org/foundation/voting.html then also
> >>> explicitly
> >>> reflect that vetoes aren't allowed when it comes to on- and ofboarding
> >>> contributors as committer and PMC member? That would surely bring
> >>> clarity.
> >>>
> >>>  I would be very unhappy with "aren´t allowed", that is something the
> >> individual PMCs should decide !
> >>
> >
> > Yes indeed that's PMCs 's remit; we just need to clarify the ASF default.
> >
> > Jacques
> >
> >
> >
> >> rgds
> >> jan I.
> >>
> >>
> >>  Best regards,
> >>>
> >>> Pierre Smits
> >>>
> >>> *ORRTIZ.COM *
> >>> Services & Solutions for Cloud-
> >>> Based Manufacturing, Professional
> >>> Services and Retail & Trade
> >>> http://www.orrtiz.com
> >>>
> >>> On Sun, Mar 22, 2015 at 2:25 PM, Bertrand Delacretaz <
> >>> bdelacre...@apache.org
> >>>
>  wrote:
>  On Sun, Mar 22, 2015 at 2:17 PM, Jacques Le Roux
>   wrote:
> 
> > ...Thanks for the clarification Bertrand, this was also unclear to
> me.
> >
>  Should
> 
> > we not amend the newcommitter page?..
> >
>  That would be great, I don't have time right now myself.
>  -Bertrand
> 
> 
>


Re: Veto! Veto?

2015-03-23 Thread Bertrand Delacretaz
On Mon, Mar 23, 2015 at 9:02 AM, Pierre Smits  wrote:
>  ...if the ASF has as its principle that no vetoes are
> allowed, how can it be the remit of a project's PMC have it as its policy?...

Our PMCs have a lot of leeway and the board doesn't micromanage them.

In our loosely-coupled communities vetoes can give too much power to
individuals, that's why https://www.apache.org/foundation/voting.html
is so restrictive about them.

I'd say broadly allowing vetoes works as long as people don't use
them, or just use them in a friendly and temporary way. But if people
are all friendly you don't really need rules anyway ;-)

-Bertrand


Re: Veto! Veto?

2015-03-23 Thread jan i
On 23 March 2015 at 09:20, Bertrand Delacretaz 
wrote:

> On Mon, Mar 23, 2015 at 9:02 AM, Pierre Smits 
> wrote:
> >  ...if the ASF has as its principle that no vetoes are
> > allowed, how can it be the remit of a project's PMC have it as its
> policy?...
>
> Our PMCs have a lot of leeway and the board doesn't micromanage them.
>
> In our loosely-coupled communities vetoes can give too much power to
> individuals, that's why https://www.apache.org/foundation/voting.html
> is so restrictive about them.
>
Sadly enough, for procedural votes, that page leaves everything open,
otherwise it is a good page.
"Procedural Votes or Opinion Polls

*TBS"*


Rgds
jan I.


> I'd say broadly allowing vetoes works as long as people don't use
> them, or just use them in a friendly and temporary way. But if people
> are all friendly you don't really need rules anyway ;-)
>
> -Bertrand
>


Re: Veto! Veto?

2015-03-23 Thread Pierre Smits
An opinion poll is not the same as voting on a procedural issue.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Mon, Mar 23, 2015 at 9:44 AM, Pierre Smits 
wrote:

> The principle/policy/rule of the ASF regarding code changes is very
> explicit, well documented and unambiguous. Can a project's PMC have another
> methodology in place while being part of the ASF? I guess not.
>
> Consensus with respect to on and off boarding of people is nice, as it
> expresses unanimity. And I, as I expect it to be for all, am all for it.
> But to have it as an requirement would be a show stopper.
>
> Would it be ok for the ASF if there were a project under its umbrella,
> that would say: that majority voting principle you for procedural issues is
> nice, but for us - when it comes to people - we veto
> promotors/speakers/book writers to participate in our project with
> privileges (commit right, PMC membership)? Or, that it vetoes people from
> France (this is example, I have nothing against people from France or even
> with the French nationality)?
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Mon, Mar 23, 2015 at 9:20 AM, jan i  wrote:
>
>> On 23 March 2015 at 09:02, Pierre Smits  wrote:
>>
>> > When it comes to people, consensus (acceptance by unanimity) is the best
>> > thing to have. But if the ASF has as its principle that no vetoes are
>> > allowed, how can it be the remit of a project's PMC have it as its
>> policy?
>> >
>>
>> I think it is a matter of wording, I do not think it is a ASF Principle
>> (actually not sure how that relates to "policy") that veto is not allowed,
>> Consensus is the ASF Principle. We all want to avoid Vetos, for many good
>> reasons, but that it not the same as not being allowed.
>>
>> As a Foundation we try to have very few rules and policies, and let the
>> communities handle how they want to do it, this here is surely
>> a case where we do not a foundation wide rule.
>>
>> I would have no problem, if the wording on the page was something like "it
>> is recommended not to use Veto"
>>
>> Pierre@ maybe just for my understanding, why would ASF be better, if we
>> make this rule foundation wide, instead of leaving it up to
>> the single community ?
>>
>> rgds
>> jan I.
>>
>>
>> > Best regards,
>> >
>> >
>> > Pierre Smits
>> >
>> > *ORRTIZ.COM *
>> > Services & Solutions for Cloud-
>> > Based Manufacturing, Professional
>> > Services and Retail & Trade
>> > http://www.orrtiz.com
>> >
>> > On Sun, Mar 22, 2015 at 3:17 PM, Jacques Le Roux <
>> > jacques.le.r...@les7arts.com> wrote:
>> >
>> > > Le 22/03/2015 14:42, jan i a écrit :
>> > >
>> > >> On 22 March 2015 at 14:35, Pierre Smits 
>> wrote:
>> > >>
>> > >>  HI Bertrand,
>> > >>>
>> > >>> Thanks for the clarification regarding
>> > >>> http://community.apache.org/newcommitter.html
>> > >>>
>> > >>> Shouldn't http://www.apache.org/foundation/voting.html then also
>> > >>> explicitly
>> > >>> reflect that vetoes aren't allowed when it comes to on- and
>> ofboarding
>> > >>> contributors as committer and PMC member? That would surely bring
>> > >>> clarity.
>> > >>>
>> > >>>  I would be very unhappy with "aren´t allowed", that is something
>> the
>> > >> individual PMCs should decide !
>> > >>
>> > >
>> > > Yes indeed that's PMCs 's remit; we just need to clarify the ASF
>> default.
>> > >
>> > > Jacques
>> > >
>> > >
>> > >
>> > >> rgds
>> > >> jan I.
>> > >>
>> > >>
>> > >>  Best regards,
>> > >>>
>> > >>> Pierre Smits
>> > >>>
>> > >>> *ORRTIZ.COM *
>> > >>> Services & Solutions for Cloud-
>> > >>> Based Manufacturing, Professional
>> > >>> Services and Retail & Trade
>> > >>> http://www.orrtiz.com
>> > >>>
>> > >>> On Sun, Mar 22, 2015 at 2:25 PM, Bertrand Delacretaz <
>> > >>> bdelacre...@apache.org
>> > >>>
>> >  wrote:
>> >  On Sun, Mar 22, 2015 at 2:17 PM, Jacques Le Roux
>> >   wrote:
>> > 
>> > > ...Thanks for the clarification Bertrand, this was also unclear to
>> > me.
>> > >
>> >  Should
>> > 
>> > > we not amend the newcommitter page?..
>> > >
>> >  That would be great, I don't have time right now myself.
>> >  -Bertrand
>> > 
>> > 
>> >
>>
>
>


Re: Veto! Veto?

2015-03-23 Thread Pierre Smits
The principle/policy/rule of the ASF regarding code changes is very
explicit, well documented and unambiguous. Can a project's PMC have another
methodology in place while being part of the ASF? I guess not.

Consensus with respect to on and off boarding of people is nice, as it
expresses unanimity. And I, as I expect it to be for all, am all for it.
But to have it as an requirement would be a show stopper.

Would it be ok for the ASF if there were a project under its umbrella, that
would say: that majority voting principle you for procedural issues is
nice, but for us - when it comes to people - we veto
promotors/speakers/book writers to participate in our project with
privileges (commit right, PMC membership)? Or, that it vetoes people from
France (this is example, I have nothing against people from France or even
with the French nationality)?

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Mon, Mar 23, 2015 at 9:20 AM, jan i  wrote:

> On 23 March 2015 at 09:02, Pierre Smits  wrote:
>
> > When it comes to people, consensus (acceptance by unanimity) is the best
> > thing to have. But if the ASF has as its principle that no vetoes are
> > allowed, how can it be the remit of a project's PMC have it as its
> policy?
> >
>
> I think it is a matter of wording, I do not think it is a ASF Principle
> (actually not sure how that relates to "policy") that veto is not allowed,
> Consensus is the ASF Principle. We all want to avoid Vetos, for many good
> reasons, but that it not the same as not being allowed.
>
> As a Foundation we try to have very few rules and policies, and let the
> communities handle how they want to do it, this here is surely
> a case where we do not a foundation wide rule.
>
> I would have no problem, if the wording on the page was something like "it
> is recommended not to use Veto"
>
> Pierre@ maybe just for my understanding, why would ASF be better, if we
> make this rule foundation wide, instead of leaving it up to
> the single community ?
>
> rgds
> jan I.
>
>
> > Best regards,
> >
> >
> > Pierre Smits
> >
> > *ORRTIZ.COM *
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
> >
> > On Sun, Mar 22, 2015 at 3:17 PM, Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> > > Le 22/03/2015 14:42, jan i a écrit :
> > >
> > >> On 22 March 2015 at 14:35, Pierre Smits 
> wrote:
> > >>
> > >>  HI Bertrand,
> > >>>
> > >>> Thanks for the clarification regarding
> > >>> http://community.apache.org/newcommitter.html
> > >>>
> > >>> Shouldn't http://www.apache.org/foundation/voting.html then also
> > >>> explicitly
> > >>> reflect that vetoes aren't allowed when it comes to on- and
> ofboarding
> > >>> contributors as committer and PMC member? That would surely bring
> > >>> clarity.
> > >>>
> > >>>  I would be very unhappy with "aren´t allowed", that is something the
> > >> individual PMCs should decide !
> > >>
> > >
> > > Yes indeed that's PMCs 's remit; we just need to clarify the ASF
> default.
> > >
> > > Jacques
> > >
> > >
> > >
> > >> rgds
> > >> jan I.
> > >>
> > >>
> > >>  Best regards,
> > >>>
> > >>> Pierre Smits
> > >>>
> > >>> *ORRTIZ.COM *
> > >>> Services & Solutions for Cloud-
> > >>> Based Manufacturing, Professional
> > >>> Services and Retail & Trade
> > >>> http://www.orrtiz.com
> > >>>
> > >>> On Sun, Mar 22, 2015 at 2:25 PM, Bertrand Delacretaz <
> > >>> bdelacre...@apache.org
> > >>>
> >  wrote:
> >  On Sun, Mar 22, 2015 at 2:17 PM, Jacques Le Roux
> >   wrote:
> > 
> > > ...Thanks for the clarification Bertrand, this was also unclear to
> > me.
> > >
> >  Should
> > 
> > > we not amend the newcommitter page?..
> > >
> >  That would be great, I don't have time right now myself.
> >  -Bertrand
> > 
> > 
> >
>


Re: Veto! Veto?

2015-03-23 Thread jan i
On Monday, March 23, 2015, Pierre Smits  wrote:

> The principle/policy/rule of the ASF regarding code changes is very
> explicit, well documented and unambiguous. Can a project's PMC have another
> methodology in place while being part of the ASF? I guess not.


not another but always a tougher (e.g. 6+1 no -1).

>
> Consensus with respect to on and off boarding of people is nice, as it
> expresses unanimity. And I, as I expect it to be for all, am all for it.
> But to have it as an requirement would be a show stopper.
>
> Would it be ok for the ASF if there were a project under its umbrella, that
> would say: that majority voting principle you for procedural issues is
> nice, but for us - when it comes to people - we veto
> promotors/speakers/book writers to participate in our project with
> privileges (commit right, PMC membership)? Or, that it vetoes people from
> France (this is example, I have nothing against people from France or even
> with the French nationality)?
>
> If the community wants it like that, then there is consensus. It is not
the task of ASF to police the communities.

We must be very careful only to make ASF wide rules where it is really
needed e.g. our release policy is there for legal reasons.

rgds
jan i


> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Mon, Mar 23, 2015 at 9:20 AM, jan i >
> wrote:
>
> > On 23 March 2015 at 09:02, Pierre Smits  > wrote:
> >
> > > When it comes to people, consensus (acceptance by unanimity) is the
> best
> > > thing to have. But if the ASF has as its principle that no vetoes are
> > > allowed, how can it be the remit of a project's PMC have it as its
> > policy?
> > >
> >
> > I think it is a matter of wording, I do not think it is a ASF Principle
> > (actually not sure how that relates to "policy") that veto is not
> allowed,
> > Consensus is the ASF Principle. We all want to avoid Vetos, for many good
> > reasons, but that it not the same as not being allowed.
> >
> > As a Foundation we try to have very few rules and policies, and let the
> > communities handle how they want to do it, this here is surely
> > a case where we do not a foundation wide rule.
> >
> > I would have no problem, if the wording on the page was something like
> "it
> > is recommended not to use Veto"
> >
> > Pierre@ maybe just for my understanding, why would ASF be better, if we
> > make this rule foundation wide, instead of leaving it up to
> > the single community ?
> >
> > rgds
> > jan I.
> >
> >
> > > Best regards,
> > >
> > >
> > > Pierre Smits
> > >
> > > *ORRTIZ.COM *
> > > Services & Solutions for Cloud-
> > > Based Manufacturing, Professional
> > > Services and Retail & Trade
> > > http://www.orrtiz.com
> > >
> > > On Sun, Mar 22, 2015 at 3:17 PM, Jacques Le Roux <
> > > jacques.le.r...@les7arts.com > wrote:
> > >
> > > > Le 22/03/2015 14:42, jan i a écrit :
> > > >
> > > >> On 22 March 2015 at 14:35, Pierre Smits  >
> > wrote:
> > > >>
> > > >>  HI Bertrand,
> > > >>>
> > > >>> Thanks for the clarification regarding
> > > >>> http://community.apache.org/newcommitter.html
> > > >>>
> > > >>> Shouldn't http://www.apache.org/foundation/voting.html then also
> > > >>> explicitly
> > > >>> reflect that vetoes aren't allowed when it comes to on- and
> > ofboarding
> > > >>> contributors as committer and PMC member? That would surely bring
> > > >>> clarity.
> > > >>>
> > > >>>  I would be very unhappy with "aren´t allowed", that is something
> the
> > > >> individual PMCs should decide !
> > > >>
> > > >
> > > > Yes indeed that's PMCs 's remit; we just need to clarify the ASF
> > default.
> > > >
> > > > Jacques
> > > >
> > > >
> > > >
> > > >> rgds
> > > >> jan I.
> > > >>
> > > >>
> > > >>  Best regards,
> > > >>>
> > > >>> Pierre Smits
> > > >>>
> > > >>> *ORRTIZ.COM *
> > > >>> Services & Solutions for Cloud-
> > > >>> Based Manufacturing, Professional
> > > >>> Services and Retail & Trade
> > > >>> http://www.orrtiz.com
> > > >>>
> > > >>> On Sun, Mar 22, 2015 at 2:25 PM, Bertrand Delacretaz <
> > > >>> bdelacre...@apache.org 
> > > >>>
> > >  wrote:
> > >  On Sun, Mar 22, 2015 at 2:17 PM, Jacques Le Roux
> > >  > wrote:
> > > 
> > > > ...Thanks for the clarification Bertrand, this was also unclear
> to
> > > me.
> > > >
> > >  Should
> > > 
> > > > we not amend the newcommitter page?..
> > > >
> > >  That would be great, I don't have time right now myself.
> > >  -Bertrand
> > > 
> > > 
> > >
> >
>


-- 
Sent from My iPad, sorry for any misspellings.


Re: Veto! Veto?

2015-03-23 Thread Pierre Smits
The ASF defines the boundaries by with the projects are allowed to operate
under its umbrella. If a project doesn't want to adhere to that, it doesn't
belong under its umbrella.

If one of its principles or boundaries is community over code and if the
ASF wants that the diversity within the communities of it projects is
reflected in the group of committers and in PMC, how can it then be that a
PMC may have it different and can veto on- and off-boarding of persons of
the other kind?

And by the way: Yes, it is the task of the ASF (meaning every person within
the greater community of the ASF, contributor, committer, PMC member, VP
and etc) to guard that the principles of the ASF are upheld. As it is the
task of the Board to police.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Mon, Mar 23, 2015 at 10:05 AM, jan i  wrote:

> On Monday, March 23, 2015, Pierre Smits  wrote:
>
> > The principle/policy/rule of the ASF regarding code changes is very
> > explicit, well documented and unambiguous. Can a project's PMC have
> another
> > methodology in place while being part of the ASF? I guess not.
>
>
> not another but always a tougher (e.g. 6+1 no -1).
>
> >
> > Consensus with respect to on and off boarding of people is nice, as it
> > expresses unanimity. And I, as I expect it to be for all, am all for it.
> > But to have it as an requirement would be a show stopper.
> >
> > Would it be ok for the ASF if there were a project under its umbrella,
> that
> > would say: that majority voting principle you for procedural issues is
> > nice, but for us - when it comes to people - we veto
> > promotors/speakers/book writers to participate in our project with
> > privileges (commit right, PMC membership)? Or, that it vetoes people from
> > France (this is example, I have nothing against people from France or
> even
> > with the French nationality)?
> >
> > If the community wants it like that, then there is consensus. It is not
> the task of ASF to police the communities.
>
> We must be very careful only to make ASF wide rules where it is really
> needed e.g. our release policy is there for legal reasons.
>
> rgds
> jan i
>
>
> > Best regards,
> >
> > Pierre Smits
> >
> > *ORRTIZ.COM *
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
> >
> > On Mon, Mar 23, 2015 at 9:20 AM, jan i >
> > wrote:
> >
> > > On 23 March 2015 at 09:02, Pierre Smits  > > wrote:
> > >
> > > > When it comes to people, consensus (acceptance by unanimity) is the
> > best
> > > > thing to have. But if the ASF has as its principle that no vetoes are
> > > > allowed, how can it be the remit of a project's PMC have it as its
> > > policy?
> > > >
> > >
> > > I think it is a matter of wording, I do not think it is a ASF Principle
> > > (actually not sure how that relates to "policy") that veto is not
> > allowed,
> > > Consensus is the ASF Principle. We all want to avoid Vetos, for many
> good
> > > reasons, but that it not the same as not being allowed.
> > >
> > > As a Foundation we try to have very few rules and policies, and let the
> > > communities handle how they want to do it, this here is surely
> > > a case where we do not a foundation wide rule.
> > >
> > > I would have no problem, if the wording on the page was something like
> > "it
> > > is recommended not to use Veto"
> > >
> > > Pierre@ maybe just for my understanding, why would ASF be better, if
> we
> > > make this rule foundation wide, instead of leaving it up to
> > > the single community ?
> > >
> > > rgds
> > > jan I.
> > >
> > >
> > > > Best regards,
> > > >
> > > >
> > > > Pierre Smits
> > > >
> > > > *ORRTIZ.COM *
> > > > Services & Solutions for Cloud-
> > > > Based Manufacturing, Professional
> > > > Services and Retail & Trade
> > > > http://www.orrtiz.com
> > > >
> > > > On Sun, Mar 22, 2015 at 3:17 PM, Jacques Le Roux <
> > > > jacques.le.r...@les7arts.com > wrote:
> > > >
> > > > > Le 22/03/2015 14:42, jan i a écrit :
> > > > >
> > > > >> On 22 March 2015 at 14:35, Pierre Smits  > >
> > > wrote:
> > > > >>
> > > > >>  HI Bertrand,
> > > > >>>
> > > > >>> Thanks for the clarification regarding
> > > > >>> http://community.apache.org/newcommitter.html
> > > > >>>
> > > > >>> Shouldn't http://www.apache.org/foundation/voting.html then also
> > > > >>> explicitly
> > > > >>> reflect that vetoes aren't allowed when it comes to on- and
> > > ofboarding
> > > > >>> contributors as committer and PMC member? That would surely bring
> > > > >>> clarity.
> > > > >>>
> > > > >>>  I would be very unhappy with "aren´t allowed", that is something
> > the
> > > > >> individual PMCs should decide !
> > > > >>
> > > > >
> > > > > Yes indeed that's PMCs 's remit; we just need to clarify the ASF
> > > default.
> > > > >
> > > > > J

Re: Veto! Veto?

2015-03-23 Thread Rob Vesse
On 21/03/2015 19:24, "Pierre Smits"  wrote:

>If in stead of the veto possibility the simple majority rule was at play,
>it might have been so that fewer project would have reported consecutively
>that no new people were onboarded

A lack of new people on-boarded does not necessarily indicate a project in
trouble (though it may do so).  More often than not in my experience (at
least outside of the Incubator which is a special case) it represents an
established mature project with a low rate of turnover and attrition in
the active community.

If the PMC worries they are stagnating personnel wise they should report
that in their board report or a PMC member could report privately to
board@ if they think there is an issue that the PMC is not publicly
acknowledging.  

On the other hand if the board thinks the projects lack of new
committers/PMC members is an issue then they can and will follow up on
that with the relevant PMC.

Rob






Apache POI CTPageMar not found

2015-03-23 Thread r01942072
I am using eclipse. I download Apache POI 3.12 Beta 1, add all jar files into 
java build path, but eclipse tells me that CTPageMar not found. Part of my code 
is shown below.

XWPFDocument doc = new XWPFDocument();
CTDocument1 doc1 = doc.get Document();
CTBody body = doc1.getBody();
CTSectPr sect = body.getSectPr();
CTPageMar mar = sect.getPgMar();

Only the last line contains error because CTPageMar not found.

Re: Apache POI CTPageMar not found

2015-03-23 Thread Nick Burch

On Mon, 23 Mar 2015, r01942072 wrote:
I am using eclipse. I download Apache POI 3.12 Beta 1, add all jar files 
into java build path, but eclipse tells me that CTPageMar not found. 
Part of my code is shown below.


This would be best asked on the POI user list, see 
http://poi.apache.org/mailinglists.html for the list archive and how to 
subscribe to the user list


However, you probably also want to read this POI FAQ entry which covers 
your problem: http://poi.apache.org/faq.html#faq-N10025


Nick


Re: ACNA Presentation Template

2015-03-23 Thread Rich Bowen



On 03/21/2015 01:04 PM, Roman Shaposhnik wrote:

Sorry for jumping into the discussion late, but is there a chance for
[semi-]official templates to be available for ACNA15?



That's what we're discussing here.



Thanks,
Roman.

On Fri, Mar 20, 2015 at 12:46 PM, Andrea Pescetti  wrote:

On 19/03/2015 Rich Bowen wrote:



http://templates.openoffice.org/en/search?search_api_views_fulltext=apachecon&sort_by=created&sort_order=ASC
and also
http://people.apache.org/~nick/NickTemplateACEU14.odp
Also, see
http://mail-archives.apache.org/mod_mbox/community-dev/201411.mbox/browser
for discussion of the differences between the two, and the fact that,
apparently, one of them is 14MB, and what to do about it.



The unusable (14MB or so) one is neither of the above. It had been
graciously provided by the Linux Foundation to speakers.

Community-produced OpenOffice templates that were actually used at
conferences are the following:

ApacheCon Europe 2012
http://templates.openoffice.org/en/template/apachecon-europe-2012-presentation

ApacheCon NA 2013
http://templates.openoffice.org/en/template/apachecon-north-amaerica-2013

ApacheCon EU 2014
http://people.apache.org/~nick/NickTemplateACEU14.odp
(this ought to have been uploaded to the Templates site too, but apparently
Linux Foundation never clarified the terms of usage for some images that
Nick included into it)

By the way, we happen to be speaking about a specific sub-sub-issue where
the Linux Foundation didn't do a great job, but ApacheCon Budapest was
amazing, and they surely have a lot of merit for it!

Regards,
   Andrea.



--
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon


Re: ACNA Presentation Template

2015-03-23 Thread Rich Bowen



On 03/22/2015 12:40 PM, Dennis E. Hamilton wrote:

Thanks Nick, those are great!

I consider the problem solved.


+1



In anticipation of the next AC-anywhere, I want to help turn this (and the 
previous two under Linux Foundation) into a form that can be 
repurposed/reused/customized along with information on how to do it and the 
resources/skills that are required.

Removing the crunch requirement is great.


Well, we need one for AC Europe, too. so there's about 6 months to work 
on that one. :-)


apachecon.eu

--Rich



  - Dennis,
Now having learned what some folks consider simple requests
(and solutions) around here.

-Original Message-
From: Nick Burch [mailto:n...@apache.org]
Sent: Sunday, March 22, 2015 07:48
To: dev@community.apache.org
Subject: Re: ACNA Presentation Template

Hi All

I've had a go at updating my Budapest template for Austin, draft so far
available at:
http://people.apache.org/~nick/Draft_ACNA15_Template_Nick.odp

[ ... ]




--
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon


ACEU Presentation Template

2015-03-23 Thread Dennis E. Hamilton
Truly back at the same venue?  
.  The hotel that 
gave rise to an Apache Project (incubating).  Great!

Wow, the logo with just "ApacheCon Europe" over the feather is great.  Much 
easier to customize that one just once for Europe, and just once for North 
America.  It also appears that many of the slide used had more simplicity of 
backgrounds.

That I can handle, with backgrounds and venue information separately 
customizable.

Remind me at OSCON if I haven't done it already.

 - Dennis

-Original Message-
From: Rich Bowen [mailto:rbo...@rcbowen.com] 
Sent: Monday, March 23, 2015 06:56
To: dev@community.apache.org
Subject: Re: ACNA Presentation Template



On 03/22/2015 12:40 PM, Dennis E. Hamilton wrote:
[ ... ]
> In anticipation of the next AC-anywhere, I want to help turn this (and the 
> previous two under Linux Foundation) into a form that can be 
> repurposed/reused/customized along with information on how to do it and the 
> resources/skills that are required.
>
> Removing the crunch requirement is great.

Well, we need one for AC Europe, too. so there's about 6 months to work 
on that one. :-)

apachecon.eu

--Rich




RE: Veto! Veto?

2015-03-23 Thread Dennis E. Hamilton
I think we should not confuse consensus with unanimity, because a -1 need not 
cure to a +1.  The procedures are more nuanced than that, 
, and there are many 
ways a cooperating participant can express their concern.  

I do notice that there is confusion about "Consensus Approval" versus "Majority 
Approval" because the description of "Consensus Approval" uses the "veto" word, 
.  

I have seen nothing that requires unanimity in the absence of the veto rule 
where it *specifically* applies to commits in ASF principles.  

I notice that "unanimity" is absent as a term in what I read of ASF principles. 
 I assume that it is intentional that such a clear term is not used.  I read 
this as allowing for consent that is not full agreement but is an alignment, 
almost always with any -1 vote cured.  See for example, the description of ways 
votes are expressed at .

Another important feature of ASF principles that I see is that ASF is not 
preoccupied with hypotheticals.  The ASF principles have behind them the 
presumption that people of good will can work out matters in a non-adversarial 
manner and that the project communities are trusted to do that.  It is what the 
ASF expects.  And it works.  We have been told repeatedly in this thread how 
extremely rare it is for it to be otherwise and the feared hypothetical 
actually arising.

It is good to stop fretting over hypotheticals and simply operate from good 
will.  If something unfortunate arises, it can be dealt with in whatever the 
actual context is.

 - Dennis

-Original Message-
From: Pierre Smits [mailto:pierre.sm...@gmail.com] 
Sent: Monday, March 23, 2015 01:02
To: dev@community.apache.org
Subject: Re: Veto! Veto?

When it comes to people, consensus (acceptance by unanimity) is the best
thing to have. But if the ASF has as its principle that no vetoes are
allowed, how can it be the remit of a project's PMC have it as its policy?

Best regards,


Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Sun, Mar 22, 2015 at 3:17 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Le 22/03/2015 14:42, jan i a écrit :
>
>> On 22 March 2015 at 14:35, Pierre Smits  wrote:
>>
>>  HI Bertrand,
>>>
>>> Thanks for the clarification regarding
>>> http://community.apache.org/newcommitter.html
>>>
>>> Shouldn't http://www.apache.org/foundation/voting.html then also
>>> explicitly
>>> reflect that vetoes aren't allowed when it comes to on- and ofboarding
>>> contributors as committer and PMC member? That would surely bring
>>> clarity.
>>>
>>>  I would be very unhappy with "aren´t allowed", that is something the
>> individual PMCs should decide !
>>
>
> Yes indeed that's PMCs 's remit; we just need to clarify the ASF default.
>
> Jacques
>
>
>
>> rgds
>> jan I.
>>
>>
>>  Best regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM *
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Sun, Mar 22, 2015 at 2:25 PM, Bertrand Delacretaz <
>>> bdelacre...@apache.org
>>>
 wrote:
 On Sun, Mar 22, 2015 at 2:17 PM, Jacques Le Roux
  wrote:

> ...Thanks for the clarification Bertrand, this was also unclear to me.
>
 Should

> we not amend the newcommitter page?..
>
 That would be great, I don't have time right now myself.
 -Bertrand





Re: ACNA Presentation Template

2015-03-23 Thread Nick Burch

On Mon, 23 Mar 2015, Rich Bowen wrote:

On 03/22/2015 12:40 PM, Dennis E. Hamilton wrote:

Thanks Nick, those are great!

I consider the problem solved.


+1


OK then! Please all consider 
http://people.apache.org/~nick/ACNA15_Template_Nick.odp as ready for use 
by those who wish!


Nick


Re: Veto! Veto?

2015-03-23 Thread Rich Bowen



On 03/23/2015 05:39 AM, Pierre Smits wrote:

The ASF defines the boundaries by with the projects are allowed to operate
under its umbrella. If a project doesn't want to adhere to that, it doesn't
belong under its umbrella.

If one of its principles or boundaries is community over code and if the
ASF wants that the diversity within the communities of it projects is
reflected in the group of committers and in PMC, how can it then be that a
PMC may have it different and can veto on- and off-boarding of persons of
the other kind?

And by the way: Yes, it is the task of the ASF (meaning every person within
the greater community of the ASF, contributor, committer, PMC member, VP
and etc) to guard that the principles of the ASF are upheld. As it is the
task of the Board to police.


The board doesn't like to be the police.

The "policy" document that is being cited is what is promoted at the 
Foundation level as best practice, but individual projects are at 
liberty to adopt those guidelines, or not, as long as fundamentals are 
respected.


If a project decides not to make a certain individual a committer, the 
Board *will not* step in to police that, as you say. It is the project's 
decision who will be a committer.


Some projects adopt a "universal committer bit" policy, while others 
have specific guidelines for inviting a committer. And there's 
everything in between. The board is not going to police this.


Your question - "how can it be" - has a simple answer. Because the board 
isn't here to tell projects how to make their technical decisions, and 
inviting a committer is at the heart of technical decisions, because it 
hands those decisions to a new person. The board is not going to tell a 
project how to invite committers.


The board, and comdev, will say "here's how we think things should go", 
but there's a lot of room between a mature project like httpd, where 
someone has 20 years worth of information to read about how to get 
started, and a newer project like, say, Open Climate Workbench, which 
requires a deep understanding of climate science to contribute 
meaningfully**, which completely justifies different levels of "barrier 
to entry" when it comes to inviting committers.


--Rich



** Note: This is a hypothetical example. I don't actually know anything 
about OCW. Please don't get bogged down in the example if I'm mistaken.


--
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon


Re: Veto! Veto?

2015-03-23 Thread Alex Harui


On 3/23/15, 2:39 AM, "Pierre Smits"  wrote:
>
>If one of its principles or boundaries is community over code and if the
>ASF wants that the diversity within the communities of it projects is
>reflected in the group of committers and in PMC, how can it then be that a
>PMC may have it different and can veto on- and off-boarding of persons of
>the other kind?

A healthy community can have vetoes for people actions and never mis-use
them.  Vetoes are supposed to have a justification for the veto attached
to it.  Vetoes based on discrimination should probably result in the
vetoer getting removed from the PMC if they refuse to rescind their veto.

It sounds like your community should not be allowing vetoes.  Start the
process of making that change and ask for board support if you need it
since there is precedent for this very thing.  That newcommitter page cost
at least one other project some serious time.

-Alex



Re: Veto! Veto?

2015-03-23 Thread Rich Bowen



On 03/23/2015 12:44 PM, Alex Harui wrote:



On 3/23/15, 2:39 AM, "Pierre Smits"  wrote:


If one of its principles or boundaries is community over code and if the
ASF wants that the diversity within the communities of it projects is
reflected in the group of committers and in PMC, how can it then be that a
PMC may have it different and can veto on- and off-boarding of persons of
the other kind?


A healthy community can have vetoes for people actions and never mis-use
them.  Vetoes are supposed to have a justification for the veto attached
to it.  Vetoes based on discrimination should probably result in the
vetoer getting removed from the PMC if they refuse to rescind their veto.

It sounds like your community should not be allowing vetoes.  Start the
process of making that change and ask for board support if you need it
since there is precedent for this very thing.  That newcommitter page cost
at least one other project some serious time.



The board is going to be VERY reluctant to tell a PMC how to invite 
committers. I would almost go so far as to say that the board WILL NOT 
do that, unless there's compelling evidence that the PMC is being 
anti-community in their practices - for example, refusing to select 
committers with particular corporate affiliations, or people of 
particular race/gender/creed.


Yes, a DISCUSS conversation should have resolved difficulties before it 
ever came to a VOTE, and it's regrettable that it didn't. Indeed, it's 
regrettable, in my opinion, that a committer should be vetoed at all. 
But it's not the role of the board to dictate to a project who they 
should give the commit bit to.




--
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon


Re: Veto! Veto?

2015-03-23 Thread Mike Kienenberger
On Mon, Mar 23, 2015 at 12:39 PM, Rich Bowen  wrote:

> The board, and comdev, will say "here's how we think things should go",
> but there's a lot of room between a mature project like httpd, where
> someone has 20 years worth of information to read about how to get started,
> and a newer project like, say, Open Climate Workbench, which requires a
> deep understanding of climate science to contribute meaningfully**, which
> completely justifies different levels of "barrier to entry" when it comes
> to inviting committers.
>
> ** Note: This is a hypothetical example. I don't actually know anything
> about OCW. Please don't get bogged down in the example if I'm mistaken.


Here's a better not-quite-so-hypothetical example.   A project like MyFaces
has to pass the TCK testing suite provided by Oracle.   We would not want
to allow unrestricted commit access by someone who did not
understand profoundly and intuitively that the JSF API portion of the
project has a predefined public API which cannot be changed.


Re: gtk requirements for builds?

2015-03-23 Thread Kay Schenk
sorry for this post -- wrong "dev" list

On 03/22/2015 02:04 PM, Kay Schenk wrote:
> GTK is enabled by default for our builds.
> 
> I don't see this listed as a build requirement for either Windows or
> Mac, however. So, should this build flag be changed to non-enabled
> generally and only enabled for Linux?
> 

-- 
-
MzK

“What is the point of being alive if you don't
 at least  try to do something remarkable?”
   -- John Green, "An Abundance of Katherines"


Re: Veto! Veto?

2015-03-23 Thread Ted Dunning
On Mon, Mar 23, 2015 at 9:59 AM, Mike Kienenberger 
wrote:

> On Mon, Mar 23, 2015 at 12:39 PM, Rich Bowen  wrote:
>
> > The board, and comdev, will say "here's how we think things should go",
> > but there's a lot of room between a mature project like httpd, where
> > someone has 20 years worth of information to read about how to get
> started,
> > and a newer project like, say, Open Climate Workbench, which requires a
> > deep understanding of climate science to contribute meaningfully**, which
> > completely justifies different levels of "barrier to entry" when it comes
> > to inviting committers.
> >
> > ** Note: This is a hypothetical example. I don't actually know anything
> > about OCW. Please don't get bogged down in the example if I'm mistaken.
>
>
> Here's a better not-quite-so-hypothetical example.   A project like MyFaces
> has to pass the TCK testing suite provided by Oracle.   We would not want
> to allow unrestricted commit access by someone who did not
> understand profoundly and intuitively that the JSF API portion of the
> project has a predefined public API which cannot be changed.


Some projects feel this way.  Others have found that review is just as
effective as restricting commit bits tightly.  The classic case is
Subversion which has a very high profile (and thus is obliged to have
stable API's).  That PMC offers a commit bit to anyone who asks.

People seem to forget that erroneous commits that pass review can simply be
reverted.  That is one of the points of using version control.


Re: Veto! Veto?

2015-03-23 Thread Roman Shaposhnik
On Mon, Mar 23, 2015 at 9:39 AM, Rich Bowen  wrote:
> If a project decides not to make a certain individual a committer, the Board
> *will not* step in to police that, as you say. It is the project's decision
> who will be a committer.

Right. At the same time if the hypothetical PMC repeatedly fails at fostering
the community by recognizing certain types of merit I will expect the board to
get involved at some point. But! It will expect it to get involved b/c
of the community
shepherding issue, not so much because a procedural guideline has
been violated.

I know this may be irritatingly nebulous (especially to folks who haven't been
around long enough to benefit from the ASF osmosis) but I feel this is
one the key things I *really* like about how ASF is governed.

Thanks,
Roman.


Re: Veto! Veto?

2015-03-23 Thread Rich Bowen



On 03/23/2015 01:31 PM, Ted Dunning wrote:

Here's a better not-quite-so-hypothetical example.   A project like MyFaces
>has to pass the TCK testing suite provided by Oracle.   We would not want
>to allow unrestricted commit access by someone who did not
>understand profoundly and intuitively that the JSF API portion of the
>project has a predefined public API which cannot be changed.


Some projects feel this way.  Others have found that review is just as
effective as restricting commit bits tightly.  The classic case is
Subversion which has a very high profile (and thus is obliged to have
stable API's).  That PMC offers a commit bit to anyone who asks.

People seem to forget that erroneous commits that pass review can simply be
reverted.  That is one of the points of using version control.




Well, sure, and as the board, or as comdev, we can say that that's best 
practice, and encourage projects to adopt that. But we're not going to 
*require* that they do that. Because they might have a different way 
that they want to do things, and it's not our job to tell them that 
their reasons are invalid.


The ASF exists to facilitate project communities. Not to dictate to them 
how they should run their project. Just to make a welcoming place for 
them to operate. As such, we keep the MUST rules to a minimum, and the 
SHOULD suggestions are where most of our discussion happens.



--
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon


Re: Veto! Veto?

2015-03-23 Thread Mike Kienenberger
On Mon, Mar 23, 2015 at 1:31 PM, Ted Dunning  wrote:

> > Here's a better not-quite-so-hypothetical example.   A project like
> MyFaces
> > has to pass the TCK testing suite provided by Oracle.   We would not want
> > to allow unrestricted commit access by someone who did not
> > understand profoundly and intuitively that the JSF API portion of the
> > project has a predefined public API which cannot be changed.
>
>
> Some projects feel this way.  Others have found that review is just as
> effective as restricting commit bits tightly.  The classic case is
> Subversion which has a very high profile (and thus is obliged to have
> stable API's).  That PMC offers a commit bit to anyone who asks.
>
> People seem to forget that erroneous commits that pass review can simply be
> reverted.  That is one of the points of using version control.
>

Yes, either approach could be used.  Myfaces doesn't filter candidates
based on this criteria -- we train contributers when they submit their
first patches to the API project -- but a TCK project might decide to do
so.   The message probably should have read "They might not want to allow"
rather than "We would not want to allow " as it gave the wrong impression.