Re: Apache project bylaws

[Alex Harui]

On 10/2/13 12:58 PM, "Marvin Humphrey"  wrote:

>On Wed, Oct 2, 2013 at 11:35 AM, Alex Harui  wrote:
>> I would like to propose a rewrite of [1] by borrowing heavily from [2]
>>but
>> making sure to emphasize that projects are allowed to have different
>>rules
>> for all of them (or is the code-commit veto required for all projects).
>> Any objections to me trying to do that?
>
>Rather than a "rewrite", I suggest proposing small, incremental,
>reversible
>changes.  Governance is easy to mess up.
Well, "small, incremental" was hard to do given the significantly
different information this document must now convey. I tried to keep as
much as possible yet incorporate feedback from Doug and Roy.   Below is my
proposed version, and below it is the svn diff in case that makes it
easier to see what changed.  Most of the changes were made at the
beginning.

I'm sure I haven't nailed it so feel free to comment.  And I'm not quite
sure how to do a table in mdtext.  I'm off to sleep so I'll respond
several hours from now.  Thanks for reading...

-Alex

--- Updated voting.mdtext --
Title: Apache Voting Process
Notice:Licensed to the Apache Software Foundation (ASF) under one
   or more contributor license agreements.  See the NOTICE file
   distributed with this work for additional information
   regarding copyright ownership.  The ASF licenses this file
   to you under the Apache License, Version 2.0 (the
   "License"); you may not use this file except in compliance
   with the License.  You may obtain a copy of the License at
   .
 http://www.apache.org/licenses/LICENSE-2.0
   .
   Unless required by applicable law or agreed to in writing,
   software distributed under the License is distributed on an
   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
   KIND, either express or implied.  See the License for the
   specific language governing permissions and limitations
   under the License.

At the Apache Software Foundation, two decisions must be made by a vote
held on a
project's mailing list.  The two decisions are:

1. Code modifications,

1. Package releases

Other decisions are commonly made via votes as well, but a project may
draft by-laws
 or guidelines that describe variations to the voting processes described
below.
If a project does not draft by-laws or guidelines, it is assumed that any
votes
held to make any of the decisions listed below follow the processes
described below.

Many projects make the following decisions via voting:

1. Approving a new committer

1. Approving a new PMC member

1. Approving a new PMC Chair

1. Removing a committer

1. Removing a PMC member

1. Approving by-laws or guidelines or changes to by-laws or guidelines

Many project by-laws and guidelines describe other decisions made via
voting.
Use of [lazy consensus](#LazyConsensus) is recommended for as many other
decisions as possible.

Here is a table of the default voting processes:


ActionApprovalDuration
Code Modification[lazy
consensus](#LazyConsensus)72 hours
Approve Release[majority](#Majority)72
hours
Approve New Committer[consensus](#Consensus)72
hours
Approve New PMC Member[consensus](#Consensus)72
hours
Approve New PMC Chair[consensus](#Consensus)72
hours
Remove
Committer[consensus-but-one](#ConsensusButOne)72
hours
Remove PMC
Member[consensus-but-one](#ConsensusButOne)72
hours
Approve/Change
By-laws/Guidelines[majority](#Majority)72 hours
Approve Donation[consensus](#Consensus)72
hours

# Binding Votes #

Who is permitted to vote is, to some extent, a project-specific thing.
However, the default rule is that for Code Modification, any committer's
veto counts,
but for all other decisions only PMC members have binding votes, and
all others have their votes considered of an indicative or advisory nature
only.

By default, only "active" PMC members may cast votes.  Project's can
define their
own definition of active, but the default definition is whether that
member has
sent an email on any Apache mailing list, made a change to any asset under
Apache
version control, or voted on any vote thread.  This low bar is intended to
cover
"mature" projects that don't do much other than file quarterly reports.

# Implications of Voting #

In some cases and communities, the exercise of a vote carries some
responsibilities that may not be immediately obvious. For example, in some
cases a favourable vote carries the implied message 'I approve **and** I'm
willing to help.' Also, an unfavourable vote may imply that 'I disapprove,
but I have an alternative and will help with that alternative.'

The tacit implications of voting should be spelt out in the community's
guidelines. However, **in no case** may someone's vote be considered
invalid if the implied commitment doesn't appear to be met; a vote is a
formal expression of opinion, *not* of commitment.

If the [R-T-C](#ReviewThenCommit) 

Re: [VOTE] BatchEE as an incubated project

[Romain Manni-Bucau]

And here is my +1

I'll prepare the result mail.

*Romain Manni-Bucau*
*Twitter: @rmannibucau *
*Blog: **http://rmannibucau.wordpress.com/*
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/10/1 Tammo van Lessen 

> +1 (binding)
>
> Best,
>   Tammo
>
>
> On Mon, Sep 30, 2013 at 7:24 PM, Gerhard Petracek <
> gerhard.petra...@gmail.com> wrote:
>
> > +1
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2013/9/30 Matthias Wessendorf 
> >
> > > +1 (binding)
> > >
> > > On Monday, September 30, 2013, Mark Struberg wrote:
> > >
> > > > +1 (binding)
> > > >
> > > > LieGrue,
> > > > strub
> > > >
> > > >
> > > >
> > > >
> > > > - Original Message -
> > > > > From: Romain Manni-Bucau 
> > > > > To: general@incubator.apache.org
> > > > > Cc:
> > > > > Sent: Monday, 30 September 2013, 6:52
> > > > > Subject: [VOTE] BatchEE as an incubated project
> > > > >
> > > > > Since discussion about the BatchEE seems done, I'd like to call a
> > vote
> > > > for
> > > > > BatchEE to
> > > > > become an incubated project.
> > > > >
> > > > > The proposal is pasted below, and also available at:
> > > > > https://wiki.apache.org/incubator/BatchEEProposal
> > > > >
> > > > > Let's keep this vote open for three business days, closing the
> voting
> > > on
> > > > > Thursday 10/03.
> > > > >
> > > > > [ ] +1 Accept BatchEE into the Incubator
> > > > > [ ] +0 Don't care.
> > > > > [ ] -1 Don't accept BatchEE because...
> > > > >
> > > > >
> > > > > = BatchEE, JBatch Implementation =
> > > > >
> > > > > === Abstract ===
> > > > >
> > > > > BatchEE will be an ASL-licensed implementation of the JBatch
> > > > Specification
> > > > > which is defined as JSR-352 (for version 1.0).
> > > > >
> > > > > === Proposal ===
> > > > >
> > > > > BatchEE specification is an effort for defining a standard API and
> > way
> > > to
> > > > > write batches in Java. It is integrated with JavaEE (JTA, CDI)
> > but
> > > > > works out of the box in a standalone environment.
> > > > >
> > > > >
> > > > > BatchEE Project is responsible for implementing the runtime
> container
> > > > > contract for the JBatch specification. Besides the implementation,
> > > > BatchEE
> > > > > Project will implement the core built-in components that further
> > > > simplifies
> > > > > the developer complex interactions with other Java EE specific
> > > enterprise
> > > > > operations. For example, it will define default
> > reader/processor/writer
> > > > for
> > > > > jdbc, jpa, xml/json/flat files...
> > > > >
> > > > > === Background ===
> > > > >
> > > > > Until today writing batches in java meant using a proprietary
> > framework
> > > > and
> > > > > link to JavaEE was quite limited (or missing). JBatch defines an
> API
> > > > fixing
> > > > > this issue and now developpers need a fix.
> > > > >
> > > > > === Rationale ===
> > > > >
> > > > > Current JBatch specificatin is released, and only the reference
> > > > > implementation is available but not really intended to be
> maintained.
> > > > > Moreover multiple Apache projects (geronimo, TomEE, ...) will need
> an
> > > > > Apache compatible Jbatch implementation to go ahread and implement
> > > > JavaEE 7.
> > > > >
> > > > >
> > > > > === Initial Goals ===
> > > > >
> > > > > The initial goals of the BatchEE Project are
> > > > >
> > > > > * Fully implement the JSR-352 specification.
> > > > > * Attracts a community around the current code base.
> > > > > * Active relationship with the other dependent projects to further
> > > > develop
> > > > > some useful batch components.
> > > > >
> > > > > == Current Status ==
> > > > >
> > > > > === Meritocracy ===
> > > > >
> > > > > Initial developer of the project is familiar with the meritocracy
> > > > > principles of Apache. He knows that the open source gets power from
> > its
> > > > > great developers and freedom. He also developed some other open
> > source
> > > > > projects. We will follow the normal meritocracy rules also with
> other
> > > > > potential contributors.
> > > > >
> > > > > === Community ===
> > > > >
> > > > > There is a great community within the OpenEJB, OpenWebBeans,
> Geronimo
> > > and
> > > > > TomEE Apache projects. BatchEE project is very related with these
> > > > projects
> > > > > and in the some cases, it enhances these projects. We are thinking
> > that
> > > > > BatchEE project gets strong community because it complete the
> needed
> > > > > frameworks of a java developper and unifies the using of these
> > > projects.
> > > > It
> > > > > simplifies the developer effort for building complex enterprise
> > > > > applications batches.
> > > > >
> > > > > === Core Developers ===
> > > > >
> > > > > BatchEE project has been developing by the IBM then forked by
> Romain
> > > > > Manni-Bucau as a sole contributor.
> > > > >
> > > > > === Alignment ===
> > > > >
> > > > > BacthEE project will be a candidate for us

[RESULT][VOTE] BatchEE as an incubated project

[Romain Manni-Bucau]

The vote for BatchEE to become an incubated project has passed with 9 +1
binding votes, 3 +1 non-binding votes, and no -1 or 0 votes.

*Binding +1 Votes:*
Olivier Lamy
Bertrand Delacretaz
Jean-Baptiste Onofré
Christian Müller
Matt Benson
Mark Struberg
Matthias Wessendorf
Gerhard Petracek
Tammo van Lessen


*Non-Binding +1 Votes:*
Rahul Sharma
Jean-Louis Monteiro
Romain Manni-Bucau

Congrats to all involved!


Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau

Re: [ANNOUNCE] Christian Müller joins the IPMC

[Christian Müller]

Thanks for the warm welcome. Because I'm a newbie here, be aware of stupid
questions... ;-)

Best,
Christian
Am 03.10.2013 08:02 schrieb "Romain Manni-Bucau" :

> Congrats!
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau *
> *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/10/3 Jean-Louis MONTEIRO 
>
> > Congrats Christian.
> >
> > Jean Louis
> > Le 3 oct. 2013 01:20, "Marvin Humphrey"  a
> écrit :
> >
> > > Apache Member and Apache Camel PMC Chair Christian Müller has joined
> > > the Incubator PMC.
> > >
> > > Welcome!
> > >
> > > Marvin Humphrey
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > >
> >
>

Re: [ANNOUNCE] Christian Müller joins the IPMC

[Mohammad Nour El-Din]

Congrats! :)


On Thu, Oct 3, 2013 at 11:49 AM, Christian Müller <
christian.muel...@gmail.com> wrote:

> Thanks for the warm welcome. Because I'm a newbie here, be aware of stupid
> questions... ;-)
>
> Best,
> Christian
> Am 03.10.2013 08:02 schrieb "Romain Manni-Bucau" :
>
> > Congrats!
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau *
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/10/3 Jean-Louis MONTEIRO 
> >
> > > Congrats Christian.
> > >
> > > Jean Louis
> > > Le 3 oct. 2013 01:20, "Marvin Humphrey"  a
> > écrit :
> > >
> > > > Apache Member and Apache Camel PMC Chair Christian Müller has joined
> > > > the Incubator PMC.
> > > >
> > > > Welcome!
> > > >
> > > > Marvin Humphrey
> > > >
> > > > -
> > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > > For additional commands, e-mail: general-h...@incubator.apache.org
> > > >
> > > >
> > >
> >
>



-- 
Thanks
- Mohammad Nour

"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein

Re: [VOTE] Retire the Tashi podling

[Olivier Lamy]

+1

On 3 October 2013 09:45, Marvin Humphrey  wrote:
> Greets,
>
> As discussed previously on general@incubator[1], the Tashi community has voted
> to retire from the Incubator.  Following the retirement guide[2], it is now
> time for an IPMC vote ratifying their decision.
>
>  [ ] +1 Retire the Tashi podling
>  [ ] +0 Neither here nor there
>  [ ] -1 Do not retire the podling because ...
>
> This vote will remain open for at least the next 72 hours.
>
> Here is my +1.
>
> Marvin Humphrey
>
> [1] http://s.apache.org/G1S
> [2] http://incubator.apache.org/guides/retirement.html
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] [PROPOSAL] Apache Monitoring

[Olivier Lamy]

Sounds good for me too.


On 2 October 2013 18:19, Mark Struberg  wrote:
> -1 for Merlin. Just too widely used :(
> There are 10++ pages of trademarks in all fields in trademarkia, many of them 
> in the software area
>
>
>
> +1 for Sirona as it has a nice meaning and it seems to not be used for any 
> software related product so far.
>
> LieGrue,
> strub
>
>
>
>
> - Original Message -
>> From: Jean-Baptiste Onofré 
>> To: general@incubator.apache.org
>> Cc:
>> Sent: Wednesday, 2 October 2013, 8:46
>> Subject: Re: [DISCUSS] [PROPOSAL] Apache Monitoring
>>
>> +1
>>
>> Regards
>> JB
>>
>> On 10/02/2013 01:01 AM, Olivier Lamy wrote:
>>>  So Apache Merlin sounds good to me.
>>>  Any objections?
>>>
>>>  On 25 September 2013 23:47, Christian Grobmeier 
>> wrote:
  Nechtan sounds cool also. Please note, in the german wikipedia its
  translated with "The tremendousness". This is not noted on
>> the english
  wikipedia. After reading wikipedia I am still not sure what Nechtan
>> stands
  for. But I like its sound.

  I just found "Sirona", goddess of healing. Because monitoring
>> is
  "identifying the sickness before its getting worse". However,
>> Sirona is used
  by companies related to healing (aka dental works).

  What I found interesting is this page claims Merlin being a god:
  http://wicca.com/celtic/wicca/celtic.htm
  of protecting, counseling, crystal reading and so.

  A few projects use Merlin, but all are very small ant not related to
  monitoring.
  There is a project management software called marlin:
  http://www.projectwizards.net/de/merlin/

  I believe we currently have:

  Apache Leitstand
  Apache Nechtan
  Apache Merlin
  Apache Sirona
  Apache Heimdall
  Apache Dagr

  Cheers



  On 25 Sep 2013, at 15:03, Stephen Connolly wrote:

>  Why not try Celtic mythology I was thinking "Apache
>> Nechtan" due to
>  the
>  association with access to knowledge and floods... but heck I am
>> not good
>  on my Irish mythology and the Norse ones always sounded way cooler
>
>
>  On 25 September 2013 13:23, Christian Grobmeier
>> 
>  wrote:
>
>>  I also see thor is being used by infra:
>>  status.apache.org
>>
>>  (mentioning, because it has been proposed as name too).
>>
>>  However, it's not so bad. I actually mixed up Baldur with
>> Heimdall, who
>>  is
>>  the actual "protector" of Bifröst. Baldur was more
>> known because he was
>>  able to return from Hel (sounds like a good name for a server
>> ;-)
>>  A quick crosscheck told me Heimdall is not used that often.
>>
>>  For those who were concerned about using nordic godnames:
>> Heimdall was
>>  named as the "father of all humans".
>>
>>  He was also known for his horn Gjallarhorn which he blew when
>> danger
>>  appeared. Most notable he blew that horn when Ragnarökr (the
>> end of our
>>  time and the fall of the gods) starts.
>>
>>  I imagine the sound of a horn when critical notification of the
>> tool
>>  happens ;-)
>>
>>  Another idea i just had was "Dagr". It old norsk for
>> "Day". In old myths
>>  Dagr is the son of night and he rides his horse Skinfaxi
>> through heaven.
>>  The crest of the horse lights the earth with golden shimmer. I
>> imagine
>>  Apache Dagr to shed light on the dark corners of our
>> applications.
>>
>>
>>  Heck, when I was young i read a lot about northern mythology.
>> Its so
>>  poetic. I should spend some time to read again.
>>
>>
>>
>>
>>
>>
>>
>>  On 25 Sep 2013, at 10:19, Daniel Gruno wrote:
>>
>>  On 09/25/2013 09:21 AM, Tammo van Lessen wrote:
>>>
>>>
  Baldr is fine with me, my only concern is the
>> similarity to Apache
  Buildr.

>>>
>>>  Just a heads up from infra; baldr.apache.org is already
>> very much a
>>>  thing, and has been for more than five years. If it can be
>> avoided, we'd
>>>  really appreciate it if we can keep the name Baldr for our
>>>  infrastructure.
>>>
>>>  With regards,
>>>  Daniel.
>>>
>>>
  Tammo
  Am 25.09.2013 01:18 schrieb "Olivier Lamy"
>> :

  So what about Baldr?
>
>  BTW we can start incubation using Monitoring then
>> change the name for
>  TLP?
>  WDYT?
>
>  On 21 September 2013 06:30, Christian Grobmeier
>> 
>  wrote:
>
>>  I would like to throw in this document:
>>
>>
>> http://www.apache.org/**foundation/marks/naming.html
>>
>>  We should make a few tests already before we
>> start the process
>>
>  officially.
>
>>
>>  here is the current list

Re: [DISCUSS] [PROPOSAL] Apache Monitoring

[Romain Manni-Bucau]

works for me too

*Romain Manni-Bucau*
*Twitter: @rmannibucau *
*Blog: **http://rmannibucau.wordpress.com/*
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/10/3 Olivier Lamy 

> Sounds good for me too.
>
>
> On 2 October 2013 18:19, Mark Struberg  wrote:
> > -1 for Merlin. Just too widely used :(
> > There are 10++ pages of trademarks in all fields in trademarkia, many of
> them in the software area
> >
> >
> >
> > +1 for Sirona as it has a nice meaning and it seems to not be used for
> any software related product so far.
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> > - Original Message -
> >> From: Jean-Baptiste Onofré 
> >> To: general@incubator.apache.org
> >> Cc:
> >> Sent: Wednesday, 2 October 2013, 8:46
> >> Subject: Re: [DISCUSS] [PROPOSAL] Apache Monitoring
> >>
> >> +1
> >>
> >> Regards
> >> JB
> >>
> >> On 10/02/2013 01:01 AM, Olivier Lamy wrote:
> >>>  So Apache Merlin sounds good to me.
> >>>  Any objections?
> >>>
> >>>  On 25 September 2013 23:47, Christian Grobmeier 
> >> wrote:
>   Nechtan sounds cool also. Please note, in the german wikipedia its
>   translated with "The tremendousness". This is not noted on
> >> the english
>   wikipedia. After reading wikipedia I am still not sure what Nechtan
> >> stands
>   for. But I like its sound.
> 
>   I just found "Sirona", goddess of healing. Because monitoring
> >> is
>   "identifying the sickness before its getting worse". However,
> >> Sirona is used
>   by companies related to healing (aka dental works).
> 
>   What I found interesting is this page claims Merlin being a god:
>   http://wicca.com/celtic/wicca/celtic.htm
>   of protecting, counseling, crystal reading and so.
> 
>   A few projects use Merlin, but all are very small ant not related to
>   monitoring.
>   There is a project management software called marlin:
>   http://www.projectwizards.net/de/merlin/
> 
>   I believe we currently have:
> 
>   Apache Leitstand
>   Apache Nechtan
>   Apache Merlin
>   Apache Sirona
>   Apache Heimdall
>   Apache Dagr
> 
>   Cheers
> 
> 
> 
>   On 25 Sep 2013, at 15:03, Stephen Connolly wrote:
> 
> >  Why not try Celtic mythology I was thinking "Apache
> >> Nechtan" due to
> >  the
> >  association with access to knowledge and floods... but heck I am
> >> not good
> >  on my Irish mythology and the Norse ones always sounded way cooler
> >
> >
> >  On 25 September 2013 13:23, Christian Grobmeier
> >> 
> >  wrote:
> >
> >>  I also see thor is being used by infra:
> >>  status.apache.org
> >>
> >>  (mentioning, because it has been proposed as name too).
> >>
> >>  However, it's not so bad. I actually mixed up Baldur with
> >> Heimdall, who
> >>  is
> >>  the actual "protector" of Bifröst. Baldur was more
> >> known because he was
> >>  able to return from Hel (sounds like a good name for a server
> >> ;-)
> >>  A quick crosscheck told me Heimdall is not used that often.
> >>
> >>  For those who were concerned about using nordic godnames:
> >> Heimdall was
> >>  named as the "father of all humans".
> >>
> >>  He was also known for his horn Gjallarhorn which he blew when
> >> danger
> >>  appeared. Most notable he blew that horn when Ragnarökr (the
> >> end of our
> >>  time and the fall of the gods) starts.
> >>
> >>  I imagine the sound of a horn when critical notification of the
> >> tool
> >>  happens ;-)
> >>
> >>  Another idea i just had was "Dagr". It old norsk for
> >> "Day". In old myths
> >>  Dagr is the son of night and he rides his horse Skinfaxi
> >> through heaven.
> >>  The crest of the horse lights the earth with golden shimmer. I
> >> imagine
> >>  Apache Dagr to shed light on the dark corners of our
> >> applications.
> >>
> >>
> >>  Heck, when I was young i read a lot about northern mythology.
> >> Its so
> >>  poetic. I should spend some time to read again.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>  On 25 Sep 2013, at 10:19, Daniel Gruno wrote:
> >>
> >>  On 09/25/2013 09:21 AM, Tammo van Lessen wrote:
> >>>
> >>>
>   Baldr is fine with me, my only concern is the
> >> similarity to Apache
>   Buildr.
> 
> >>>
> >>>  Just a heads up from infra; baldr.apache.org is already
> >> very much a
> >>>  thing, and has been for more than five years. If it can be
> >> avoided, we'd
> >>>  really appreciate it if we can keep the name Baldr for our
> >>>  infrastructure.
> >>>
> >>>  With regards,
> >>>  Daniel.
> >>>
> >>>
>   Tammo
>   Am 25.09.2013 01:18 schrieb "Olivier Lamy"
> >> :
> 
>   So

Re: [DISCUSS] [PROPOSAL] Apache Monitoring

[Jean-Louis MONTEIRO]

No problem, that sounds good as well.

JLouis


2013/10/3 Romain Manni-Bucau 

> works for me too
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau *
> *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/10/3 Olivier Lamy 
>
> > Sounds good for me too.
> >
> >
> > On 2 October 2013 18:19, Mark Struberg  wrote:
> > > -1 for Merlin. Just too widely used :(
> > > There are 10++ pages of trademarks in all fields in trademarkia, many
> of
> > them in the software area
> > >
> > >
> > >
> > > +1 for Sirona as it has a nice meaning and it seems to not be used for
> > any software related product so far.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >
> > >
> > > - Original Message -
> > >> From: Jean-Baptiste Onofré 
> > >> To: general@incubator.apache.org
> > >> Cc:
> > >> Sent: Wednesday, 2 October 2013, 8:46
> > >> Subject: Re: [DISCUSS] [PROPOSAL] Apache Monitoring
> > >>
> > >> +1
> > >>
> > >> Regards
> > >> JB
> > >>
> > >> On 10/02/2013 01:01 AM, Olivier Lamy wrote:
> > >>>  So Apache Merlin sounds good to me.
> > >>>  Any objections?
> > >>>
> > >>>  On 25 September 2013 23:47, Christian Grobmeier <
> grobme...@gmail.com>
> > >> wrote:
> >   Nechtan sounds cool also. Please note, in the german wikipedia its
> >   translated with "The tremendousness". This is not noted on
> > >> the english
> >   wikipedia. After reading wikipedia I am still not sure what Nechtan
> > >> stands
> >   for. But I like its sound.
> > 
> >   I just found "Sirona", goddess of healing. Because monitoring
> > >> is
> >   "identifying the sickness before its getting worse". However,
> > >> Sirona is used
> >   by companies related to healing (aka dental works).
> > 
> >   What I found interesting is this page claims Merlin being a god:
> >   http://wicca.com/celtic/wicca/celtic.htm
> >   of protecting, counseling, crystal reading and so.
> > 
> >   A few projects use Merlin, but all are very small ant not related
> to
> >   monitoring.
> >   There is a project management software called marlin:
> >   http://www.projectwizards.net/de/merlin/
> > 
> >   I believe we currently have:
> > 
> >   Apache Leitstand
> >   Apache Nechtan
> >   Apache Merlin
> >   Apache Sirona
> >   Apache Heimdall
> >   Apache Dagr
> > 
> >   Cheers
> > 
> > 
> > 
> >   On 25 Sep 2013, at 15:03, Stephen Connolly wrote:
> > 
> > >  Why not try Celtic mythology I was thinking "Apache
> > >> Nechtan" due to
> > >  the
> > >  association with access to knowledge and floods... but heck I am
> > >> not good
> > >  on my Irish mythology and the Norse ones always sounded way cooler
> > >
> > >
> > >  On 25 September 2013 13:23, Christian Grobmeier
> > >> 
> > >  wrote:
> > >
> > >>  I also see thor is being used by infra:
> > >>  status.apache.org
> > >>
> > >>  (mentioning, because it has been proposed as name too).
> > >>
> > >>  However, it's not so bad. I actually mixed up Baldur with
> > >> Heimdall, who
> > >>  is
> > >>  the actual "protector" of Bifröst. Baldur was more
> > >> known because he was
> > >>  able to return from Hel (sounds like a good name for a server
> > >> ;-)
> > >>  A quick crosscheck told me Heimdall is not used that often.
> > >>
> > >>  For those who were concerned about using nordic godnames:
> > >> Heimdall was
> > >>  named as the "father of all humans".
> > >>
> > >>  He was also known for his horn Gjallarhorn which he blew when
> > >> danger
> > >>  appeared. Most notable he blew that horn when Ragnarökr (the
> > >> end of our
> > >>  time and the fall of the gods) starts.
> > >>
> > >>  I imagine the sound of a horn when critical notification of the
> > >> tool
> > >>  happens ;-)
> > >>
> > >>  Another idea i just had was "Dagr". It old norsk for
> > >> "Day". In old myths
> > >>  Dagr is the son of night and he rides his horse Skinfaxi
> > >> through heaven.
> > >>  The crest of the horse lights the earth with golden shimmer. I
> > >> imagine
> > >>  Apache Dagr to shed light on the dark corners of our
> > >> applications.
> > >>
> > >>
> > >>  Heck, when I was young i read a lot about northern mythology.
> > >> Its so
> > >>  poetic. I should spend some time to read again.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>  On 25 Sep 2013, at 10:19, Daniel Gruno wrote:
> > >>
> > >>  On 09/25/2013 09:21 AM, Tammo van Lessen wrote:
> > >>>
> > >>>
> >   Baldr is fine with me, my only concern is the
> > >> similarity to Apache
> >   Buildr.
> > 
> > >>>
> > >>>  Just a heads up fro

[RESULT][VOTE] Release Apache Marmotta 3.1.0-incubating

[Sebastian Schaffert]

Dear all,

thanks for your support! The 72 hours have now passed and we have 8
positive votes, of which 3 are binding and 5 are non-binding. We now have
the required number of positive binding votes and will therefore proceed
with the release.

The remark by sebb has been added as an issue for the next release
(MARMOTTA-327).

Greetings,

Sebastian


2013/10/2 Olivier Lamy 

> +1 sources build fine.
>
> --
> Olivier
> On Sep 30, 2013 8:17 PM, "Sebastian Schaffert" 
> wrote:
>
> > Dear all,
> >
> > After several months of work since the last incubating release
> > (3.0.0-incubating) in April, we are now ready to release version
> > 3.1.0-incubating. We fixed all the remaining issues that have been
> > discussed in April (see thread [1]) plus many more technical issues. We
> > have already held a vote that was open for more than 72 hours on the
> Apache
> > Marmotta developer mailinglist [2]. The vote concluded [3] with 7
> positive
> > votes, of which 2 have been binding from IPMC members (Andy and Nandana)
> > and the remaining 5 from the Apache Marmotta developers.
> >
> > I'd therefore like to ask the general incubator to check our release
> > candidate. The release notes are available at the Jira Issue Tracker [4].
> > The vote form is included at the bottom of this mail.
> >
> > Greetings,
> >
> > Sebastian
> >
> >
> > [1] http://apache.markmail.org/message/5tieelmeevi2j6xb
> > [2] http://apache.markmail.org/message/lk3hc3jutoaxp6dr
> > [3] http://apache.markmail.org/message/fvytzho2pnhasw2c
> > [4]
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314321&version=12324026
> >
> > ===
> > A candidate for the Marmotta 3.1.0-incubating release is available at:
> >
> >
> https://dist.apache.org/repos/dist/dev/incubator/marmotta/3.1.0-incubating/
> >
> > The release candidate is based on the sources tagged with
> 3.1.0-incubating
> > in:
> >
> > https://git-wip-us.apache.org/repos/asf/incubator-marmotta.git
> >
> > The release candidate consists of the following source distribution
> > archives:
> > - apache-marmotta-3.1.0-
> > incubating-src.[zip|tar.gz]
> >   SHA1 of ZIP: 763c39dc9d7eb1c7d8fad83742b08f44b6fa5527
> >   SHA1 of TGZ: 0f7f3395f22aeeaa4a402f1b08048c84899d9729
> >
> > In addition, the following supplementary binary distributions are
> provided:
> > - apache-marmotta-3.1.0-incubating-installer.[zip|tar.gz]
> >   SHA1 of ZIP: d7417a711a7f80eb29eb93ec75744a314fcf2edd
> >   SHA1 of TGZ: 4606fe743f607215dd4f3f39d8506852f529b617
> > - apache-marmotta-3.1.0-incubating-ldpath.[zip|tar.gz]
> >   SHA1 of ZIP: 4f4db937e0064a4393039b6fb8277be166a971ab
> >   SHA1 of TGZ: 5d63f972df2306afec96aa1a8931c4d0dabb2f75
> > - apache-marmotta-3.1.0-incubating-webapp.[zip|tar.gz]
> >   SHA1 of ZIP: e8e168a29e398cda9220a793958b825a906a3142
> >   SHA1 of TGZ: 80d022d316e727b5f011069eec6dc9793b174838
> >
> > A staged Maven repository is available for review at:
> >
> >
> https://repository.apache.org/content/repositories/orgapachemarmotta-092/
> >
> > Please vote on releasing this package as Apache Marmotta
> 3.1.0-incubating.
> > The vote is open for the next 72 hours and passes if a majority of at
> > least three +1 Marmotta PMC votes are cast.
> >
> > [ ] +1 Release this package as Apache Marmotta 3.1.0-incubating
> > [ ]  0 I don't feel strongly about it, but I'm okay with the release
> > [ ] -1 Do not release this package because...
> >
> > ===
> >
> > Release Notes - Marmotta - Version 3.1-incubating
> >
> > ** Sub-task
> > * [MARMOTTA-216] - Implement JOIN improvements
> > * [MARMOTTA-217] - Implement FILTER improvements
> > * [MARMOTTA-218] - Integrate in marmotta-sparql
> >
> >
> > ** Bug
> > * [MARMOTTA-28] - Implement tests for core that take into account
> > triple store changes
> > * [MARMOTTA-63] - Triplestore: garbage collector for nodes currently
> > not working properly
> > * [MARMOTTA-66] - Rework sesame-commons ResourceUtils
> > * [MARMOTTA-143] - unable to import big files
> > * [MARMOTTA-150] - BNodes are a dead end in the Linked Data Explorer
> > * [MARMOTTA-154] - Youtube video provider doesn't fetch the keywords
> > * [MARMOTTA-155] - 3-char lang-tags are not accepted
> > * [MARMOTTA-156] - Add Logback configuration to all tests to
> > enable/disable debug logging
> > * [MARMOTTA-170] - file-store (meta) for ldcache-backend-file
> contains
> > wrong comments
> > * [MARMOTTA-171] - remove legacy subdirs from src/main/webapp in
> > marmotta-webapp
> > * [MARMOTTA-186] - LDPath parser fails on local names that contain
> '.'
> > * [MARMOTTA-187] - ldpath extension for CM does not recognize local
> > names with '.' or '-'
> > * [MARMOTTA-191] - SPARQL graph results fails under some
> circunstances
> > * [MARMOTTA-197] - ldpath is loosing brackets on re-serialisation
> > * [MARMOTTA-204] - Update to Sesa

Re: [DISCUSS] [PROPOSAL] Apache Monitoring

[Jean-Baptiste Onofré]

It works for me.

Regards
JB

On 10/02/2013 10:19 AM, Mark Struberg wrote:

-1 for Merlin. Just too widely used :(
There are 10++ pages of trademarks in all fields in trademarkia, many of them 
in the software area



+1 for Sirona as it has a nice meaning and it seems to not be used for any 
software related product so far.

LieGrue,
strub




- Original Message -

From: Jean-Baptiste Onofré 
To: general@incubator.apache.org
Cc:
Sent: Wednesday, 2 October 2013, 8:46
Subject: Re: [DISCUSS] [PROPOSAL] Apache Monitoring

+1

Regards
JB

On 10/02/2013 01:01 AM, Olivier Lamy wrote:

  So Apache Merlin sounds good to me.
  Any objections?

  On 25 September 2013 23:47, Christian Grobmeier 

wrote:

  Nechtan sounds cool also. Please note, in the german wikipedia its
  translated with "The tremendousness". This is not noted on

the english

  wikipedia. After reading wikipedia I am still not sure what Nechtan

stands

  for. But I like its sound.

  I just found "Sirona", goddess of healing. Because monitoring

is

  "identifying the sickness before its getting worse". However,

Sirona is used

  by companies related to healing (aka dental works).

  What I found interesting is this page claims Merlin being a god:
  http://wicca.com/celtic/wicca/celtic.htm
  of protecting, counseling, crystal reading and so.

  A few projects use Merlin, but all are very small ant not related to
  monitoring.
  There is a project management software called marlin:
  http://www.projectwizards.net/de/merlin/

  I believe we currently have:

  Apache Leitstand
  Apache Nechtan
  Apache Merlin
  Apache Sirona
  Apache Heimdall
  Apache Dagr

  Cheers



  On 25 Sep 2013, at 15:03, Stephen Connolly wrote:


  Why not try Celtic mythology I was thinking "Apache

Nechtan" due to

  the
  association with access to knowledge and floods... but heck I am

not good

  on my Irish mythology and the Norse ones always sounded way cooler


  On 25 September 2013 13:23, Christian Grobmeier



  wrote:


  I also see thor is being used by infra:
  status.apache.org

  (mentioning, because it has been proposed as name too).

  However, it's not so bad. I actually mixed up Baldur with

Heimdall, who

  is
  the actual "protector" of Bifröst. Baldur was more

known because he was

  able to return from Hel (sounds like a good name for a server

;-)

  A quick crosscheck told me Heimdall is not used that often.

  For those who were concerned about using nordic godnames:

Heimdall was

  named as the "father of all humans".

  He was also known for his horn Gjallarhorn which he blew when

danger

  appeared. Most notable he blew that horn when Ragnarökr (the

end of our

  time and the fall of the gods) starts.

  I imagine the sound of a horn when critical notification of the

tool

  happens ;-)

  Another idea i just had was "Dagr". It old norsk for

"Day". In old myths

  Dagr is the son of night and he rides his horse Skinfaxi

through heaven.

  The crest of the horse lights the earth with golden shimmer. I

imagine

  Apache Dagr to shed light on the dark corners of our

applications.



  Heck, when I was young i read a lot about northern mythology.

Its so

  poetic. I should spend some time to read again.







  On 25 Sep 2013, at 10:19, Daniel Gruno wrote:

  On 09/25/2013 09:21 AM, Tammo van Lessen wrote:




  Baldr is fine with me, my only concern is the

similarity to Apache

  Buildr.



  Just a heads up from infra; baldr.apache.org is already

very much a

  thing, and has been for more than five years. If it can be

avoided, we'd

  really appreciate it if we can keep the name Baldr for our
  infrastructure.

  With regards,
  Daniel.



  Tammo
  Am 25.09.2013 01:18 schrieb "Olivier Lamy"

:


  So what about Baldr?


  BTW we can start incubation using Monitoring then

change the name for

  TLP?
  WDYT?

  On 21 September 2013 06:30, Christian Grobmeier



  wrote:


  I would like to throw in this document:



http://www.apache.org/**foundation/marks/naming.html


  We should make a few tests already before we

start the process



  officially.



  here is the current list, i felt so free to add

a few comments

  already.

  - CoMon
  There is "Common Software", a

company. We might have a trademarks

  problem because of similarity.

  - Leitstand
  Not sure if I like the sound :-), but did not

find any repositories

  at
  github. From the meaning, a Leitstand is

usually something were you

  can
  adjust things (more power, less steam and so

on). Monitoring would be

  only a part of it. But on the other hand, it

expresses things well

  and
  it is a unused word so far.

  - Thor
  Great name, great god, but unfortunately a lot

of people use that

  name
  for their code :-(

  - Balder / Baldur, also possible: Baldr
  I haven't see a lot with that name, but we

need to check this more in

  detail.

   From that perspective, Leitstand would be the

Re: Apache project bylaws

[Marvin Humphrey]

On Thu, Oct 3, 2013 at 12:09 AM, Alex Harui  wrote:
> On 10/2/13 12:58 PM, "Marvin Humphrey"  wrote:

>> Rather than a "rewrite", I suggest proposing small, incremental, reversible
>> changes.  Governance is easy to mess up.
>
> Well, "small, incremental" was hard to do given the significantly
> different information this document must now convey.

I appreciate the labor you've put in, but what we have here is akin to a
big patch on highly sensitive mission-critical code for which there are no
tests.  I hope we can find a less costly way to integrate your efforts.

> I tried to keep as
> much as possible yet incorporate feedback from Doug and Roy.

Even if it was "wrong", people have been quoting from that document,
referencing it and following its guidance for a long time.  I'm quite
irritated that something "wrong" has persisted for so long and has been used
so many times as the basis for settling disputes.

My take is that if that fundamental a document is "wrong", something is
dreadfully "wrong" with how hard-won wisdom gets handed down at the ASF.

Let's step back for a moment and reassess what we're trying to accomplish.
We're starting with a voting document which is apparently "wrong" and trying
to make it quasi-authoritative.  But when we're finished turd polishing, there
will still be no boundaries demarcating where the authoritative stuff begins
and ends.

We have this problem with the Incubator website, too.  It started off with
buckets of poorly-thought-through text scooped out of mailing lists and dumped
into version control.  Years later, certain portions of it have been carefully
wordsmithed or even negotiated under high heat; as a result, making a minor
change has the potential to obliterate a great deal of other people's hard
work.  But from just looking at the surface, you can't tell what's garbage and
what's crucial.

Personally, I'm not eager to spend a lot of cycles negotiating large revisions
to highly-utilized governance documentation under such a flawed regime.  I'd
rather that we limit ourselves to small tweaks, or if we're going to go all
out, draw up a set of default bylaws which will in the future be set off from
other documentation and subject to review-then-commit by some governing body
charged with oversight.

> Below is my
> proposed version, and below it is the svn diff in case that makes it
> easier to see what changed.  Most of the changes were made at the
> beginning.

The formatting of the diff is messed up because of line wrapping by your email
client.  Please take the time to present such a costly-to-review patch in a
way which accommodates your potential reviewers.  I suggest posting a link to
a persistent paste created using .

Marvin Humphrey

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Retire the Tashi podling

[Matt Franklin]

+1


On Wed, Oct 2, 2013 at 7:45 PM, Marvin Humphrey wrote:

> Greets,
>
> As discussed previously on general@incubator[1], the Tashi community has
> voted
> to retire from the Incubator.  Following the retirement guide[2], it is now
> time for an IPMC vote ratifying their decision.
>
>  [ ] +1 Retire the Tashi podling
>  [ ] +0 Neither here nor there
>  [ ] -1 Do not retire the podling because ...
>
> This vote will remain open for at least the next 72 hours.
>
> Here is my +1.
>
> Marvin Humphrey
>
> [1] http://s.apache.org/G1S
> [2] http://incubator.apache.org/guides/retirement.html
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Retire the Tashi podling

[Alan D. Cabrera]

+1

Regards,
Alan

On Oct 2, 2013, at 4:45 PM, Marvin Humphrey  wrote:

> [ ] +1 Retire the Tashi podling
> [ ] +0 Neither here nor there
> [ ] -1 Do not retire the podling because ...

Re: [VOTE] Retire the Tashi podling

[Mark Struberg]

+1

LieGrue,
strub





>
> From: Alan D. Cabrera 
>To: general@incubator.apache.org 
>Sent: Thursday, 3 October 2013, 16:34
>Subject: Re: [VOTE] Retire the Tashi podling
> 
>
>+1
>
>Regards,
>Alan
>
>On Oct 2, 2013, at 4:45 PM, Marvin Humphrey  wrote:
>
>> [ ] +1 Retire the Tashi podling
>> [ ] +0 Neither here nor there
>> [ ] -1 Do not retire the podling because ...
>
>
>
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Apache project bylaws

[Alex Harui]

On 10/3/13 6:23 AM, "Marvin Humphrey"  wrote:

>On Thu, Oct 3, 2013 at 12:09 AM, Alex Harui  wrote:
>> On 10/2/13 12:58 PM, "Marvin Humphrey"  wrote:
>
>>> Rather than a "rewrite", I suggest proposing small, incremental,
>>>reversible
>>> changes.  Governance is easy to mess up.
>>
>> Well, "small, incremental" was hard to do given the significantly
>> different information this document must now convey.
>
>I appreciate the labor you've put in, but what we have here is akin to a
>big patch on highly sensitive mission-critical code for which there are no
>tests.  I hope we can find a less costly way to integrate your efforts.
It is a big patch for sure, but I'm not sure I agree with equating it to
code.  It is probably always going to be "just words" and I'm not sure you
can create tests.  I think even laws don't have tests, they only have to
survive the reviews of the approvers and are always subject to revision
later.  But hopefully the reviewers will think through whether the things
they thought were "right" about the old version are retained and whether
the things that were "wrong" have been removed, and new content appears to
be "right".
 
>
>> I tried to keep as
>> much as possible yet incorporate feedback from Doug and Roy.
>
>Even if it was "wrong", people have been quoting from that document,
>referencing it and following its guidance for a long time.  I'm quite
>irritated that something "wrong" has persisted for so long and has been
>used
>so many times as the basis for settling disputes.
>
>My take is that if that fundamental a document is "wrong", something is
>dreadfully "wrong" with how hard-won wisdom gets handed down at the ASF.
>
>Let's step back for a moment and reassess what we're trying to accomplish.
>We're starting with a voting document which is apparently "wrong" and
>trying
>to make it quasi-authoritative.  But when we're finished turd polishing,
>there
>will still be no boundaries demarcating where the authoritative stuff
>begins
>and ends.
>
>We have this problem with the Incubator website, too.  It started off with
>buckets of poorly-thought-through text scooped out of mailing lists and
>dumped
>into version control.  Years later, certain portions of it have been
>carefully
>wordsmithed or even negotiated under high heat; as a result, making a
>minor
>change has the potential to obliterate a great deal of other people's hard
>work.  But from just looking at the surface, you can't tell what's
>garbage and
>what's crucial.
>
>Personally, I'm not eager to spend a lot of cycles negotiating large
>revisions
>to highly-utilized governance documentation under such a flawed regime.
>I'd
>rather that we limit ourselves to small tweaks, or if we're going to go
>all
>out, draw up a set of default bylaws which will in the future be set off
>from
>other documentation and subject to review-then-commit by some governing
>body
>charged with oversight.
Some good points in there.  I know you want to revise the incubator site
and I wish you well on your efforts to do so because I agree it needs it.,
However I just want to change this one document, and it shouldn't require
the restructuring of a site, so I want to separate the two efforts,
although maybe this effort will influence yours.

So how about this:  I will go all out and rewrite this one document so it
will demarcate what is authoritative and what isn't.  And I will try to
make it clear that the goal of the document is to define a set of default
by-laws.  And I will retain the entirety of the old document for
historical reference.  To do so, I will insert the rewrite at the
beginning of the document after I get lazy consensus on the following text
which will go at the very beginning.

This document is under revision.  The original can be found here
(#link_to_original_further_down).  All decision based on the
original document remain valid and the original document remains
valid until further notice.  The text color of the original
document has been changed to (brown) to help delineate the
boundaries of the original content.

All authoritative sections will be demarcated with:

--this section is authoritative--

And end with:

--end of authoritative section--

My understanding is that only the code-modification and release voting
approval type is authoritative.  Please correct me if I'm wrong.


>
>> Below is my
>> proposed version, and below it is the svn diff in case that makes it
>> easier to see what changed.  Most of the changes were made at the
>> beginning.
>
>The formatting of the diff is messed up because of line wrapping by your
>email
>client.  Please take the time to present such a costly-to-review patch in
>a
>way which accommodates your potential reviewers.  I suggest posting a
>link to
>a persistent paste created using .
And with the above disclaimer, instead of using paste.a.o, I propose to
revise this document using CMS and/or SVN.  T

Re: Apache project bylaws

[Joseph Schaefer]

Good Lord man all you need to add is a one-sentence
statement that personnel votes are consensus votes not
procedural (simple majority) votes.

On Oct 3, 2013, at 11:40 AM, Alex Harui  wrote:

> 
> 
> On 10/3/13 6:23 AM, "Marvin Humphrey"  wrote:
> 
>> On Thu, Oct 3, 2013 at 12:09 AM, Alex Harui  wrote:
>>> On 10/2/13 12:58 PM, "Marvin Humphrey"  wrote:
>> 
 Rather than a "rewrite", I suggest proposing small, incremental,
 reversible
 changes.  Governance is easy to mess up.
>>> 
>>> Well, "small, incremental" was hard to do given the significantly
>>> different information this document must now convey.
>> 
>> I appreciate the labor you've put in, but what we have here is akin to a
>> big patch on highly sensitive mission-critical code for which there are no
>> tests.  I hope we can find a less costly way to integrate your efforts.
> It is a big patch for sure, but I'm not sure I agree with equating it to
> code.  It is probably always going to be "just words" and I'm not sure you
> can create tests.  I think even laws don't have tests, they only have to
> survive the reviews of the approvers and are always subject to revision
> later.  But hopefully the reviewers will think through whether the things
> they thought were "right" about the old version are retained and whether
> the things that were "wrong" have been removed, and new content appears to
> be "right".
> 
>> 
>>> I tried to keep as
>>> much as possible yet incorporate feedback from Doug and Roy.
>> 
>> Even if it was "wrong", people have been quoting from that document,
>> referencing it and following its guidance for a long time.  I'm quite
>> irritated that something "wrong" has persisted for so long and has been
>> used
>> so many times as the basis for settling disputes.
>> 
>> My take is that if that fundamental a document is "wrong", something is
>> dreadfully "wrong" with how hard-won wisdom gets handed down at the ASF.
>> 
>> Let's step back for a moment and reassess what we're trying to accomplish.
>> We're starting with a voting document which is apparently "wrong" and
>> trying
>> to make it quasi-authoritative.  But when we're finished turd polishing,
>> there
>> will still be no boundaries demarcating where the authoritative stuff
>> begins
>> and ends.
>> 
>> We have this problem with the Incubator website, too.  It started off with
>> buckets of poorly-thought-through text scooped out of mailing lists and
>> dumped
>> into version control.  Years later, certain portions of it have been
>> carefully
>> wordsmithed or even negotiated under high heat; as a result, making a
>> minor
>> change has the potential to obliterate a great deal of other people's hard
>> work.  But from just looking at the surface, you can't tell what's
>> garbage and
>> what's crucial.
>> 
>> Personally, I'm not eager to spend a lot of cycles negotiating large
>> revisions
>> to highly-utilized governance documentation under such a flawed regime.
>> I'd
>> rather that we limit ourselves to small tweaks, or if we're going to go
>> all
>> out, draw up a set of default bylaws which will in the future be set off
>> from
>> other documentation and subject to review-then-commit by some governing
>> body
>> charged with oversight.
> Some good points in there.  I know you want to revise the incubator site
> and I wish you well on your efforts to do so because I agree it needs it.,
> However I just want to change this one document, and it shouldn't require
> the restructuring of a site, so I want to separate the two efforts,
> although maybe this effort will influence yours.
> 
> So how about this:  I will go all out and rewrite this one document so it
> will demarcate what is authoritative and what isn't.  And I will try to
> make it clear that the goal of the document is to define a set of default
> by-laws.  And I will retain the entirety of the old document for
> historical reference.  To do so, I will insert the rewrite at the
> beginning of the document after I get lazy consensus on the following text
> which will go at the very beginning.
> 
>   This document is under revision.  The original can be found here
>   (#link_to_original_further_down).  All decision based on the
>   original document remain valid and the original document remains
>valid until further notice.  The text color of the original
>   document has been changed to (brown) to help delineate the
>   boundaries of the original content.
> 
> All authoritative sections will be demarcated with:
> 
>   --this section is authoritative--
> 
> And end with:
> 
>   --end of authoritative section--
> 
> My understanding is that only the code-modification and release voting
> approval type is authoritative.  Please correct me if I'm wrong.
> 
> 
>> 
>>> Below is my
>>> proposed version, and below it is the svn diff in case that makes it
>>> easier to see what changed.  Most of the changes were made at the
>>> beginning.
>> 
>> The formatting of the diff is

Re: [VOTE] Retire the Tashi podling

[Roman Shaposhnik]

On Wed, Oct 2, 2013 at 4:45 PM, Marvin Humphrey  wrote:
> Greets,
>
> As discussed previously on general@incubator[1], the Tashi community has voted
> to retire from the Incubator.  Following the retirement guide[2], it is now
> time for an IPMC vote ratifying their decision.
>
>  [ ] +1 Retire the Tashi podling
>  [ ] +0 Neither here nor there
>  [ ] -1 Do not retire the podling because ...

+1

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Apache project bylaws

[Greg Stein]

For committership, that is typical. Most PMCs allow a veto for adding
new members to the PMC.

On Thu, Oct 3, 2013 at 10:48 AM, Joseph Schaefer  wrote:
> Good Lord man all you need to add is a one-sentence
> statement that personnel votes are consensus votes not
> procedural (simple majority) votes.
>
> On Oct 3, 2013, at 11:40 AM, Alex Harui  wrote:
>
>>
>>
>> On 10/3/13 6:23 AM, "Marvin Humphrey"  wrote:
>>
>>> On Thu, Oct 3, 2013 at 12:09 AM, Alex Harui  wrote:
 On 10/2/13 12:58 PM, "Marvin Humphrey"  wrote:
>>>
> Rather than a "rewrite", I suggest proposing small, incremental,
> reversible
> changes.  Governance is easy to mess up.

 Well, "small, incremental" was hard to do given the significantly
 different information this document must now convey.
>>>
>>> I appreciate the labor you've put in, but what we have here is akin to a
>>> big patch on highly sensitive mission-critical code for which there are no
>>> tests.  I hope we can find a less costly way to integrate your efforts.
>> It is a big patch for sure, but I'm not sure I agree with equating it to
>> code.  It is probably always going to be "just words" and I'm not sure you
>> can create tests.  I think even laws don't have tests, they only have to
>> survive the reviews of the approvers and are always subject to revision
>> later.  But hopefully the reviewers will think through whether the things
>> they thought were "right" about the old version are retained and whether
>> the things that were "wrong" have been removed, and new content appears to
>> be "right".
>>
>>>
 I tried to keep as
 much as possible yet incorporate feedback from Doug and Roy.
>>>
>>> Even if it was "wrong", people have been quoting from that document,
>>> referencing it and following its guidance for a long time.  I'm quite
>>> irritated that something "wrong" has persisted for so long and has been
>>> used
>>> so many times as the basis for settling disputes.
>>>
>>> My take is that if that fundamental a document is "wrong", something is
>>> dreadfully "wrong" with how hard-won wisdom gets handed down at the ASF.
>>>
>>> Let's step back for a moment and reassess what we're trying to accomplish.
>>> We're starting with a voting document which is apparently "wrong" and
>>> trying
>>> to make it quasi-authoritative.  But when we're finished turd polishing,
>>> there
>>> will still be no boundaries demarcating where the authoritative stuff
>>> begins
>>> and ends.
>>>
>>> We have this problem with the Incubator website, too.  It started off with
>>> buckets of poorly-thought-through text scooped out of mailing lists and
>>> dumped
>>> into version control.  Years later, certain portions of it have been
>>> carefully
>>> wordsmithed or even negotiated under high heat; as a result, making a
>>> minor
>>> change has the potential to obliterate a great deal of other people's hard
>>> work.  But from just looking at the surface, you can't tell what's
>>> garbage and
>>> what's crucial.
>>>
>>> Personally, I'm not eager to spend a lot of cycles negotiating large
>>> revisions
>>> to highly-utilized governance documentation under such a flawed regime.
>>> I'd
>>> rather that we limit ourselves to small tweaks, or if we're going to go
>>> all
>>> out, draw up a set of default bylaws which will in the future be set off
>>> from
>>> other documentation and subject to review-then-commit by some governing
>>> body
>>> charged with oversight.
>> Some good points in there.  I know you want to revise the incubator site
>> and I wish you well on your efforts to do so because I agree it needs it.,
>> However I just want to change this one document, and it shouldn't require
>> the restructuring of a site, so I want to separate the two efforts,
>> although maybe this effort will influence yours.
>>
>> So how about this:  I will go all out and rewrite this one document so it
>> will demarcate what is authoritative and what isn't.  And I will try to
>> make it clear that the goal of the document is to define a set of default
>> by-laws.  And I will retain the entirety of the old document for
>> historical reference.  To do so, I will insert the rewrite at the
>> beginning of the document after I get lazy consensus on the following text
>> which will go at the very beginning.
>>
>>   This document is under revision.  The original can be found here
>>   (#link_to_original_further_down).  All decision based on the
>>   original document remain valid and the original document remains
>>valid until further notice.  The text color of the original
>>   document has been changed to (brown) to help delineate the
>>   boundaries of the original content.
>>
>> All authoritative sections will be demarcated with:
>>
>>   --this section is authoritative--
>>
>> And end with:
>>
>>   --end of authoritative section--
>>
>> My understanding is that only the code-modification and release voting
>> approval type is authoritative.  Please c

[RESULTS] Usergrid BaaS Stack for Apache Incubator (revised proposal)

[Dave]

I am officially closing the vote. We have 11 binding +1 votes, 4
non-binding votes and no -1 notes. Usergrid is now officially part of the
Apache Incubator. Thanks to everybody who helped put together the proposal,
those who joined the discussion, those who voted and the Usergrid community.

+1 binding votes

   Afkham Azeez
   Alan D. Cabrera
   Alex Karasulu
   Ate Douma
   Bertrand Delacretaz
   Chip Childers
   David Nalley
   Henry Saputra
   Jim Jagielski
   Luciano Resende
   Marvin Humphrey

+1 non-binding

   Larry McCay
   Lewis John Mcgibbney
   Lieven Govaerts
   Raminder Singh

Totals

   11 binding +1 votes
   4 non-binding +1 votes
   0 -1 votes

Thanks,
Dave


PS. this also happens to be the 2nd anniversary of the day that Usergrid
was released on Github. Happy Birthday Usergrid!

Re: Apache project bylaws

[Joseph Schaefer]

The definitions are in a glossary somewhere, the more
we denormalize the locations of our common understandings
the harder it will be to maintain sanity over discussions.

Projects don't need to be encouraged to write their own
bylaws, most don't bother and that's proper.  We don't need
to spell every possible decision making process out in detail
because they should have experienced the normal processes during
incubation under competent mentorship.

In other words I agree with Marvin that widespread changes
to documents that have been widely referenced are not a good
idea, no matter what the board happens to think today.  Just
clarify the actual issues before us, e.g. how to vote properly
on personnel issues, and that should entirely suffice. Even Greg
doesn't seem to know what consensus voting means in this context,
so there's surely room for improvement.



On Oct 3, 2013, at 12:44 PM, Alex Harui  wrote:

> 
> 
> On 10/3/13 8:48 AM, "Joseph Schaefer"  wrote:
> 
>> Good Lord man all you need to add is a one-sentence
>> statement that personnel votes are consensus votes not
>> procedural (simple majority) votes.
> Hmm. Maybe I'm reaching too far, but my hope was to put in this document a
> definition of consensus and a set of defaults for by-laws so that other
> new projects don't have as much if any work to do in defining their
> project-specific by-laws.
> 
> -Alex
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Apache project bylaws

[Alex Harui]

On 10/3/13 8:48 AM, "Joseph Schaefer"  wrote:

>Good Lord man all you need to add is a one-sentence
>statement that personnel votes are consensus votes not
>procedural (simple majority) votes.
Hmm. Maybe I'm reaching too far, but my hope was to put in this document a
definition of consensus and a set of defaults for by-laws so that other
new projects don't have as much if any work to do in defining their
project-specific by-laws.

-Alex


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [RESULTS] Usergrid BaaS Stack for Apache Incubator (revised proposal)

[Henry Saputra]

Welcome to ASF incubator Usergrid =)

- Henry

On Thu, Oct 3, 2013 at 9:49 AM, Dave  wrote:
> I am officially closing the vote. We have 11 binding +1 votes, 4
> non-binding votes and no -1 notes. Usergrid is now officially part of the
> Apache Incubator. Thanks to everybody who helped put together the proposal,
> those who joined the discussion, those who voted and the Usergrid community.
>
> +1 binding votes
>
>Afkham Azeez
>Alan D. Cabrera
>Alex Karasulu
>Ate Douma
>Bertrand Delacretaz
>Chip Childers
>David Nalley
>Henry Saputra
>Jim Jagielski
>Luciano Resende
>Marvin Humphrey
>
> +1 non-binding
>
>Larry McCay
>Lewis John Mcgibbney
>Lieven Govaerts
>Raminder Singh
>
> Totals
>
>11 binding +1 votes
>4 non-binding +1 votes
>0 -1 votes
>
> Thanks,
> Dave
>
>
> PS. this also happens to be the 2nd anniversary of the day that Usergrid
> was released on Github. Happy Birthday Usergrid!

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Apache project bylaws

[Alex Harui]

On 10/3/13 9:51 AM, "Joseph Schaefer"  wrote:

>The definitions are in a glossary somewhere, the more
>we denormalize the locations of our common understandings
>the harder it will be to maintain sanity over discussions.
OK, found the glossary.  I will try to leverage it more in the next
revision.  It will probably need to have consensus-but-one added to it.
>
>Projects don't need to be encouraged to write their own
>bylaws, most don't bother and that's proper.
Unfortunately, new TLPs are all copying the same board resolution which
dictates that we need to write bylaws.  That's independent of this thread,
but something that I also suggested changing.

>We don't need
>to spell every possible decision making process out in detail
>because they should have experienced the normal processes during
>incubation under competent mentorship.
Well, maybe we got lucky but we got through incubation without any major
conflicts about who should be added and didn't have to deal with removing
anyone.  I think there should be defaults for handling removals in the
voting document.
>
>In other words I agree with Marvin that widespread changes
>to documents that have been widely referenced are not a good
>idea, no matter what the board happens to think today.  Just
>clarify the actual issues before us, e.g. how to vote properly
>on personnel issues, and that should entirely suffice. Even Greg
>doesn't seem to know what consensus voting means in this context,
>so there's surely room for improvement.
OK, I'll try again tonight.

-Alex


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Retire the Tashi podling

[Chip Childers]

On Wed, Oct 02, 2013 at 04:45:31PM -0700, Marvin Humphrey wrote:
> Greets,
> 
> As discussed previously on general@incubator[1], the Tashi community has voted
> to retire from the Incubator.  Following the retirement guide[2], it is now
> time for an IPMC vote ratifying their decision.
> 
>  [ ] +1 Retire the Tashi podling
>  [ ] +0 Neither here nor there
>  [ ] -1 Do not retire the podling because ...

+1

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org