Re: Preparing for the October reports

[sebb]

On 11 October 2012 22:30, David Crossley  wrote:
> Rob Weir wrote:
>> On Thu, Oct 11, 2012 at 3:53 PM, Benson Margulies  
>> wrote:
>> > On Thu, Oct 11, 2012 at 3:38 PM, Rob Weir  wrote:
>> >> On Wed, Oct 10, 2012 at 7:21 PM, Jukka Zitting  
>> >> wrote:
>> >>> Hi,
>> >>>
>> >>> Thanks for the reviews, Benson! I added you as a signer-off on these 
>> >>> reports.
>> >>>
>> >>> As reported and discussed, Kafka remains ready to graduate and will
>> >>> hopefully complete that transition shortly.
>> >>>
>> >>> On Fri, Oct 5, 2012 at 3:19 PM, Benson Margulies  
>> >>> wrote:
>>  ODFToolkit, on the other hand, seems to have a metadata problem. It
>>  shows no total committers and one new committer. Does anyone
>>  understand that? Otherwise, all their boxes are green.
>> >>>
>> >>> Any thoughts on this from mentors or committers of the project?
>> >>>
>> >>
>> >> Well, here is our status page:
>> >>
>> >> http://incubator.apache.org/projects/odftoolkit.html
>> >>
>> >> It lists both committers and mentors, including new committers.   It
>> >> needs an update, since we just voted in a new committer/PPMC member
>> >> last week, but I don't see what a problem here.
>> >>
>> >> Where are you seeing "no total committers" ???
>> >
>> > incubator.apache.org/clutch
>> >
>>
>> Hmmm. another clue is here:  
>> http://people.apache.org/committer-index.html
>>
>> We don't seem to exist.  Our committers are listed as being in
>> "incubator" not there is no "odf" project here.  But we obviously have
>> karma for SVN.  But something is not right.
>
> I have investigated this a few times but not yet found the cause.
> There is also something inconsistent with a few other podlings.
>
> It seems that clutch cannot obtain the lists of committers from
> its normal place, e.g.
> http://people.apache.org/committers-by-project.html#drill
>
> However, cannot find the project "odftoolkit" or the other missing
> ones e.g. "allura" or "cloudstack" etc.
>
> It seems to start going wrong when project started using git
> so perhaps the normal listing of committers is broken.

The people.a.o script only currently looks at groups defined or
referenced in the asf-authorization-template, which AFAIK is not used
for git auth.

odftoolkit does not appear in the svn auth file; I don't know where
git auth is defined.

Some LDAP groups are not referenced in the svn auth file; these are
also not shown on people.a.o.

> -David
>
>> -Rob
>>
>>
>> >
>> >>
>> >>> How should we categorize the status of ODF Toolkit? In June we
>> >>> classified the podling under low activty due to the low commit counts.
>> >>> That figure and those of list activity look a bit better now, though
>> >>> it's hard to tell how much of that is just temporary improvement from
>> >>> the GSoC work.
>> >>>
>> >>
>> >> GSoC did not bring any lasting contributors.  But we've had a step up
>> >> in recent activity from other contributors, not related to the GSoC
>> >> work. So I think that part is looking good, and we're successfully
>> >> overcoming the loss of one of the main contributors earlier in the
>> >> year, the source of our low activity rate at the time.
>> >>
>> >> As we say in the report, if we can bring a couple more committers on
>> >> board, and get out a 2nd release, we think we'll be ready to graduate.
>> >>
>> >>> Like in June, there were no mentor sign-offs on the ODF Toolkit report
>> >>> and I see little mentor activity on odf-dev@. Do we need more/new
>> >>> mentors for the project?
>> >>>
>> >>
>> >> An additional pair of eyes on the podling is always welcome.
>> >>
>> >> Regards,
>> >>
>> >> -Rob
>> >>
>> >>> BR,
>> >>>
>> >>> Jukka Zitting
>> >>>
>> >>> -
>> >>> 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
>> >>
>> >
>> > -
>> > 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
>>
>
> -
> 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

[jira] [Commented] (PODLINGNAMESEARCH-13) Establish whether "Apache Wookie" is a suitable name

[Shane Curcuru (JIRA)]

[ 
https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474666#comment-13474666
 ] 

Shane Curcuru commented on PODLINGNAMESEARCH-13:


Thanks for the thorough searching and the factual and direct comments in the 
Jira thread.

+1 to Apache Wookie!

> Establish whether "Apache Wookie" is a suitable name
> 
>
> Key: PODLINGNAMESEARCH-13
> URL: 
> https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-13
> Project: Podling Suitable Names Search
>  Issue Type: Suitable Name Search
>Reporter: Scott Wilson
>
> We have to do some investigations to ensure that "Apache Wookie" is a 
> suitable name for a TLP. 
> Here are some resources related to this issue: 
> http://incubator.apache.org/guides/names.html 
> http://www.apache.org/foundation/marks/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: Allura name search - What next

[Shane Curcuru]

+1 to Apache Allura.  Commented on your Jira.

If you truly want a "blessing", a little song or dance would be good, 
but not strictly required.  8-)


- Shane

On 10/8/2012 10:41 AM, Rich Bowen wrote:

Trademarks folks,


I've done a name search for 'Allura' and the results of that search are
here:

https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-15

Is there anything I still need to do in order to get the blessing of the
Trademarks folks on using this name?

--
Rich Bowen
rbo...@rcbowen.com  :: @rbowen
rbo...@apache.org 









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

Re: Permission to edit wiki

[Marvin Humphrey]

On Thu, Oct 11, 2012 at 4:52 PM, kishore g  wrote:
> I may have to edit the Helix Proposal wiki.  Can you please grant me
> the permission. My id is k4j

Done.

Marvin Humphrey

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

[jira] [Commented] (PODLINGNAMESEARCH-15) Establish Whether "Apache Allura" would be a Suitable Name

[Shane Curcuru (JIRA)]

[ 
https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474595#comment-13474595
 ] 

Shane Curcuru commented on PODLINGNAMESEARCH-15:


Geez, you missed the Allura font and the AlluraDirect software - for vacation 
rentals in Canada. 8-)

Note also the USPTO is not link friendly; your link to the abandoned 
application is "session expired".  You need to use the TSDR or TTAB links to be 
able to share them, like this: 
http://tsdr.uspto.gov/#caseNumber=74648070&caseType=SERIAL_NO&searchType=statusSearch

Indeed, that is abandoned, and is not directly related to the Apache Allura 
podling software.

Approved.  Enjoy the name!

> Establish Whether "Apache Allura" would be a Suitable Name
> --
>
> Key: PODLINGNAMESEARCH-15
> URL: 
> https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-15
> Project: Podling Suitable Names Search
>  Issue Type: Suitable Name Search
>Reporter: Rich Bowen
>
> Allura means "and then ..." in colloquial Italian. It's also the name of a 
> character in the show Voltron. And it's also the name of a particular red dye 
> color disodium 
> 6-hydroxy-5-((2-methoxy-5-methyl-4-sulfophenyl)azo)-2-naphthalenesulfonate. 
> (http://en.wikipedia.org/wiki/Allura_Red_AC)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

RE: Preparing for the October reports

[Franklin, Matthew B.]

>-Original Message-
>From: Franklin, Matthew B. [mailto:mfrank...@mitre.org]
>Sent: Wednesday, October 10, 2012 9:18 PM
>To: general
>Subject: RE: Preparing for the October reports
>
>>-Original Message-
>>From: Jukka Zitting [mailto:jukka.zitt...@gmail.com]
>>Sent: Wednesday, October 10, 2012 7:28 PM
>>To: general
>>Subject: Re: Preparing for the October reports
>>
>>Hi,
>>
>>On Mon, Sep 24, 2012 at 10:34 PM, Jukka Zitting 
>>wrote:
>>> It would be nice if we had all reviews ready by Tuesday, October 9th,
>>> to give one extra day for unexpected delays.
>>
>>I'm again running a bit late on completing the Incubator report. I
>>hope to have it finished and submitted already tomorrow, but for that
>>we still need the following shepherd reviews:
>>
>>   Dave Fisher  - Celix
>>   Jukka Zitting- EasyAnt
>>   Matt Franklin- CloudStack, Tashi
>>   Matt Hogstrom- VXQuery
>>   Ross Gardler - DeviceMap, JSPWiki
>>
>>Let us know if you won't have time to do the review by tomorrow, so I
>>or someone else can jump in where needed.
>
>I will have mine in tomorrow morning.  Apologies for the tardiness.

I have reviewed both communities and sent notes regarding Tashi.  Cloudstack 
looks to be settling in nicely.

>
>>
>>BR,
>>
>>Jukka Zitting
>>
>>-
>>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
>


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

Tashi: A Shepherd's View

[Franklin, Matthew B.]

I am concerned about the lack of mail list and JIRA activity for the podling 
since the last reporting period.  There has been very little activity, but the 
report indicates a lot of work was completed.  I did see a bunch of commits in 
August, but the only e-mails on the list were from the committing developer and 
there were only 2 at that.

In short, it appears that Tashi does not currently have sufficient community 
activity to be on a path to graduation.

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

Re: Preparing for the October reports

[David Crossley]

Rob Weir wrote:
> On Thu, Oct 11, 2012 at 3:53 PM, Benson Margulies  
> wrote:
> > On Thu, Oct 11, 2012 at 3:38 PM, Rob Weir  wrote:
> >> On Wed, Oct 10, 2012 at 7:21 PM, Jukka Zitting  
> >> wrote:
> >>> Hi,
> >>>
> >>> Thanks for the reviews, Benson! I added you as a signer-off on these 
> >>> reports.
> >>>
> >>> As reported and discussed, Kafka remains ready to graduate and will
> >>> hopefully complete that transition shortly.
> >>>
> >>> On Fri, Oct 5, 2012 at 3:19 PM, Benson Margulies  
> >>> wrote:
>  ODFToolkit, on the other hand, seems to have a metadata problem. It
>  shows no total committers and one new committer. Does anyone
>  understand that? Otherwise, all their boxes are green.
> >>>
> >>> Any thoughts on this from mentors or committers of the project?
> >>>
> >>
> >> Well, here is our status page:
> >>
> >> http://incubator.apache.org/projects/odftoolkit.html
> >>
> >> It lists both committers and mentors, including new committers.   It
> >> needs an update, since we just voted in a new committer/PPMC member
> >> last week, but I don't see what a problem here.
> >>
> >> Where are you seeing "no total committers" ???
> >
> > incubator.apache.org/clutch
> >
> 
> Hmmm. another clue is here:  http://people.apache.org/committer-index.html
> 
> We don't seem to exist.  Our committers are listed as being in
> "incubator" not there is no "odf" project here.  But we obviously have
> karma for SVN.  But something is not right.

I have investigated this a few times but not yet found the cause.
There is also something inconsistent with a few other podlings.

It seems that clutch cannot obtain the lists of committers from
its normal place, e.g.
http://people.apache.org/committers-by-project.html#drill

However, cannot find the project "odftoolkit" or the other missing
ones e.g. "allura" or "cloudstack" etc.

It seems to start going wrong when project started using git
so perhaps the normal listing of committers is broken.

-David

> -Rob
> 
> 
> >
> >>
> >>> How should we categorize the status of ODF Toolkit? In June we
> >>> classified the podling under low activty due to the low commit counts.
> >>> That figure and those of list activity look a bit better now, though
> >>> it's hard to tell how much of that is just temporary improvement from
> >>> the GSoC work.
> >>>
> >>
> >> GSoC did not bring any lasting contributors.  But we've had a step up
> >> in recent activity from other contributors, not related to the GSoC
> >> work. So I think that part is looking good, and we're successfully
> >> overcoming the loss of one of the main contributors earlier in the
> >> year, the source of our low activity rate at the time.
> >>
> >> As we say in the report, if we can bring a couple more committers on
> >> board, and get out a 2nd release, we think we'll be ready to graduate.
> >>
> >>> Like in June, there were no mentor sign-offs on the ODF Toolkit report
> >>> and I see little mentor activity on odf-dev@. Do we need more/new
> >>> mentors for the project?
> >>>
> >>
> >> An additional pair of eyes on the podling is always welcome.
> >>
> >> Regards,
> >>
> >> -Rob
> >>
> >>> BR,
> >>>
> >>> Jukka Zitting
> >>>
> >>> -
> >>> 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
> >>
> >
> > -
> > 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
> 

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

Re: Preparing for the October reports

[Dave Fisher]

Sent from my iPhone

On Oct 11, 2012, at 3:06 PM, Rob Weir  wrote:

> On Thu, Oct 11, 2012 at 3:53 PM, Benson Margulies  
> wrote:
>> On Thu, Oct 11, 2012 at 3:38 PM, Rob Weir  wrote:
>>> On Wed, Oct 10, 2012 at 7:21 PM, Jukka Zitting  
>>> wrote:
 Hi,
 
 Thanks for the reviews, Benson! I added you as a signer-off on these 
 reports.
 
 As reported and discussed, Kafka remains ready to graduate and will
 hopefully complete that transition shortly.
 
 On Fri, Oct 5, 2012 at 3:19 PM, Benson Margulies  
 wrote:
> ODFToolkit, on the other hand, seems to have a metadata problem. It
> shows no total committers and one new committer. Does anyone
> understand that? Otherwise, all their boxes are green.
 
 Any thoughts on this from mentors or committers of the project?
 
>>> 
>>> Well, here is our status page:
>>> 
>>> http://incubator.apache.org/projects/odftoolkit.html
>>> 
>>> It lists both committers and mentors, including new committers.   It
>>> needs an update, since we just voted in a new committer/PPMC member
>>> last week, but I don't see what a problem here.
>>> 
>>> Where are you seeing "no total committers" ???
>> 
>> incubator.apache.org/clutch
>> 
> 
> Hmmm. another clue is here:  http://people.apache.org/committer-index.html
> 
> We don't seem to exist.  Our committers are listed as being in
> "incubator" not there is no "odf" project here.  But we obviously have
> karma for SVN.  But something is not right.

It is likely that Nick and Yegor are too busy. Nick with ConCom and Yegor with 
POI and Openmeetings.

I would volunteer but I have not had much spare time and have missed my 
shepherd duty and need to look at Flex.

I am glad to see you paying more attention to the ODFToolkit.

Regards,
Dave

> 
> -Rob
> 
> 
>> 
>>> 
 How should we categorize the status of ODF Toolkit? In June we
 classified the podling under low activty due to the low commit counts.
 That figure and those of list activity look a bit better now, though
 it's hard to tell how much of that is just temporary improvement from
 the GSoC work.
 
>>> 
>>> GSoC did not bring any lasting contributors.  But we've had a step up
>>> in recent activity from other contributors, not related to the GSoC
>>> work. So I think that part is looking good, and we're successfully
>>> overcoming the loss of one of the main contributors earlier in the
>>> year, the source of our low activity rate at the time.
>>> 
>>> As we say in the report, if we can bring a couple more committers on
>>> board, and get out a 2nd release, we think we'll be ready to graduate.
>>> 
 Like in June, there were no mentor sign-offs on the ODF Toolkit report
 and I see little mentor activity on odf-dev@. Do we need more/new
 mentors for the project?
 
>>> 
>>> An additional pair of eyes on the podling is always welcome.
>>> 
>>> Regards,
>>> 
>>> -Rob
>>> 
 BR,
 
 Jukka Zitting
 
 -
 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
>>> 
>> 
>> -
>> 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
> 

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

Re: key signing

[Marvin Humphrey]

On Thu, Oct 11, 2012 at 1:29 PM, Daniel Shahaf  wrote:
> 1) RM prepares tarball, signs, uploads for voting
> 2) voting passes
> 3) mentor appends his signature to the .asc file
> 4) artifacts posted to dist/
>
> That solves the problem for end users until the RM attends a keysigning
> party.

+1

Great solution.

Marvin Humphrey

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

Re: key signing

[Daniel Shahaf]

Marvin Humphrey wrote on Thu, Oct 11, 2012 at 11:46:23 -0700:
> In my opinion, general@incubator is an appropriate venue to explore ways in
> which the system can be improved.  That will necessarily mean talking about

I am sure there are crypto minds in the ASF who aren't on general@incubator.  

> some implementation details because it would be silly to assess feasibility
> otherwise, but please note that the proposed protocol was labeled a "rough
> draft".  Maybe we can call it "sample" instead, implying the need to start

.. and if you said "We need to design a protocol", and the usual reasons
for not doing that do not apply, they are precisely the guys whose
attention you'll need.

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

Re: key signing

[Daniel Shahaf]

Marvin Humphrey wrote on Thu, Oct 11, 2012 at 11:46:23 -0700:
> On Wed, Oct 10, 2012 at 2:36 PM, Nick Kew  wrote:
> > On 10 Oct 2012, at 17:04, Marvin Humphrey wrote:
> >
> >> In my opinion, we have sufficient expertise here at the ASF to devise an
> >> authentication protocol whose reliability exceeds that of individuals
> >> participating unsupervised in a web of trust, particularly if the protocol
> >> were to incorporate archived video and auditing by a PMC.
> >
> > That may be, but I don't think general@incubator is the place to develop it.
> 
> The Incubator is where the acute need exists, because we are bootstrapping
> entire communities where no one is linked into the web of trust.
> 
> For existing projects, the longer they've been around, the more likely that a
> significant number of committers have attended an ApacheCon key-signing party
> or otherwise had an opportunity to get their keys signed.  But here, we see
> new RMs all the time who are isolated.  It would be nice if we had some
> systematic way of integrating them.
> 
> In the absence of a formal protocol, suggesting that new RMs go find someone
> to sign their key is unsatisfying, since at least some of the time that's
> likely to mean email contact alone and potentially a tenuous relationship to
> the signer.  The alternative of suggesting that new RMs with a release VOTE
> pending go find a local key-signing party to attend seems unrealistic.

No one said that a release need have only one signature... 

1) RM prepares tarball, signs, uploads for voting
2) voting passes
3) mentor appends his signature to the .asc file
4) artifacts posted to dist/

That solves the problem for end users until the RM attends a keysigning
party.

Daniel
(for reference, Subversion requires 3+3 signatures for every release)

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

Re: Preparing for the October reports

[Rob Weir]

On Thu, Oct 11, 2012 at 3:53 PM, Benson Margulies  wrote:
> On Thu, Oct 11, 2012 at 3:38 PM, Rob Weir  wrote:
>> On Wed, Oct 10, 2012 at 7:21 PM, Jukka Zitting  
>> wrote:
>>> Hi,
>>>
>>> Thanks for the reviews, Benson! I added you as a signer-off on these 
>>> reports.
>>>
>>> As reported and discussed, Kafka remains ready to graduate and will
>>> hopefully complete that transition shortly.
>>>
>>> On Fri, Oct 5, 2012 at 3:19 PM, Benson Margulies  
>>> wrote:
 ODFToolkit, on the other hand, seems to have a metadata problem. It
 shows no total committers and one new committer. Does anyone
 understand that? Otherwise, all their boxes are green.
>>>
>>> Any thoughts on this from mentors or committers of the project?
>>>
>>
>> Well, here is our status page:
>>
>> http://incubator.apache.org/projects/odftoolkit.html
>>
>> It lists both committers and mentors, including new committers.   It
>> needs an update, since we just voted in a new committer/PPMC member
>> last week, but I don't see what a problem here.
>>
>> Where are you seeing "no total committers" ???
>
> incubator.apache.org/clutch
>

Hmmm. another clue is here:  http://people.apache.org/committer-index.html

We don't seem to exist.  Our committers are listed as being in
"incubator" not there is no "odf" project here.  But we obviously have
karma for SVN.  But something is not right.

-Rob


>
>>
>>> How should we categorize the status of ODF Toolkit? In June we
>>> classified the podling under low activty due to the low commit counts.
>>> That figure and those of list activity look a bit better now, though
>>> it's hard to tell how much of that is just temporary improvement from
>>> the GSoC work.
>>>
>>
>> GSoC did not bring any lasting contributors.  But we've had a step up
>> in recent activity from other contributors, not related to the GSoC
>> work. So I think that part is looking good, and we're successfully
>> overcoming the loss of one of the main contributors earlier in the
>> year, the source of our low activity rate at the time.
>>
>> As we say in the report, if we can bring a couple more committers on
>> board, and get out a 2nd release, we think we'll be ready to graduate.
>>
>>> Like in June, there were no mentor sign-offs on the ODF Toolkit report
>>> and I see little mentor activity on odf-dev@. Do we need more/new
>>> mentors for the project?
>>>
>>
>> An additional pair of eyes on the podling is always welcome.
>>
>> Regards,
>>
>> -Rob
>>
>>> BR,
>>>
>>> Jukka Zitting
>>>
>>> -
>>> 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
>>
>
> -
> 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: Preparing for the October reports

[Benson Margulies]

On Thu, Oct 11, 2012 at 3:38 PM, Rob Weir  wrote:
> On Wed, Oct 10, 2012 at 7:21 PM, Jukka Zitting  
> wrote:
>> Hi,
>>
>> Thanks for the reviews, Benson! I added you as a signer-off on these reports.
>>
>> As reported and discussed, Kafka remains ready to graduate and will
>> hopefully complete that transition shortly.
>>
>> On Fri, Oct 5, 2012 at 3:19 PM, Benson Margulies  
>> wrote:
>>> ODFToolkit, on the other hand, seems to have a metadata problem. It
>>> shows no total committers and one new committer. Does anyone
>>> understand that? Otherwise, all their boxes are green.
>>
>> Any thoughts on this from mentors or committers of the project?
>>
>
> Well, here is our status page:
>
> http://incubator.apache.org/projects/odftoolkit.html
>
> It lists both committers and mentors, including new committers.   It
> needs an update, since we just voted in a new committer/PPMC member
> last week, but I don't see what a problem here.
>
> Where are you seeing "no total committers" ???

incubator.apache.org/clutch


>
>> How should we categorize the status of ODF Toolkit? In June we
>> classified the podling under low activty due to the low commit counts.
>> That figure and those of list activity look a bit better now, though
>> it's hard to tell how much of that is just temporary improvement from
>> the GSoC work.
>>
>
> GSoC did not bring any lasting contributors.  But we've had a step up
> in recent activity from other contributors, not related to the GSoC
> work. So I think that part is looking good, and we're successfully
> overcoming the loss of one of the main contributors earlier in the
> year, the source of our low activity rate at the time.
>
> As we say in the report, if we can bring a couple more committers on
> board, and get out a 2nd release, we think we'll be ready to graduate.
>
>> Like in June, there were no mentor sign-offs on the ODF Toolkit report
>> and I see little mentor activity on odf-dev@. Do we need more/new
>> mentors for the project?
>>
>
> An additional pair of eyes on the podling is always welcome.
>
> Regards,
>
> -Rob
>
>> BR,
>>
>> Jukka Zitting
>>
>> -
>> 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
>

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

Re: Preparing for the October reports

[Rob Weir]

On Wed, Oct 10, 2012 at 7:21 PM, Jukka Zitting  wrote:
> Hi,
>
> Thanks for the reviews, Benson! I added you as a signer-off on these reports.
>
> As reported and discussed, Kafka remains ready to graduate and will
> hopefully complete that transition shortly.
>
> On Fri, Oct 5, 2012 at 3:19 PM, Benson Margulies  
> wrote:
>> ODFToolkit, on the other hand, seems to have a metadata problem. It
>> shows no total committers and one new committer. Does anyone
>> understand that? Otherwise, all their boxes are green.
>
> Any thoughts on this from mentors or committers of the project?
>

Well, here is our status page:

http://incubator.apache.org/projects/odftoolkit.html

It lists both committers and mentors, including new committers.   It
needs an update, since we just voted in a new committer/PPMC member
last week, but I don't see what a problem here.

Where are you seeing "no total committers" ???

> How should we categorize the status of ODF Toolkit? In June we
> classified the podling under low activty due to the low commit counts.
> That figure and those of list activity look a bit better now, though
> it's hard to tell how much of that is just temporary improvement from
> the GSoC work.
>

GSoC did not bring any lasting contributors.  But we've had a step up
in recent activity from other contributors, not related to the GSoC
work. So I think that part is looking good, and we're successfully
overcoming the loss of one of the main contributors earlier in the
year, the source of our low activity rate at the time.

As we say in the report, if we can bring a couple more committers on
board, and get out a 2nd release, we think we'll be ready to graduate.

> Like in June, there were no mentor sign-offs on the ODF Toolkit report
> and I see little mentor activity on odf-dev@. Do we need more/new
> mentors for the project?
>

An additional pair of eyes on the podling is always welcome.

Regards,

-Rob

> BR,
>
> Jukka Zitting
>
> -
> 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: key signing

[Dennis E. Hamilton]

@Marvin,

Can you say more about Multi-factor?  I know commonly-claimed schemes involve 
the same factor multiple times (e.g., more things that a party knows, like Aunt 
Gracie's dress size).  I agree that confirming a picture ID (something the 
individual has) is another factor.  What other factors are you thinking of?  (I 
am not sure how many factors signings by others count as new factors.)

 - Dennis

-Original Message-
From: Marvin Humphrey [mailto:mar...@rectangular.com] 
Sent: Thursday, October 11, 2012 11:46
To: general@incubator.apache.org
Subject: Re: key signing

On Wed, Oct 10, 2012 at 2:36 PM, Nick Kew  wrote:
> On 10 Oct 2012, at 17:04, Marvin Humphrey wrote:
>
>> In my opinion, we have sufficient expertise here at the ASF to devise an
>> authentication protocol whose reliability exceeds that of individuals
>> participating unsupervised in a web of trust, particularly if the protocol
>> were to incorporate archived video and auditing by a PMC.
>
> That may be, but I don't think general@incubator is the place to develop it.

The Incubator is where the acute need exists, because we are bootstrapping
entire communities where no one is linked into the web of trust.

For existing projects, the longer they've been around, the more likely that a
significant number of committers have attended an ApacheCon key-signing party
or otherwise had an opportunity to get their keys signed.  But here, we see
new RMs all the time who are isolated.  It would be nice if we had some
systematic way of integrating them.

In the absence of a formal protocol, suggesting that new RMs go find someone
to sign their key is unsatisfying, since at least some of the time that's
likely to mean email contact alone and potentially a tenuous relationship to
the signer.  The alternative of suggesting that new RMs with a release VOTE
pending go find a local key-signing party to attend seems unrealistic.

In my opinion, general@incubator is an appropriate venue to explore ways in
which the system can be improved.  That will necessarily mean talking about
some implementation details because it would be silly to assess feasibility
otherwise, but please note that the proposed protocol was labeled a "rough
draft".  Maybe we can call it "sample" instead, implying the need to start
over later -- it doesn't matter to me.  I had always imagined that if the
protocol were to move forward it would undergo a process of relentless
scrutiny and refinement by interested parties outside the Incubator.

The payoff is that with a protocol in place which enables us to establish
identity to a high degree of certainty and add an individual to web of trust
on a short turnaround, the Incubator need not approve another release signed
by an RM who is not linked into the ASF web of trust.

> FWIW for myself I like to back WOT paths by checking manually,
> and feel best about it when I can identify a chain of trust involving only
> people I trust to be savvy enough not to sign keys willy-nilly.
> PGP/GPG support different levels of trust, so the model helps there.

The PR challenge is a separate question.  I will acknowlege that I have been
taken aback by the extreme skepticism in what I view as a straightforward
application of the principles of multi-factor authentication, faithful to
the spirit and letter of the GnuPG docs.

It pains me that the only outcome of this discussion may be that it gets even
harder to make an incubating release. :(

Marvin Humphrey

-
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: [DISCUSS] Jr. Mentor role

[Marvin Humphrey]

On Thu, Oct 11, 2012 at 10:41 AM, Roman Shaposhnik  wrote:
> However, see my 'how would it help to clear 3 +1 IPMC votes hurdle' question
> on this thread'?

If you help to audit the IP of the podling and to instill good habits and
values, it will make it considerably easier for the formal Mentors or other
IPMC members to add their +1.

The first AOO release got my freelance IPMC vote because it was clear that
they knew what they were doing and were taking their role as IP stewards
seriously.  It would have been absurd for me to attempt review of even a tiny
fraction of that codebase -- and in the long run, it is much more important
that the community members own the task of IP management themselves than that
they pass any sort of superficial documentation review.

PS: People who help out with this demanding and time-consuming work accumulate
the sort of merit that lands them on the IPMC and in the ASF membership.

Marvin Humphrey

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

Re: key signing

[Marvin Humphrey]

On Wed, Oct 10, 2012 at 2:36 PM, Nick Kew  wrote:
> On 10 Oct 2012, at 17:04, Marvin Humphrey wrote:
>
>> In my opinion, we have sufficient expertise here at the ASF to devise an
>> authentication protocol whose reliability exceeds that of individuals
>> participating unsupervised in a web of trust, particularly if the protocol
>> were to incorporate archived video and auditing by a PMC.
>
> That may be, but I don't think general@incubator is the place to develop it.

The Incubator is where the acute need exists, because we are bootstrapping
entire communities where no one is linked into the web of trust.

For existing projects, the longer they've been around, the more likely that a
significant number of committers have attended an ApacheCon key-signing party
or otherwise had an opportunity to get their keys signed.  But here, we see
new RMs all the time who are isolated.  It would be nice if we had some
systematic way of integrating them.

In the absence of a formal protocol, suggesting that new RMs go find someone
to sign their key is unsatisfying, since at least some of the time that's
likely to mean email contact alone and potentially a tenuous relationship to
the signer.  The alternative of suggesting that new RMs with a release VOTE
pending go find a local key-signing party to attend seems unrealistic.

In my opinion, general@incubator is an appropriate venue to explore ways in
which the system can be improved.  That will necessarily mean talking about
some implementation details because it would be silly to assess feasibility
otherwise, but please note that the proposed protocol was labeled a "rough
draft".  Maybe we can call it "sample" instead, implying the need to start
over later -- it doesn't matter to me.  I had always imagined that if the
protocol were to move forward it would undergo a process of relentless
scrutiny and refinement by interested parties outside the Incubator.

The payoff is that with a protocol in place which enables us to establish
identity to a high degree of certainty and add an individual to web of trust
on a short turnaround, the Incubator need not approve another release signed
by an RM who is not linked into the ASF web of trust.

> FWIW for myself I like to back WOT paths by checking manually,
> and feel best about it when I can identify a chain of trust involving only
> people I trust to be savvy enough not to sign keys willy-nilly.
> PGP/GPG support different levels of trust, so the model helps there.

The PR challenge is a separate question.  I will acknowlege that I have been
taken aback by the extreme skepticism in what I view as a straightforward
application of the principles of multi-factor authentication, faithful to
the spirit and letter of the GnuPG docs.

It pains me that the only outcome of this discussion may be that it gets even
harder to make an incubating release. :(

Marvin Humphrey

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

Re: [VOTE] Ripple Emulator to be admitted to the incubator

[Christian Grobmeier]

+1 (binding)

On Thu, Oct 11, 2012 at 6:04 PM, Gord Tanner  wrote:
> Please cast your votes!
>
> [ ] +1, recommend Ripple to move into the incubator
> [ ] +0, abstain/don't care
> [ ] -1, do not recommend Ripple to move into the incubator,because...
>
>
>
> Ripple, A Mobile Environment Emulator
> =
>
> Abstract
> 
>
> Ripple is a browser based mobile phone emulator designed to aid in the
> development
> of HTML5 based mobile applications.  Ripple is a cross platform and cross
> runtime testing/debugging tool. It currently supports such runtimes as
> Cordova, WebWorks
> and the Mobile Web.
>
> Proposal
> 
>
> Ripple is going to be (in some circles already is) the goto emulator
> for rapid development of mobile web applications. This
> will be accomplished by quickly keeping up with the mobile web
> platforms as they arise (Cordova, Tizen, WAC, WebWorks, etc).
>
> Background
> ==
>
> Ripple started as a product of tinyHippos and was aquired by Research
> in Motion in late March 2011.  Ripple was then open sourced
> under the Apache 2.0 License and hosted on the blackberry github
> account (http://github.com/blackberry/Ripple-UI).
>
> Ripple is a browser based mobile phone emulator that runs as a chrome
> extension.  It fills the gap for developers between
> developing on their desktops/laptops and having to test on platform
> specific emulators or physical devices. Ripple allows develors
> to quickly edit-refresh-test in Chrome on their desktops/laptops while
> working on web content that will be embedded and distributed
> as a native application.
>
> Rationale
> =
>
> The project is currently opensourced and managed by a small team at
> Research in Motion.  We are starting to have some
> more community engagement but the project could benefit from greater
> exposure in the open source cummunity.  Our team
> overlaps highly with the Cordova group. Watching the success for that
> project in Apache has inspired us to contribute
> Ripple to the ASF as well.
>
> Ripple fills a large gap in the toolset for most mobile web developers
> between development on the desktop and testing
> on the physical device.
>
> Current Status
> ==
>
> Currently all development is managed on github via the issues and the
> direction of the project is strongly influenced by
> Research in Motion.  A more clear project plan and more open
> communication will be needed by this project to abide by
> the apache guidelines.
>
> Metriocracy
> ===
>
> Ripple has been very accepting of letting in patches from 3rd party
> developers and has been functioning like apache in requiring a CLA
> for code to be pulled in. The core team is hoping to grow and include more
> developers.
>
> Community
> =
>
> The development community of Ripple is a small but tight knit group but
> the users of the project number more than 40,000. With the launch
> ofemulate.phonegap.com (which is a portal for installing ripple) we
> are
> getting approx 5000 hits a day to that site.
>
>
> Core Developers
> ===
>
> See Inital Committers below.
>
> Alignment
> =
>
> Apache is a good match for this project due to it's close ties
> to the Cordova Project. Cordova has been very successful as a project
> since joining Apache and we hope Ripple will follow suit.
>
> Known Risks
> ===
>
> Orphaned Products
> -
>
> Ripple is a core component to the toolset at RIM and the Cordova /
> Phonegap community has embrased ripple into their tooling
> as well. This project has been under active development for 3 years
> and a lot of vested interest from both RIM and the
> community is already present to keep the tool up to date.
>
> Inexperience with Open Source
> -
>
> Ripple has been opensourced at RIM for the last year.  All of the work
> is done in the open. There are a few extra measures we need to learn
> how to take (mailing lists, project planning) for working within the
> ASF community.
> However the team has a good understanding of what needs to happen, as
> some of the
> team are also contributers to the Apache Cordova Incubator project.
>
> Homogenous Developers
> --
>
> Ripple's core team currently all works at RIM with contributions for
> some features done by third parties.  There is a
> backlog of features currently done / being put in by third parties
> such as Adobe and IBM.
>
> Reliance on Salaried Developers
> ---
>
> Most of the developers are paid by their employer to contribute to
> this project but are all highly involved on a personal
> level with this project as well as the mobile web community.
>
> Relationships with Other Apache Products
> 
>
> There is a strong overlap and relationship between the ripple and
> cordova teams.  Gord Tanner is an active commiter in
> both project and has been ensuring that both

Re: key signing

[Marvin Humphrey]

On Thu, Oct 11, 2012 at 12:00 AM, Branko Čibej  wrote:

> So instead of giving too much credence to government-issued IDs, you'd
> prefer to give credence to a service provided "for free" by a commercial
> entity with a conceivable interest in inserting backdoors in software or
> subverting trust in certain keys (a.k.a. Google), with the whole thing
> being archived in as system controlled by another commercial entity
> (a.k.a. YouTube, incidentally a.k.a. Google), with no public oversight
> of those archives.

The beauty of multi-factor authentication is that any one factor may have
weaknesses, so long as it remains infeasible to compromise all of them.

Giving an unaccountable proprietary entity like Google a role is indeed a
weakness, just as relying on fallible amateurs to detect potentially forged
government-issued IDs is a weakness.  In a layered system, neither weakness
need be fatal.

> I'm sure you'd sue Google and win if they fake the archive.

I'm confused as to what attack vector you're describing here.

Since Google controls the only copies of the video, in theory they might
"photoshop" its content to alter the appearance of one of the participants --
but that seems implausible because of technical challenges.

It's possible Google could "accidentally" misplace some video content, though.

In the sample/rough-draft protocol I described, the archived video serves two
purposes:

In the short term, it provides footage for third parties contacted out-of-band
(via e.g. phone or email) to review and provide testimonials: "Yes, that's my
colleague Noah Slater, who I've known for 5 years".  Should the video archive
mysteriously vanish before that loop closes, key signing aborts and the system
remains uncompromised.

In the long term, the archived video serves to deter would-be identity
spoofers by capturing their faces and voices for posterity.  An attacker who
has the ability to remove the video (conspirator, rogue employee, cracker who
has compromised Google's servers or more likely the account hosting the video)
would still have to overcome other obstacles -- establishing control over an
ASF committer account, preventing third parties contacted out-of-band from
raising red flags, etc.  It seems to me that the potential dissappearance of
archived video degrades deterrence by a small amount, but that so long as
other factors retain their integrity, the degradation is nowhere near enough
to bring down the system.

Marvin Humphrey

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

Re: [VOTE] Ripple Emulator to be admitted to the incubator

[Ross Gardler]

+1 binding

Sent from mobile, forgive terseness and errors
On Oct 11, 2012 5:05 PM, "Gord Tanner"  wrote:

> Please cast your votes!
>
> [ ] +1, recommend Ripple to move into the incubator
> [ ] +0, abstain/don't care
> [ ] -1, do not recommend Ripple to move into the incubator,because...
>
>
>
> Ripple, A Mobile Environment Emulator
> =
>
> Abstract
> 
>
> Ripple is a browser based mobile phone emulator designed to aid in the
> development
> of HTML5 based mobile applications.  Ripple is a cross platform and cross
> runtime testing/debugging tool. It currently supports such runtimes as
> Cordova, WebWorks
> and the Mobile Web.
>
> Proposal
> 
>
> Ripple is going to be (in some circles already is) the goto emulator
> for rapid development of mobile web applications. This
> will be accomplished by quickly keeping up with the mobile web
> platforms as they arise (Cordova, Tizen, WAC, WebWorks, etc).
>
> Background
> ==
>
> Ripple started as a product of tinyHippos and was aquired by Research
> in Motion in late March 2011.  Ripple was then open sourced
> under the Apache 2.0 License and hosted on the blackberry github
> account (http://github.com/blackberry/Ripple-UI).
>
> Ripple is a browser based mobile phone emulator that runs as a chrome
> extension.  It fills the gap for developers between
> developing on their desktops/laptops and having to test on platform
> specific emulators or physical devices. Ripple allows develors
> to quickly edit-refresh-test in Chrome on their desktops/laptops while
> working on web content that will be embedded and distributed
> as a native application.
>
> Rationale
> =
>
> The project is currently opensourced and managed by a small team at
> Research in Motion.  We are starting to have some
> more community engagement but the project could benefit from greater
> exposure in the open source cummunity.  Our team
> overlaps highly with the Cordova group. Watching the success for that
> project in Apache has inspired us to contribute
> Ripple to the ASF as well.
>
> Ripple fills a large gap in the toolset for most mobile web developers
> between development on the desktop and testing
> on the physical device.
>
> Current Status
> ==
>
> Currently all development is managed on github via the issues and the
> direction of the project is strongly influenced by
> Research in Motion.  A more clear project plan and more open
> communication will be needed by this project to abide by
> the apache guidelines.
>
> Metriocracy
> ===
>
> Ripple has been very accepting of letting in patches from 3rd party
> developers and has been functioning like apache in requiring a CLA
> for code to be pulled in. The core team is hoping to grow and include more
> developers.
>
> Community
> =
>
> The development community of Ripple is a small but tight knit group but
> the users of the project number more than 40,000. With the launch
> ofemulate.phonegap.com (which is a portal for installing ripple) we
> are
> getting approx 5000 hits a day to that site.
>
>
> Core Developers
> ===
>
> See Inital Committers below.
>
> Alignment
> =
>
> Apache is a good match for this project due to it's close ties
> to the Cordova Project. Cordova has been very successful as a project
> since joining Apache and we hope Ripple will follow suit.
>
> Known Risks
> ===
>
> Orphaned Products
> -
>
> Ripple is a core component to the toolset at RIM and the Cordova /
> Phonegap community has embrased ripple into their tooling
> as well. This project has been under active development for 3 years
> and a lot of vested interest from both RIM and the
> community is already present to keep the tool up to date.
>
> Inexperience with Open Source
> -
>
> Ripple has been opensourced at RIM for the last year.  All of the work
> is done in the open. There are a few extra measures we need to learn
> how to take (mailing lists, project planning) for working within the
> ASF community.
> However the team has a good understanding of what needs to happen, as
> some of the
> team are also contributers to the Apache Cordova Incubator project.
>
> Homogenous Developers
> --
>
> Ripple's core team currently all works at RIM with contributions for
> some features done by third parties.  There is a
> backlog of features currently done / being put in by third parties
> such as Adobe and IBM.
>
> Reliance on Salaried Developers
> ---
>
> Most of the developers are paid by their employer to contribute to
> this project but are all highly involved on a personal
> level with this project as well as the mobile web community.
>
> Relationships with Other Apache Products
> 
>
> There is a strong overlap and relationship between the ripple and
> cordova teams.  Gord Tanner is an active commiter in
> both

Re: [VOTE] Ripple Emulator to be admitted to the incubator

[Scott Wilson]

+1 (non-binding)

On 11 Oct 2012, at 18:04, Gord Tanner wrote:

> Please cast your votes!
> 
> [ ] +1, recommend Ripple to move into the incubator
> [ ] +0, abstain/don't care
> [ ] -1, do not recommend Ripple to move into the incubator,because...
> 
> 
> 
> Ripple, A Mobile Environment Emulator
> =
> 
> Abstract
> 
> 
> Ripple is a browser based mobile phone emulator designed to aid in the
> development
> of HTML5 based mobile applications.  Ripple is a cross platform and cross
> runtime testing/debugging tool. It currently supports such runtimes as
> Cordova, WebWorks
> and the Mobile Web.
> 
> Proposal
> 
> 
> Ripple is going to be (in some circles already is) the goto emulator
> for rapid development of mobile web applications. This
> will be accomplished by quickly keeping up with the mobile web
> platforms as they arise (Cordova, Tizen, WAC, WebWorks, etc).
> 
> Background
> ==
> 
> Ripple started as a product of tinyHippos and was aquired by Research
> in Motion in late March 2011.  Ripple was then open sourced
> under the Apache 2.0 License and hosted on the blackberry github
> account (http://github.com/blackberry/Ripple-UI).
> 
> Ripple is a browser based mobile phone emulator that runs as a chrome
> extension.  It fills the gap for developers between
> developing on their desktops/laptops and having to test on platform
> specific emulators or physical devices. Ripple allows develors
> to quickly edit-refresh-test in Chrome on their desktops/laptops while
> working on web content that will be embedded and distributed
> as a native application.
> 
> Rationale
> =
> 
> The project is currently opensourced and managed by a small team at
> Research in Motion.  We are starting to have some
> more community engagement but the project could benefit from greater
> exposure in the open source cummunity.  Our team
> overlaps highly with the Cordova group. Watching the success for that
> project in Apache has inspired us to contribute
> Ripple to the ASF as well.
> 
> Ripple fills a large gap in the toolset for most mobile web developers
> between development on the desktop and testing
> on the physical device.
> 
> Current Status
> ==
> 
> Currently all development is managed on github via the issues and the
> direction of the project is strongly influenced by
> Research in Motion.  A more clear project plan and more open
> communication will be needed by this project to abide by
> the apache guidelines.
> 
> Metriocracy
> ===
> 
> Ripple has been very accepting of letting in patches from 3rd party
> developers and has been functioning like apache in requiring a CLA
> for code to be pulled in. The core team is hoping to grow and include more
> developers.
> 
> Community
> =
> 
> The development community of Ripple is a small but tight knit group but
> the users of the project number more than 40,000. With the launch
> ofemulate.phonegap.com (which is a portal for installing ripple) we
> are
> getting approx 5000 hits a day to that site.
> 
> 
> Core Developers
> ===
> 
> See Inital Committers below.
> 
> Alignment
> =
> 
> Apache is a good match for this project due to it's close ties
> to the Cordova Project. Cordova has been very successful as a project
> since joining Apache and we hope Ripple will follow suit.
> 
> Known Risks
> ===
> 
> Orphaned Products
> -
> 
> Ripple is a core component to the toolset at RIM and the Cordova /
> Phonegap community has embrased ripple into their tooling
> as well. This project has been under active development for 3 years
> and a lot of vested interest from both RIM and the
> community is already present to keep the tool up to date.
> 
> Inexperience with Open Source
> -
> 
> Ripple has been opensourced at RIM for the last year.  All of the work
> is done in the open. There are a few extra measures we need to learn
> how to take (mailing lists, project planning) for working within the
> ASF community.
> However the team has a good understanding of what needs to happen, as
> some of the
> team are also contributers to the Apache Cordova Incubator project.
> 
> Homogenous Developers
> --
> 
> Ripple's core team currently all works at RIM with contributions for
> some features done by third parties.  There is a
> backlog of features currently done / being put in by third parties
> such as Adobe and IBM.
> 
> Reliance on Salaried Developers
> ---
> 
> Most of the developers are paid by their employer to contribute to
> this project but are all highly involved on a personal
> level with this project as well as the mobile web community.
> 
> Relationships with Other Apache Products
> 
> 
> There is a strong overlap and relationship between the ripple and
> cordova teams.  Gord Tanner is an active commiter in
> both projec

Re: [DISCUSS] Jr. Mentor role

[Roman Shaposhnik]

On Thu, Oct 11, 2012 at 10:33 AM, Jakob Homan  wrote:
> You go and help the community out in general and, when it comes time
> for a release, you do all the things a regular mentor would do.  If
> you catch issues with the release, this will be a big help.  No one is
> going to ignore your assistance just because you don't have a specific
> title.

There's no disagreement with any of this. However, see my 'how would
it help to clear 3 +1 IPMC votes hurdle' question on this thread'?

Thanks,
Roman.

P.S. It is an honest question -- if we all agree that the answer to it
is: "it won't" -- that's a fine answer too. The only downside side to
this answer is that it limits the potential usefulness of my involvement.

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

Re: key signing

[Nick Kew]

On 11 Oct 2012, at 17:14, Dennis E. Hamilton wrote:

> @Nick
> 
> I don't understand the supposed attack vector concerning the file digests 
> being of no value and the WoT being essential.
> 
> - Dennis
> 
> ANALYSIS
> 
> So long as the digest value is obtained from a reliable read-only source, it 
> doesn't matter where the file comes from, the digest can be verified.  This 
> will protect against and help detect a poisoned mirror site or a third-party 
> redistribution that substitutes an inauthentic artifact.  That is, in fact, a 
> very big deal and it defends against exploits that happen too regularly.

In saying "a reliable read-only source, you're glossing over the MITM.
My browser may say foo.apache.org when in fact it's talking to my
evil ISP's proxy.

> If the reliable read-only source is compromised, that means an adversary has 
> managed to (1) replace the file in Apache custody, and (2) replace the digest 
> that applies to that artifact.

Yes, for those communicating directly with an apache server.
We can improve the security of that using https, but that too is a
weaker security model due not least to the variable quality of the CAs.

>  (Or just replace the digest and make the authentic file look bogus and the 
> poisoned downloads look authentic.)

Funnily enough I diagnosed a rather similar issue for my mother only yesterday.
A site at which she's shopped before had evidently been compromised, and the
attacker had sent her email she took for genuine, while she was suspicious of a
'confirm your change of password' email that was almost certainly genuine (but
useless).  And the compromise had happened at least a month earlier, as
evidenced by two monthly trojanised 'newsletter's from the attacker.

Anecdotes aside ...

>  If substitution of the file-digest pair is achievable, providing a different 
> external signature can't be much harder, although the exploit might achieve 
> the intended purpose without that. Introducing a verifiable external 
> signature that finds a counterfeit public-key certificate on a key service 
> may extend the ruse a little longer. 

A trojan PGP key is plausible.  Trojanised signatures are possible, though the
bar seems to me to be rising.

But a trojanised chain of trust leading back to a trusted signature?  That 
raises
the bar a long, long way.  And within the ASF we have a lot of WOT
interconnectedness: to impersonate an ASF key you'd need in effect to
impersonate a whole lot of us.  It's a many-eyes scenario, and those eyes
will tend to route to tech-savvy brains.

I'm at an advantage: when I download an Apache bundle, I can generally
trace a chain of trust back to myself.  If I find something signed by "Dennis
E. Hamilton" but without enough ASF sigs to establish a chain of trust
back to myself, I *will* query it, so an imposter is going to have hijacked
your ASF email if (s)he's going to intercept my query and prevent you or
me raising the alarm.  Add to that other checks (e.g. does the project have
an IRC channel, how old is the key and does that check out, if nothing
checks out then ask the project dev list).  Multiply that by lots of other folks
who check PGP keys carefully, and that's a much higher level of security
than some mere checksum.

> The exploit continues until some Apache folk or security-proficient external 
> party detect (1) the substitution or (2) a counterfeit external signature or 
> (3) confirms that the external signature is not verifiable on the substituted 
> file and digest pair.

Not "the signature" .  A whole lot of signatures.  Each with a real person to
notice something is wrong, unlike an unowned checksum.

> I don't see the WoT as much of a factor if this exploit occurs.  It comes 
> down to how quickly the exploit is detected, the damage detected, and a 
> mitigation put in place.  I assume that infrastructure defense-in-depth 
> measures have to expose the fact of an exploit, even if an insider is 
> involved.  At the worst, it might be necessary to recall a release.
> 
> This assumes that the exploit is by exploit against the read-only 
> distribution material in Apache custody.  
> 
> If the exploit is by tampering with a release prior to its approval, that is 
> an entirely different problem,

Sure.  If someone we elect as committer smuggles in a trojan, no amount of 
security
after the event will help.  That's a different issue to the one I thought we 
were
talking about.

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

Re: [DISCUSS] Jr. Mentor role

[Jakob Homan]

> Great. Lets make it practical -- there's a Helix project that is currently
> being proposed for incubation. I'm very much interested in helping
> it to grow into a TLP eventually. Given how closely it aligns with some
> of the things we're trying to do in Bigtop -- I'm definitely joining the
> community.
>
> What are the next steps for me, if I would like to volunteer some of
> my time to support the formal mentors of the project?

You go and help the community out in general and, when it comes time
for a release, you do all the things a regular mentor would do.  If
you catch issues with the release, this will be a big help.  No one is
going to ignore your assistance just because you don't have a specific
title.

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

Re: [DISCUSS] Jr. Mentor role

[Roman Shaposhnik]

On Thu, Oct 11, 2012 at 1:32 AM, Upayavira  wrote:
> I guess I would encourage you to do as Luciano suggests, and to chat to
> mentors on a project that you might help with.

Great. Lets make it practical -- there's a Helix project that is currently
being proposed for incubation. I'm very much interested in helping
it to grow into a TLP eventually. Given how closely it aligns with some
of the things we're trying to do in Bigtop -- I'm definitely joining the
community.

What are the next steps for me, if I would like to volunteer some of
my time to support the formal mentors of the project?

What about any other project that is being proposed for incubation?
Should it all just be on an ad-hoc basis where I reach out to
existing mentors and offer my help?

> It is not uncommon for mentors to feel stretched, and thus might appreciate
> some help with their mentoring duties.

Simply joining a community is definitely very, very useful, but I guess
what I was alluding to is a notion that the official IPMC members can
count on somebody coming as a Jr. Mentor as far as handling some
of the more mundane tasks of mentoring is concerned.

Of course, everything in Apache is done by volunteers, but there are
are different levels of this volunteer commitment. It just so happens that
formal mentors are expected to volunteer a bit more of their time to
help podlings. Members of the podling community know that they can
reach out to mentors and expect an answer, where's if they simply
reach out to the community (or any particular member of the community)
there's no presumption that cycles will be available.

Hence my suggestion -- a more designated role that can be viewed by
the podling community in the same way as they view mentors.

Thanks,
Roman.

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

Re: [VOTE] Ripple Emulator to be admitted to the incubator

[Leif Hedstrom]

On 10/11/12 10:04 AM, Gord Tanner wrote:

Please cast your votes!

[ ] +1, recommend Ripple to move into the incubator
[ ] +0, abstain/don't care
[ ] -1, do not recommend Ripple to move into the incubator,because...


+1 (binding)

-- leif


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

Re: [VOTE] Recommend to the Board to establish the Apache OpenOffice Project

[Leif Hedstrom]

On 10/10/12 1:00 PM, Andrea Pescetti wrote:
Seeing no objections to my last message, and keeping into account that 
this list had been regularly informed about the steps Apache OpenOffice 
was taking towards graduation, I'm hereby asking the IPMC to recommend the 
following resolution to the Board. Aim of the resolution is to establish 
the Apache OpenOffice Project as a Top Level Project.


Please cast your vote:

[ ] +1, recommend the resolution to the Board
[ ] +0, abstain/don't care
[ ] -1, do not recommend the resolution to the Board, because...

This vote will be open for 72 hours from now; only votes from the 
Incubator PMC are binding.


+1 (binding)

-- Leif


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

Re: [DISCUSS] Jr. Mentor role

[Roman Shaposhnik]

On Thu, Oct 11, 2012 at 9:58 AM, Suresh Marru  wrote:
> But great suggestion Luciano (to use all the incumbent IPMC to help more 
> while experiences are fresh).
> My personal opinion is, the easiest way to look for projects needing help is 
> during releases. If a project
> comes to general list without the needed binding 3 IPMC votes, its highly 
> likely that podling needs mentors
> who can spare time to validate the releases. If any podling is struggling to 
> get the releases out, it might be
> useful for us to even take one more extra step and subscribe to the podling 
> dev list and help getting the
> releases right even before they are called for vote.

Validating a release is probably the greatest example of why I asked
the question
and suggested that formalization might be needed. At this point, being
a VP of a TLP
at Apache I feel pretty confident that I can help podlings with good feedback
on release practices. However, I can't really help them clear the '3 IPMC votes'
hurdle, can I?

Thanks,
Roman.

P.S. Same question could be asked wrt. other activities requiring IPMC
karma, btw.

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

Re: [DISCUSS] Jr. Mentor role

[Suresh Marru]

On Oct 11, 2012, at 4:32 AM, Upayavira  wrote:

> There's that, and also the fact that no two mentors have the same level
> of experience anyway, so what you describe is possible within the
> current structures, just isn't formalized.

I am not sure if formalizing the role is neded. I agree with Upayavira that the 
current structure has varying expertise anyway. And more mentoring varies from 
one mentor to another. I have seen one mentor focuses on community aspects 
more, while others focus on releases and legal requirements more and so on. All 
of these roles combined are very helpful.

But great suggestion Luciano (to use all the incumbent IPMC to help more while 
experiences are fresh). My personal opinion is, the easiest way to look for 
projects needing help is during releases. If a project comes to general list 
without the needed binding 3 IPMC votes, its highly likely that podling needs 
mentors who can spare time to validate the releases. If any podling is 
struggling to get the releases out, it might be useful for us to even take one 
more extra step and subscribe to the podling dev list and help getting the 
releases right even before they are called for vote.

Suresh

> 
> I guess I would encourage you to do as Luciano suggests, and to chat to
> mentors on a project that you might help with. It is not uncommon for
> mentors to feel stretched, and thus might appreciate some help with
> their mentoring duties.
> 
> Upayavira
> 
> On Thu, Oct 11, 2012, at 06:19 AM, Luciano Resende wrote:
>> On Wed, Oct 10, 2012 at 6:06 PM, Roman Shaposhnik  wrote:
>>> Hi!
>>> 
>>> ever since Bigtop has incubated I've been thinking
>>> about the experience that I've had and that it would
>>> be very nice if I could help the new projects at least
>>> 1/10th the amount of help I received from some of the
>>> mentors.
>>> 
>>> Also, seeing a steady stream of graduating projects
>>> I would imagine that some of the newly appointed
>>> VPs might also want to help (especially while the
>>> experience of going through the Incubator is still
>>> fresh :-)).
>>> 
>>> Now, as it stands it seems like there are two issues
>>> that would prevent somebody like me to actually
>>> help the existing pool of mentors shoulder the
>>> responsibility of shepherding the new podlings:
>>>   #1 formal mentors are required to be IMPC
>>>   #2 the good mentoring skills need to be honed
>>>over time and can't be assumed
>>> 
>>> So here's what I'm wondering: is there a place for
>>> a Jr. Mentor type of a role within the Incubator?
>>> Basically somebody who can help more Sr. mentors
>>> with more mundane tasks, but still deffer to their
>>> judgement in certain cases.
>>> 
>>> Thanks,
>>> Roman.
>>> 
>> 
>> While official mentors are responsible to help the podling and also
>> report back to IPMC when there are issues, anyone can join a community
>> (podling or TLP) and help the community on "The Apache Way" and with
>> time, you would be recognized by your peers and start building Karma
>> towards different levels at Apache and the projects.
>> 
>> 
>> -- 
>> Luciano Resende
>> http://people.apache.org/~lresende
>> http://twitter.com/lresende1975
>> http://lresende.blogspot.com/
>> 
>> -
>> 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
> 


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

Re: [VOTE] Accept Helix into Apache Incubator

[Suresh Marru]

+ 1 (binding),

Good luck folks!
Suresh

On Oct 10, 2012, at 12:37 PM, kishore g  wrote:

> Hi,
> 
> I would like to call a vote for accepting Helix for incubation in the
> Apache Incubator. I have pasted the full proposal below.
> 
> Please cast your vote:
> 
> [ ] +1, bring Helix into Incubator
> [ ] +0, I don't care either way,
> [ ] -1, do not bring Helix into Incubator, because ...
> 
> This vote will be open for 72 hours and only votes from the Incubator
> PMC are binding.
> 
> Thanks,
> Kishore G
> 
> 
> == Abstract ==
> Helix is a cluster management system for managing partitioned and
> replicated resources in distributed data systems.
> 
> == Proposal ==
> Helix provides an abstraction that separates coordination and
> management tasks from functional tasks of a distributed system. The
> developer defines the system behavior via a state machine, the
> transitions between those states, and constraints on states and
> transitions that govern the system’s valid settings. Helix ensures the
> distributed system satisfies the state machine, controlling state
> changes as appropriate during common operational activities such as
> upgrades, component failures, bootstrapping, running maintenance
> tasks, and adding capacity.
> 
> == Background ==
> Helix was developed at LinkedIn to manage large clusters for several
> diverse applications, including a distributed, partitioned,
> replicated, highly available document store with a master-slave model,
> a search service with multiple replicas that are updated atomically
> and in near real-time, and a change data capture service for reliably
> transporting database changes to caches, other dependent databases and
> indexes.
> 
> These services use Helix to reliably manage dozens of clusters in
> multiple data centers.  These services meet stringent SLAs at large
> scale for mission-critical production applications such as search,
> social gestures, and profiles.
> Helix has proven to be flexible for a wide variety of system
> configurations and operational patterns, is easy to integrate, with
> pluggable interfaces enabling custom behavior.  It depends on Apache
> Zookeeper for coordination and tracking of system state across the
> cluster, as well as providing fault tolerance.
> Helix is written in Java. It was developed internally at LinkedIn to
> meet our particular use cases, but will be useful to many
> organizations facing a similar need to manage large clusters.
> Therefore, we would like to share it the ASF and begin developing a
> community of developers and users within Apache.
> 
> == Rationale ==
> Many organizations can benefit from a generalized cluster management
> system such as Helix. While our distributed data systems use-cases for
> a very large website like LinkedIn has driven the design of Helix, its
> uses are varied and we expect many new use cases to emerge.
> 
> == Current Status ==
> === Meritocracy ===
> Our intent with this incubator proposal is to start building a diverse
> developer community around Helix following the Apache meritocracy
> model. Since Helix was initially developed in late 2011, we have had
> fast adoption and contributions by multiple teams at LinkedIn.
> We plan to continue support for new contributors and work with those
> who contribute significantly to the project to make them committers.
> 
> === Community ===
> Helix is currently being used internally at LinkedIn and is in
> production in that company for customer-facing features. Recent public
> presentations of Helix and its goals garnered much interest from
> potential contributors. We hope to extend our contributor base
> significantly and invite all those who are interested in building
> large-scale distributed systems to participate.
> To further this goal, we use GitHub issue tracking and branching facilities.
> 
> === Core Developers ===
> Helix is currently being developed by three engineers at LinkedIn:
> Kishore Gopalakrishna, Shi Lu and Jason Zheng, and Adam Silberstein,
> an engineer at Trifacta.  Kishore, the lead developer and architect,
> has experience within Apache as an S4 committer. Shi developed the
> partition to node mapping and rebalancing algorithm, cluster admin
> APIs, and the health check framework.  Jason developed the cluster
> controller and most of the test framework.  Adam developed the rich
> alerting framework that enables cluster-wide, “intelligent“ alerts.
> 
> === Alignment ===
> The ASF is the natural choice to host the Helix project as its goal of
> encouraging community-driven open-source projects fits with our vision
> for Helix. Many projects that can benefit from Helix will rely on
> Apache ZooKeeper for cluster state management, and can far more easily
> achieve their operational goals by using Helix.
> 
> == Known Risks ==
> === Orphaned Products ===
> The core developers plan to work full time on the project. There is
> very little risk of Helix being abandoned as it is a critical part of
> LinkedIn's internal 

Re: [VOTE] Recommend to the Board to establish the Apache OpenOffice Project

[Suresh Marru]

+ 1 (binding).

Great to see the project graduate.

Suresh

On Oct 10, 2012, at 3:00 PM, Andrea Pescetti  wrote:

> Seeing no objections to my last message, and keeping into account that this 
> list had been regularly informed about the steps Apache OpenOffice was taking 
> towards graduation, I'm hereby asking the IPMC to recommend the following 
> resolution to the Board. Aim of the resolution is to establish the Apache 
> OpenOffice Project as a Top Level Project.
> 
> Please cast your vote:
> 
> [ ] +1, recommend the resolution to the Board
> [ ] +0, abstain/don't care
> [ ] -1, do not recommend the resolution to the Board, because...
> 
> This vote will be open for 72 hours from now; only votes from the Incubator 
> PMC are binding.
> 
> Resolution text:
>  ---
> WHEREAS, the Board of Directors deems it to be in the best interests of the 
> Foundation and consistent with the Foundation's purpose to establish a 
> Project Management Committee charged with the creation and maintenance of 
> open-source software related to the OpenOffice personal productivity 
> applications, for distribution at no charge to the public.
> 
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to 
> be known as the "Apache OpenOffice Project", be and hereby is established 
> pursuant to Bylaws of the Foundation; and be it further
> 
> RESOLVED, that the Apache OpenOffice Project be and hereby is responsible for 
> the creation and maintenance of software related to the OpenOffice personal 
> productivity applications; and be it further
> 
> RESOLVED, that the office of "Vice President, OpenOffice" be and hereby is 
> created, the person holding such office to serve at the direction of the 
> Board of Directors as the chair of the Apache OpenOffice Project, and to have 
> primary responsibility for management of the projects within the scope of 
> responsibility of the Apache OpenOffice Project; and be it further
> 
> RESOLVED, that the persons listed immediately below be and hereby are 
> appointed to serve as the initial members of the Apache OpenOffice Project:
> 
>* Andre Fischer (af)
>* Andrea Pescetti (pescetti)
>* Andrew Rist (arist)
>* Ariel Constenla-Haile (arielch)
>* Armin Le Grand (alg)
>* Dave Fisher (wave)
>* Donald Harbison (dpharbison)
>* Drew Jensen (atjensen)
>* Ian Lynch (ingotian)
>* Jürgen Schmidt (jsc)
>* Kay Schenk (kschenk)
>* Kazunari Hirano (khirano)
>* Louis Suarez-Potts (louis)
>* Marcus Lange (marcus)
>* Oliver-Rainer Wittmann (orw)
>* Pedro Giffuni (pfg)
>* Peter Junge (pj)
>* Raphael Bircher (rbircher)
>* Regina Henschel (regina)
>* RGB.ES (rgb-es)
>* Roberto Galoppini (galoppini)
>* Yang Shih-Ching (imacat)
>* Yong Lin Ma (mayongl)
> 
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Andrea Pescetti be appointed to 
> the office of Vice President, OpenOffice, to serve in accordance with and 
> subject to the direction of the Board of Directors and the Bylaws of the 
> Foundation until death, resignation, retirement, removal or disqualification, 
> or until a successor is appointed; and be it further
> 
> RESOLVED, that the initial Apache OpenOffice Project be and hereby is tasked 
> with the creation of a set of bylaws intended to encourage open development 
> and increased participation in the OpenOffice Project; and be it further
> 
> RESOLVED, that the Apache OpenOffice Project be and hereby is tasked with the 
> migration and rationalization of the Apache OpenOffice.org podling; and be it 
> further
> 
> RESOLVED, that all responsibilities pertaining to the Apache Incubator 
> OpenOffice.org podling encumbered upon the Apache Incubator Project are 
> hereafter discharged.
>  ---
> Best regards,
>  Andrea Pescetti - Apache OpenOffice PPMC.
> 
> -
> 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: [VOTE] Ripple Emulator to be admitted to the incubator

[Dan Silivestru]

+1

Although I know my vote doesn't count :-)

On Thu, Oct 11, 2012 at 12:04 PM, Gord Tanner  wrote:

> Please cast your votes!
>
> [ ] +1, recommend Ripple to move into the incubator
> [ ] +0, abstain/don't care
> [ ] -1, do not recommend Ripple to move into the incubator,because...
>
>
>
> Ripple, A Mobile Environment Emulator
> =
>
> Abstract
> 
>
> Ripple is a browser based mobile phone emulator designed to aid in the
> development
> of HTML5 based mobile applications.  Ripple is a cross platform and cross
> runtime testing/debugging tool. It currently supports such runtimes as
> Cordova, WebWorks
> and the Mobile Web.
>
> Proposal
> 
>
> Ripple is going to be (in some circles already is) the goto emulator
> for rapid development of mobile web applications. This
> will be accomplished by quickly keeping up with the mobile web
> platforms as they arise (Cordova, Tizen, WAC, WebWorks, etc).
>
> Background
> ==
>
> Ripple started as a product of tinyHippos and was aquired by Research
> in Motion in late March 2011.  Ripple was then open sourced
> under the Apache 2.0 License and hosted on the blackberry github
> account (http://github.com/blackberry/Ripple-UI).
>
> Ripple is a browser based mobile phone emulator that runs as a chrome
> extension.  It fills the gap for developers between
> developing on their desktops/laptops and having to test on platform
> specific emulators or physical devices. Ripple allows develors
> to quickly edit-refresh-test in Chrome on their desktops/laptops while
> working on web content that will be embedded and distributed
> as a native application.
>
> Rationale
> =
>
> The project is currently opensourced and managed by a small team at
> Research in Motion.  We are starting to have some
> more community engagement but the project could benefit from greater
> exposure in the open source cummunity.  Our team
> overlaps highly with the Cordova group. Watching the success for that
> project in Apache has inspired us to contribute
> Ripple to the ASF as well.
>
> Ripple fills a large gap in the toolset for most mobile web developers
> between development on the desktop and testing
> on the physical device.
>
> Current Status
> ==
>
> Currently all development is managed on github via the issues and the
> direction of the project is strongly influenced by
> Research in Motion.  A more clear project plan and more open
> communication will be needed by this project to abide by
> the apache guidelines.
>
> Metriocracy
> ===
>
> Ripple has been very accepting of letting in patches from 3rd party
> developers and has been functioning like apache in requiring a CLA
> for code to be pulled in. The core team is hoping to grow and include more
> developers.
>
> Community
> =
>
> The development community of Ripple is a small but tight knit group but
> the users of the project number more than 40,000. With the launch
> ofemulate.phonegap.com (which is a portal for installing ripple) we
> are
> getting approx 5000 hits a day to that site.
>
>
> Core Developers
> ===
>
> See Inital Committers below.
>
> Alignment
> =
>
> Apache is a good match for this project due to it's close ties
> to the Cordova Project. Cordova has been very successful as a project
> since joining Apache and we hope Ripple will follow suit.
>
> Known Risks
> ===
>
> Orphaned Products
> -
>
> Ripple is a core component to the toolset at RIM and the Cordova /
> Phonegap community has embrased ripple into their tooling
> as well. This project has been under active development for 3 years
> and a lot of vested interest from both RIM and the
> community is already present to keep the tool up to date.
>
> Inexperience with Open Source
> -
>
> Ripple has been opensourced at RIM for the last year.  All of the work
> is done in the open. There are a few extra measures we need to learn
> how to take (mailing lists, project planning) for working within the
> ASF community.
> However the team has a good understanding of what needs to happen, as
> some of the
> team are also contributers to the Apache Cordova Incubator project.
>
> Homogenous Developers
> --
>
> Ripple's core team currently all works at RIM with contributions for
> some features done by third parties.  There is a
> backlog of features currently done / being put in by third parties
> such as Adobe and IBM.
>
> Reliance on Salaried Developers
> ---
>
> Most of the developers are paid by their employer to contribute to
> this project but are all highly involved on a personal
> level with this project as well as the mobile web community.
>
> Relationships with Other Apache Products
> 
>
> There is a strong overlap and relationship between the ripple and
> cordova teams.  Gord Tanner is an active commiter in
> both proj

RE: key signing

[Dennis E. Hamilton]

@Nick

I don't understand the supposed attack vector concerning the file digests being 
of no value and the WoT being essential.

 - Dennis

ANALYSIS

So long as the digest value is obtained from a reliable read-only source, it 
doesn't matter where the file comes from, the digest can be verified.  This 
will protect against and help detect a poisoned mirror site or a third-party 
redistribution that substitutes an inauthentic artifact.  That is, in fact, a 
very big deal and it defends against exploits that happen too regularly.

If the reliable read-only source is compromised, that means an adversary has 
managed to (1) replace the file in Apache custody, and (2) replace the digest 
that applies to that artifact.  (Or just replace the digest and make the 
authentic file look bogus and the poisoned downloads look authentic.)  If 
substitution of the file-digest pair is achievable, providing a different 
external signature can't be much harder, although the exploit might achieve the 
intended purpose without that. Introducing a verifiable external signature that 
finds a counterfeit public-key certificate on a key service may extend the ruse 
a little longer. 

The exploit continues until some Apache folk or security-proficient external 
party detect (1) the substitution or (2) a counterfeit external signature or 
(3) confirms that the external signature is not verifiable on the substituted 
file and digest pair.

I don't see the WoT as much of a factor if this exploit occurs.  It comes down 
to how quickly the exploit is detected, the damage detected, and a mitigation 
put in place.  I assume that infrastructure defense-in-depth measures have to 
expose the fact of an exploit, even if an insider is involved.  At the worst, 
it might be necessary to recall a release.

This assumes that the exploit is by exploit against the read-only distribution 
material in Apache custody.  

If the exploit is by tampering with a release prior to its approval, that is an 
entirely different problem, since it means the digital artifacts have been 
approved as authentic.  Even so, I think it is the trustworthiness committers, 
release managers, and PMC approval that matters here, not the WoT, and that is 
bolstered by the Apache Trust Chain.  The WoT does not protect against someone 
subsequently being revealed to have committed a bad act.  (The revocation of 
trust and how it is noticed is an aspect of WoT that I have not investigated.)

-Original Message-
From: Nick Kew [mailto:n...@webthing.com] 
Sent: Thursday, October 11, 2012 06:46
To: general@incubator.apache.org
Subject: Re: key signing


On 11 Oct 2012, at 09:57, Noah Slater wrote:

> On Thu, Oct 11, 2012 at 9:01 AM, Nick Kew  wrote:
> 
>> 
>> You have to extend that assumption not only to our infrastructure but to
>> every proxy that might come between us and a user, and that might
>> substitute a trojan along with the trojan's own SHA1.
>> 
> 
> The same reasoning holds for the .asc file.

Only if there are no WOT paths to improve confidence in it.

And only if noone ever detects the imposter, which is a lot less
likely with a trojan PGP key (someone in particular is being
impersonated) than a checksum (owned by noone).

-- 
Nick Kew


-
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: key signing

[Dennis E. Hamilton]

I see I committed the sin of using "signature" two different ways, below.

I mean the file digest value (digital hash, SHA1) for what power users and 
appropriate downloader utilities check.

I mean the external digital signature and the signers public-key cert in the 
Apache keys with regard to checking digital signatures on release candidates 
and in any subsequent forensic investigation/confirmation.  

 - Dennis

-Original Message-
From: Dennis E. Hamilton [mailto:orc...@apache.org] 
Sent: Thursday, October 11, 2012 08:19
To: general@incubator.apache.org
Subject: RE: key signing

+1

I'm assuming Benson means the digest (SHA1) by "signature."  Using those from 
the Apache site is probably the first-line for power users and about as much 
extra effort that can be expected.  The use of download utilities that reliably 
check signatures from authentic sources is a small boost -- for power users.  

 - Dennis

The verification of the external signatures also on the Apache site is 
something that I believe is material only for review of the release candidate 
and also any subsequent forensics work if there is a problem.  In all cases, 
the public-key cert should be obtained from the Apache site keys folder.  

The most-significant improvement in this, for binaries at least, is the use of 
embedded signatures that are verified as part of operating-system functions on 
the relevant platform.  That's as low-friction as it gets and users don't have 
to take any special steps at all, other than pay attention to the warning 
dialogs that the platform coughs up.

-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com] 
Sent: Thursday, October 11, 2012 05:20
To: general@incubator.apache.org
Subject: Re: key signing

Greg having more or less restated my opening position ("how do we
improve assurance for probable actual users"), I'd throw in another
bit.

Threat analysis is all well and good, but it please don't forget the
biggest principle here. If the assurance mechanism is so abstruse that
users won't understand it, or so complex that they can't use it, then
they won't, and they will be at the mercy of the dumbest possible
attack.

Before we worry about MITM, or subverted Apache infrastructure, I
claim that we should be offering users a simple, easy-to-understand
means of protecting against fraudulent packages. As per Greg, the
signatures do that. As per me, unsigned keys verified against Apache
infrastructure do that.

Over and above that, we could then ask, 'how could we improve
protection against most complex problems?'

-
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


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

Re: key signing

[Nick Kew]

On 11 Oct 2012, at 09:57, Noah Slater wrote:

> On Thu, Oct 11, 2012 at 9:01 AM, Nick Kew  wrote:
> 
>> 
>> You have to extend that assumption not only to our infrastructure but to
>> every proxy that might come between us and a user, and that might
>> substitute a trojan along with the trojan's own SHA1.
>> 
> 
> The same reasoning holds for the .asc file.

Only if there are no WOT paths to improve confidence in it.

And only if noone ever detects the imposter, which is a lot less
likely with a trojan PGP key (someone in particular is being
impersonated) than a checksum (owned by noone).

-- 
Nick Kew


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

Re: [PROPOSAL] Ripple Emulator

[Gord Tanner]

Please cast your votes!

[ ] +1, recommend Ripple to move into the incubator
[ ] +0, abstain/don't care
[ ] -1, do not recommend Ripple to move into the incubator,because...



> On Thu, Oct 11, 2012 at 3:16 AM, Ross Gardler 
> wrote:
>
>> Great to have you Andrew.
>>
>> Dan, yes, the discuss period has been long enough feel free to call a
>> vote.
>>
>> Ross
>>
>> Sent from my tablet
>> On Oct 10, 2012 7:44 PM, "Dan Silivestru" 
>> wrote:
>>
>> > Hi Andrew,
>> >
>> > That's great news. Ross, does this mean we've hit our "needed" 3
>> mentors?
>> > :-)
>> >
>> > Thanks,
>> >
>> > Dan.
>> >
>> > On Wed, Oct 10, 2012 at 1:36 PM, Andrew Savory 
>> wrote:
>> >
>> > > Hi,
>> > >
>> > > On 9 October 2012 16:11, Ross Gardler 
>> > wrote:
>> > >
>> > >
>> > > > We "need" another mentor (although there is no fixed requirement on
>> > > > the number of mentors, three seems to be the generally accepted
>> target
>> > > > number).
>> > > >
>> > > > Volunteers?
>> > > >
>> > >
>> > > If you'd like more than three, I'm happy to keep an eye on things,
>> though
>> > > not yet sure how much time I'll have for it.
>> > >
>> > >
>> > > Andrew.
>> > > --
>> > > asav...@apache.org / cont...@andrewsavory.com
>> > > http://www.andrewsavory.com/
>> > >
>> >
>> >
>> >
>> > --
>> > Dan Silivestru
>> > +1 (519) 589-3624
>> >
>>
>
>
>
> --
> Gord Tanner
> Senior Developer / Code Poet
> tinyHippos Inc.
> @tinyhippos
>
>


-- 
Gord Tanner
Senior Developer / Code Poet
tinyHippos Inc.
@tinyhippos

RE: key signing

[Dennis E. Hamilton]

+1

I'm assuming Benson means the digest (SHA1) by "signature."  Using those from 
the Apache site is probably the first-line for power users and about as much 
extra effort that can be expected.  The use of download utilities that reliably 
check signatures from authentic sources is a small boost -- for power users.  

 - Dennis

The verification of the external signatures also on the Apache site is 
something that I believe is material only for review of the release candidate 
and also any subsequent forensics work if there is a problem.  In all cases, 
the public-key cert should be obtained from the Apache site keys folder.  

The most-significant improvement in this, for binaries at least, is the use of 
embedded signatures that are verified as part of operating-system functions on 
the relevant platform.  That's as low-friction as it gets and users don't have 
to take any special steps at all, other than pay attention to the warning 
dialogs that the platform coughs up.

-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com] 
Sent: Thursday, October 11, 2012 05:20
To: general@incubator.apache.org
Subject: Re: key signing

Greg having more or less restated my opening position ("how do we
improve assurance for probable actual users"), I'd throw in another
bit.

Threat analysis is all well and good, but it please don't forget the
biggest principle here. If the assurance mechanism is so abstruse that
users won't understand it, or so complex that they can't use it, then
they won't, and they will be at the mercy of the dumbest possible
attack.

Before we worry about MITM, or subverted Apache infrastructure, I
claim that we should be offering users a simple, easy-to-understand
means of protecting against fraudulent packages. As per Greg, the
signatures do that. As per me, unsigned keys verified against Apache
infrastructure do that.

Over and above that, we could then ask, 'how could we improve
protection against most complex problems?'

-
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: Tashi - report missing

[Craig L Russell]

Hi Michael,

On Oct 10, 2012, at 8:03 PM, Michael Stroucken wrote:


Craig L Russell wrote:

Hi Jukka,

The incubator report in wiki is immutable.

Could you please amend the tashi report:

Change "diogo" to "diego"
Please don't, the gentleman's name is "Diogo", though I've  
misspelled it too on occasion. ;)


'nuff said.

Thanks,

Craig




Add me as mentor signed-off-by.

Thanks,
Michael.

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



Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:craig.russ...@oracle.com
P.S. A good JDO? O, Gasp!


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

Re: [VOTE] Recommend to the Board to establish the Apache OpenOffice Project

[Andrea Pescetti]

On 11/10/2012 15:30, Bertrand Delacretaz wrote:

Unless I'm mistaken, the list of PMC members below includes a single
individual (Dave Fisher) who's active in more than just the OO
project, all others have joined the ASF via OO incubation.


Yes, this is quite possible. The way PMC members were selected (public 
nominations on the ooo-dev list) might have been a factor here.



Are the OO mentors really comfortable with this, considering the
unusual size of this project isn't there a need to have a few more
experienced ASFers on the PMC?


I'm obviously not a mentor, but I must say this hasn't been seen as a 
problem so far and that we fully understand that this is just the 
initial PMC, which would be enlarged to further contributors later;  and 
volunteers from other Apache projects who would like to help with 
OpenOffice would of course be very welcome.


In general, strengthening our bonds with other Apache projects is 
something we want to do, and ApacheCon EU will probably be a very good 
opportunity for cross-pollination and talks in this direction.


Regards,
  Andrea.

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

Re: key signing

[Nick Kew]

On 11 Oct 2012, at 13:19, Benson Margulies wrote:

> Over and above that, we could then ask, 'how could we improve
> protection against most complex problems?'

Now that's something the ASF might indeed be well-qualified to hack.

Improved end-user tools (e.g. browser plugins) to take advantage of
the PGP/WoT infrastructure.  Including supplementary resources like
Apache Keys.

-- 
Nick Kew

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

Re: [VOTE] Recommend to the Board to establish the Apache OpenOffice Project

[Bertrand Delacretaz]

Hi,

Unless I'm mistaken, the list of PMC members below includes a single
individual (Dave Fisher) who's active in more than just the OO
project, all others have joined the ASF via OO incubation.

Are the OO mentors really comfortable with this, considering the
unusual size of this project isn't there a need to have a few more
experienced ASFers on the PMC?

I'm not implying that the suggested PMC members are not fit for the
job, and I haven't followed the details of OO incubation, just trying
to give us the best chance of having a good cultural match between
this new big project and the rest of the ASF.

Maybe the answer is that the mentors intend to propose a number of
those folks as ASF members soon, in which case I'll shut up ;-)

-Bertrand


On Wed, Oct 10, 2012 at 9:00 PM, Andrea Pescetti  wrote:
>... RESOLVED, that the persons listed immediately below be and hereby are
> appointed to serve as the initial members of the Apache OpenOffice Project:
>
> * Andre Fischer (af)
> * Andrea Pescetti (pescetti)
> * Andrew Rist (arist)
> * Ariel Constenla-Haile (arielch)
> * Armin Le Grand (alg)
> * Dave Fisher (wave)
> * Donald Harbison (dpharbison)
> * Drew Jensen (atjensen)
> * Ian Lynch (ingotian)
> * Jürgen Schmidt (jsc)
> * Kay Schenk (kschenk)
> * Kazunari Hirano (khirano)
> * Louis Suarez-Potts (louis)
> * Marcus Lange (marcus)
> * Oliver-Rainer Wittmann (orw)
> * Pedro Giffuni (pfg)
> * Peter Junge (pj)
> * Raphael Bircher (rbircher)
> * Regina Henschel (regina)
> * RGB.ES (rgb-es)
> * Roberto Galoppini (galoppini)
> * Yang Shih-Ching (imacat)
> * Yong Lin Ma (mayongl)

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

Re: [VOTE] Graduate Cordova podling from Apache Incubator

[Bertrand Delacretaz]

On Wed, Oct 10, 2012 at 12:24 AM, Steven Gill  wrote:
> This is a call for vote to graduate the Cordova podling from Apache
> Incubator.

+1

> ...We have prepared and reviewed our charter. You can view it at [5]

IMO "related to building cross platform mobile applications with HTML,
Javascript and CSS" is a bit restrictive, you might want to say
"related to building cross platform mobile applications using standard
Web tools such as HTML, Javascript and CSS". Just to avoid having to
change your charter if something new and exciting comes along ;-)

-Bertrand

> [5] http://wiki.apache.org/cordova/Draft%20Charter

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

Re: key signing

[Daniel Shahaf]

sebb wrote on Thu, Oct 11, 2012 at 09:48:25 +0100:
> On 11 October 2012 02:39, Daniel Shahaf  wrote:
> > Greg Stein wrote on Wed, Oct 10, 2012 at 21:31:30 -0400:
> >> Not too much. We still instruct users "take the signatures and verify
> >> them against blah.apache.org/KEYS". John Blackhat could replace the
> >> signatures and install his entry into KEYS.
> >
> > If you use https://people.apache.org/keys/ instead of KEYS files in the
> > dist/ tree, John would have to crack two machines rather than one.
> 
> Last time I looked, the process downloads the key from a PGP server
> (which does not provide any auth at all) using the key id(s) in LDAP.
> 
> I assume you mean John would have to obtain credentials to be able to
> alter the key id in the signer's LDAP record?
> 
> AFAIK, this is the same LDAP that is used to authenticate SVN access
> (which is all that is needed to upload new archives and KEYS).
> 
> Seems like a single point of failure to me - or maybe I am missing
> something here?

LDAP is a single point of failure, but with that you can't forge
anything without causing a post-commit email.

> 
> >  :-P
> >
> > -
> > 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
> 

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

Re: [VOTE] Accept Helix into Apache Incubator

[Mahadev Konar]

+1 binding.

On Wed, Oct 10, 2012 at 1:32 PM, Ted Dunning  wrote:
> +1 (binding)
>
> On Wed, Oct 10, 2012 at 9:37 AM, kishore g  wrote:
>
>> Hi,
>>
>> I would like to call a vote for accepting Helix for incubation in the
>> Apache Incubator. I have pasted the full proposal below.
>>
>> Please cast your vote:
>>
>> [ ] +1, bring Helix into Incubator
>> [ ] +0, I don't care either way,
>> [ ] -1, do not bring Helix into Incubator, because ...
>>
>> This vote will be open for 72 hours and only votes from the Incubator
>> PMC are binding.
>>
>> Thanks,
>> Kishore G
>>
>>
>> == Abstract ==
>> Helix is a cluster management system for managing partitioned and
>> replicated resources in distributed data systems.
>>
>> == Proposal ==
>> Helix provides an abstraction that separates coordination and
>> management tasks from functional tasks of a distributed system. The
>> developer defines the system behavior via a state machine, the
>> transitions between those states, and constraints on states and
>> transitions that govern the system’s valid settings. Helix ensures the
>> distributed system satisfies the state machine, controlling state
>> changes as appropriate during common operational activities such as
>> upgrades, component failures, bootstrapping, running maintenance
>> tasks, and adding capacity.
>>
>> == Background ==
>> Helix was developed at LinkedIn to manage large clusters for several
>> diverse applications, including a distributed, partitioned,
>> replicated, highly available document store with a master-slave model,
>> a search service with multiple replicas that are updated atomically
>> and in near real-time, and a change data capture service for reliably
>> transporting database changes to caches, other dependent databases and
>> indexes.
>>
>> These services use Helix to reliably manage dozens of clusters in
>> multiple data centers.  These services meet stringent SLAs at large
>> scale for mission-critical production applications such as search,
>> social gestures, and profiles.
>> Helix has proven to be flexible for a wide variety of system
>> configurations and operational patterns, is easy to integrate, with
>> pluggable interfaces enabling custom behavior.  It depends on Apache
>> Zookeeper for coordination and tracking of system state across the
>> cluster, as well as providing fault tolerance.
>> Helix is written in Java. It was developed internally at LinkedIn to
>> meet our particular use cases, but will be useful to many
>> organizations facing a similar need to manage large clusters.
>> Therefore, we would like to share it the ASF and begin developing a
>> community of developers and users within Apache.
>>
>> == Rationale ==
>> Many organizations can benefit from a generalized cluster management
>> system such as Helix. While our distributed data systems use-cases for
>> a very large website like LinkedIn has driven the design of Helix, its
>> uses are varied and we expect many new use cases to emerge.
>>
>> == Current Status ==
>> === Meritocracy ===
>> Our intent with this incubator proposal is to start building a diverse
>> developer community around Helix following the Apache meritocracy
>> model. Since Helix was initially developed in late 2011, we have had
>> fast adoption and contributions by multiple teams at LinkedIn.
>> We plan to continue support for new contributors and work with those
>> who contribute significantly to the project to make them committers.
>>
>> === Community ===
>> Helix is currently being used internally at LinkedIn and is in
>> production in that company for customer-facing features. Recent public
>> presentations of Helix and its goals garnered much interest from
>> potential contributors. We hope to extend our contributor base
>> significantly and invite all those who are interested in building
>> large-scale distributed systems to participate.
>> To further this goal, we use GitHub issue tracking and branching
>> facilities.
>>
>> === Core Developers ===
>> Helix is currently being developed by three engineers at LinkedIn:
>> Kishore Gopalakrishna, Shi Lu and Jason Zheng, and Adam Silberstein,
>> an engineer at Trifacta.  Kishore, the lead developer and architect,
>> has experience within Apache as an S4 committer. Shi developed the
>> partition to node mapping and rebalancing algorithm, cluster admin
>> APIs, and the health check framework.  Jason developed the cluster
>> controller and most of the test framework.  Adam developed the rich
>> alerting framework that enables cluster-wide, “intelligent“ alerts.
>>
>> === Alignment ===
>> The ASF is the natural choice to host the Helix project as its goal of
>> encouraging community-driven open-source projects fits with our vision
>> for Helix. Many projects that can benefit from Helix will rely on
>> Apache ZooKeeper for cluster state management, and can far more easily
>> achieve their operational goals by using Helix.
>>
>> == Known Risks ==
>> === Orphaned Products ===
>> The core developers plan t

Re: [VOTE] Recommend to the Board to establish the Apache OpenOffice Project

[Dave Fisher]

+1 (IPMC)

Regards,
Dave

On Oct 11, 2012, at 12:14 AM, Ross Gardler wrote:

> +1 (mentor)
> 
> Sent from my tablet
> On Oct 10, 2012 9:00 PM, "Andrea Pescetti"  wrote:
> 
>> Seeing no objections to my last message, and keeping into account that
>> this list had been regularly informed about the steps Apache OpenOffice was
>> taking towards graduation, I'm hereby asking the IPMC to recommend the
>> following resolution to the Board. Aim of the resolution is to establish
>> the Apache OpenOffice Project as a Top Level Project.
>> 
>> Please cast your vote:
>> 
>> [ ] +1, recommend the resolution to the Board
>> [ ] +0, abstain/don't care
>> [ ] -1, do not recommend the resolution to the Board, because...
>> 
>> This vote will be open for 72 hours from now; only votes from the
>> Incubator PMC are binding.
>> 
>> Resolution text:
>>  ---
>> WHEREAS, the Board of Directors deems it to be in the best interests of
>> the Foundation and consistent with the Foundation's purpose to establish a
>> Project Management Committee charged with the creation and maintenance of
>> open-source software related to the OpenOffice personal productivity
>> applications, for distribution at no charge to the public.
>> 
>> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC),
>> to be known as the "Apache OpenOffice Project", be and hereby is
>> established pursuant to Bylaws of the Foundation; and be it further
>> 
>> RESOLVED, that the Apache OpenOffice Project be and hereby is responsible
>> for the creation and maintenance of software related to the OpenOffice
>> personal productivity applications; and be it further
>> 
>> RESOLVED, that the office of "Vice President, OpenOffice" be and hereby is
>> created, the person holding such office to serve at the direction of the
>> Board of Directors as the chair of the Apache OpenOffice Project, and to
>> have primary responsibility for management of the projects within the scope
>> of responsibility of the Apache OpenOffice Project; and be it further
>> 
>> RESOLVED, that the persons listed immediately below be and hereby are
>> appointed to serve as the initial members of the Apache OpenOffice Project:
>> 
>>* Andre Fischer (af)
>>* Andrea Pescetti (pescetti)
>>* Andrew Rist (arist)
>>* Ariel Constenla-Haile (arielch)
>>* Armin Le Grand (alg)
>>* Dave Fisher (wave)
>>* Donald Harbison (dpharbison)
>>* Drew Jensen (atjensen)
>>* Ian Lynch (ingotian)
>>* Jürgen Schmidt (jsc)
>>* Kay Schenk (kschenk)
>>* Kazunari Hirano (khirano)
>>* Louis Suarez-Potts (louis)
>>* Marcus Lange (marcus)
>>* Oliver-Rainer Wittmann (orw)
>>* Pedro Giffuni (pfg)
>>* Peter Junge (pj)
>>* Raphael Bircher (rbircher)
>>* Regina Henschel (regina)
>>* RGB.ES (rgb-es)
>>* Roberto Galoppini (galoppini)
>>* Yang Shih-Ching (imacat)
>>* Yong Lin Ma (mayongl)
>> 
>> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Andrea Pescetti be appointed
>> to the office of Vice President, OpenOffice, to serve in accordance with
>> and subject to the direction of the Board of Directors and the Bylaws of
>> the Foundation until death, resignation, retirement, removal or
>> disqualification, or until a successor is appointed; and be it further
>> 
>> RESOLVED, that the initial Apache OpenOffice Project be and hereby is
>> tasked with the creation of a set of bylaws intended to encourage open
>> development and increased participation in the OpenOffice Project; and be
>> it further
>> 
>> RESOLVED, that the Apache OpenOffice Project be and hereby is tasked with
>> the migration and rationalization of the Apache OpenOffice.org podling; and
>> be it further
>> 
>> RESOLVED, that all responsibilities pertaining to the Apache Incubator
>> OpenOffice.org podling encumbered upon the Apache Incubator Project are
>> hereafter discharged.
>>  ---
>> Best regards,
>>  Andrea Pescetti - Apache OpenOffice PPMC.
>> 
>> --**--**-
>> To unsubscribe, e-mail: 
>> general-unsubscribe@incubator.**apache.org
>> For additional commands, e-mail: 
>> general-help@incubator.apache.**org
>> 
>> 


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

Re: key signing

[Martijn Dashorst]

On Thu, Oct 11, 2012 at 10:57 AM, Noah Slater  wrote:
> Which is why we link to the .md5, .sha, .asc, and KEYS files on our severs.
> Unless you're assuming a MITM along the request/response path to apache.org,
> in which case all bets are off anyway. No?

Which is why I have my release vote messages include the .asc files in
the actual vote. This way people can verify that the vote that is
being carried out is done on the right artifacts including the correct
.asc files.

Perhaps I need to include the .asc contents in the release
announcements as well (though that might be overkill).

Martijn

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

Re: [VOTE] Recommend to the Board to establish the Apache OpenOffice Project

[Alexei Fedotov]

+1


On Thu, Oct 11, 2012 at 2:53 PM, Mark Struberg  wrote:
> +1
>
> LieGrue,
> strub
>
>
>
>
> - Original Message -
>> From: Ross Gardler 
>> To: general@incubator.apache.org
>> Cc:
>> Sent: Thursday, October 11, 2012 9:14 AM
>> Subject: Re: [VOTE] Recommend to the Board to establish the Apache 
>> OpenOffice Project
>>
>> +1 (mentor)
>>
>> Sent from my tablet
>> On Oct 10, 2012 9:00 PM, "Andrea Pescetti" 
>> wrote:
>>
>>>  Seeing no objections to my last message, and keeping into account that
>>>  this list had been regularly informed about the steps Apache OpenOffice was
>>>  taking towards graduation, I'm hereby asking the IPMC to recommend the
>>>  following resolution to the Board. Aim of the resolution is to establish
>>>  the Apache OpenOffice Project as a Top Level Project.
>>>
>>>  Please cast your vote:
>>>
>>>  [ ] +1, recommend the resolution to the Board
>>>  [ ] +0, abstain/don't care
>>>  [ ] -1, do not recommend the resolution to the Board, because...
>>>
>>>  This vote will be open for 72 hours from now; only votes from the
>>>  Incubator PMC are binding.
>>>
>>>  Resolution text:
>>>---
>>>  WHEREAS, the Board of Directors deems it to be in the best interests of
>>>  the Foundation and consistent with the Foundation's purpose to
>> establish a
>>>  Project Management Committee charged with the creation and maintenance of
>>>  open-source software related to the OpenOffice personal productivity
>>>  applications, for distribution at no charge to the public.
>>>
>>>  NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC),
>>>  to be known as the "Apache OpenOffice Project", be and hereby is
>>>  established pursuant to Bylaws of the Foundation; and be it further
>>>
>>>  RESOLVED, that the Apache OpenOffice Project be and hereby is responsible
>>>  for the creation and maintenance of software related to the OpenOffice
>>>  personal productivity applications; and be it further
>>>
>>>  RESOLVED, that the office of "Vice President, OpenOffice" be and
>> hereby is
>>>  created, the person holding such office to serve at the direction of the
>>>  Board of Directors as the chair of the Apache OpenOffice Project, and to
>>>  have primary responsibility for management of the projects within the scope
>>>  of responsibility of the Apache OpenOffice Project; and be it further
>>>
>>>  RESOLVED, that the persons listed immediately below be and hereby are
>>>  appointed to serve as the initial members of the Apache OpenOffice Project:
>>>
>>>  * Andre Fischer (af)
>>>  * Andrea Pescetti (pescetti)
>>>  * Andrew Rist (arist)
>>>  * Ariel Constenla-Haile (arielch)
>>>  * Armin Le Grand (alg)
>>>  * Dave Fisher (wave)
>>>  * Donald Harbison (dpharbison)
>>>  * Drew Jensen (atjensen)
>>>  * Ian Lynch (ingotian)
>>>  * Jürgen Schmidt (jsc)
>>>  * Kay Schenk (kschenk)
>>>  * Kazunari Hirano (khirano)
>>>  * Louis Suarez-Potts (louis)
>>>  * Marcus Lange (marcus)
>>>  * Oliver-Rainer Wittmann (orw)
>>>  * Pedro Giffuni (pfg)
>>>  * Peter Junge (pj)
>>>  * Raphael Bircher (rbircher)
>>>  * Regina Henschel (regina)
>>>  * RGB.ES (rgb-es)
>>>  * Roberto Galoppini (galoppini)
>>>  * Yang Shih-Ching (imacat)
>>>  * Yong Lin Ma (mayongl)
>>>
>>>  NOW, THEREFORE, BE IT FURTHER RESOLVED, that Andrea Pescetti be appointed
>>>  to the office of Vice President, OpenOffice, to serve in accordance with
>>>  and subject to the direction of the Board of Directors and the Bylaws of
>>>  the Foundation until death, resignation, retirement, removal or
>>>  disqualification, or until a successor is appointed; and be it further
>>>
>>>  RESOLVED, that the initial Apache OpenOffice Project be and hereby is
>>>  tasked with the creation of a set of bylaws intended to encourage open
>>>  development and increased participation in the OpenOffice Project; and be
>>>  it further
>>>
>>>  RESOLVED, that the Apache OpenOffice Project be and hereby is tasked with
>>>  the migration and rationalization of the Apache OpenOffice.org podling; and
>>>  be it further
>>>
>>>  RESOLVED, that all responsibilities pertaining to the Apache Incubator
>>>  OpenOffice.org podling encumbered upon the Apache Incubator Project are
>>>  hereafter discharged.
>>>---
>>>  Best regards,
>>>Andrea Pescetti - Apache OpenOffice PPMC.
>>>
>>>  --**--**-
>>>  To unsubscribe, e-mail:
>> general-unsubscribe@incubator.**apache.org
>>>  For additional commands, e-mail:
>> general-help@incubator.apache.**org
>>>
>>>
>>
>
> -
> 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 additiona

Re: [VOTE] Graduate Cordova podling from Apache Incubator

[Mark Struberg]

+1

LieGrue,
strub



- Original Message -
> From: Steven Gill 
> To: general@incubator.apache.org
> Cc: 
> Sent: Wednesday, October 10, 2012 12:24 AM
> Subject: [VOTE] Graduate Cordova podling from Apache Incubator
> 
>T his is a call for vote to graduate the Cordova podling from Apache
> Incubator.
> 
> Cordova entered the Incubator in October of 2011. We have made significant
> progress with the project since moving over to Apache. We have 30
> committers listed on our status page at [1]. We made our first official
> Cordova release last month. Results for that vote can be viewed at [2]. We
> have also added support for new platforms such as Tizen, Windows, Windows
> Phone 8 and more. You can view all of our repos at [3].
> 
> The community of Cordova is active, healthy and growing and has
> demonstrated the ability to self-govern using accepted Apache practices.
> 
> The Apache Cordova community are under consensus that we are ready to
> graduation. You can view the discussion at [4].
> 
> We have prepared and reviewed our charter. You can view it at [5].
> 
> Please cast your votes:
> 
> [ ] +1 Graduate Isis podling from Apache Incubator [ ] +0 Indifferent to
> the graduation status of Isis podling [ ] -1 Reject graduation of Isis
> podling from Apache Incubator because ...
> 
> This vote will be open for at least 72 hours.
> 
> 
> [1] http://incubator.apache.org/projects/callback.html
> [2] http://markmail.org/message/g5g32hnh223gj34m
> [3] https://git-wip-us.apache.org/repos/asf
> [4] http://markmail.org/message/3bcttovgyjrypiq4
> [5] http://wiki.apache.org/cordova/Draft%20Charter
> 
> Cheers,
> -Steve Gill
> 

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

Re: [VOTE] Recommend to the Board to establish the Apache OpenOffice Project

[Mark Struberg]

+1

LieGrue,
strub




- Original Message -
> From: Ross Gardler 
> To: general@incubator.apache.org
> Cc: 
> Sent: Thursday, October 11, 2012 9:14 AM
> Subject: Re: [VOTE] Recommend to the Board to establish the Apache OpenOffice 
> Project
> 
> +1 (mentor)
> 
> Sent from my tablet
> On Oct 10, 2012 9:00 PM, "Andrea Pescetti"  
> wrote:
> 
>>  Seeing no objections to my last message, and keeping into account that
>>  this list had been regularly informed about the steps Apache OpenOffice was
>>  taking towards graduation, I'm hereby asking the IPMC to recommend the
>>  following resolution to the Board. Aim of the resolution is to establish
>>  the Apache OpenOffice Project as a Top Level Project.
>> 
>>  Please cast your vote:
>> 
>>  [ ] +1, recommend the resolution to the Board
>>  [ ] +0, abstain/don't care
>>  [ ] -1, do not recommend the resolution to the Board, because...
>> 
>>  This vote will be open for 72 hours from now; only votes from the
>>  Incubator PMC are binding.
>> 
>>  Resolution text:
>>    ---
>>  WHEREAS, the Board of Directors deems it to be in the best interests of
>>  the Foundation and consistent with the Foundation's purpose to 
> establish a
>>  Project Management Committee charged with the creation and maintenance of
>>  open-source software related to the OpenOffice personal productivity
>>  applications, for distribution at no charge to the public.
>> 
>>  NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC),
>>  to be known as the "Apache OpenOffice Project", be and hereby is
>>  established pursuant to Bylaws of the Foundation; and be it further
>> 
>>  RESOLVED, that the Apache OpenOffice Project be and hereby is responsible
>>  for the creation and maintenance of software related to the OpenOffice
>>  personal productivity applications; and be it further
>> 
>>  RESOLVED, that the office of "Vice President, OpenOffice" be and 
> hereby is
>>  created, the person holding such office to serve at the direction of the
>>  Board of Directors as the chair of the Apache OpenOffice Project, and to
>>  have primary responsibility for management of the projects within the scope
>>  of responsibility of the Apache OpenOffice Project; and be it further
>> 
>>  RESOLVED, that the persons listed immediately below be and hereby are
>>  appointed to serve as the initial members of the Apache OpenOffice Project:
>> 
>>      * Andre Fischer (af)
>>      * Andrea Pescetti (pescetti)
>>      * Andrew Rist (arist)
>>      * Ariel Constenla-Haile (arielch)
>>      * Armin Le Grand (alg)
>>      * Dave Fisher (wave)
>>      * Donald Harbison (dpharbison)
>>      * Drew Jensen (atjensen)
>>      * Ian Lynch (ingotian)
>>      * Jürgen Schmidt (jsc)
>>      * Kay Schenk (kschenk)
>>      * Kazunari Hirano (khirano)
>>      * Louis Suarez-Potts (louis)
>>      * Marcus Lange (marcus)
>>      * Oliver-Rainer Wittmann (orw)
>>      * Pedro Giffuni (pfg)
>>      * Peter Junge (pj)
>>      * Raphael Bircher (rbircher)
>>      * Regina Henschel (regina)
>>      * RGB.ES (rgb-es)
>>      * Roberto Galoppini (galoppini)
>>      * Yang Shih-Ching (imacat)
>>      * Yong Lin Ma (mayongl)
>> 
>>  NOW, THEREFORE, BE IT FURTHER RESOLVED, that Andrea Pescetti be appointed
>>  to the office of Vice President, OpenOffice, to serve in accordance with
>>  and subject to the direction of the Board of Directors and the Bylaws of
>>  the Foundation until death, resignation, retirement, removal or
>>  disqualification, or until a successor is appointed; and be it further
>> 
>>  RESOLVED, that the initial Apache OpenOffice Project be and hereby is
>>  tasked with the creation of a set of bylaws intended to encourage open
>>  development and increased participation in the OpenOffice Project; and be
>>  it further
>> 
>>  RESOLVED, that the Apache OpenOffice Project be and hereby is tasked with
>>  the migration and rationalization of the Apache OpenOffice.org podling; and
>>  be it further
>> 
>>  RESOLVED, that all responsibilities pertaining to the Apache Incubator
>>  OpenOffice.org podling encumbered upon the Apache Incubator Project are
>>  hereafter discharged.
>>    ---
>>  Best regards,
>>    Andrea Pescetti - Apache OpenOffice PPMC.
>> 
>>  --**--**-
>>  To unsubscribe, e-mail: 
> general-unsubscribe@incubator.**apache.org
>>  For additional commands, e-mail: 
> general-help@incubator.apache.**org
>> 
>> 
>

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

Re: [VOTE] Apache OpenMeetings Drupal Plugin 1.0 Incubating Release Candidate 1

[Alexei Fedotov]

+1



On Thu, Oct 11, 2012 at 1:40 PM, seba.wag...@gmail.com
 wrote:
> We've moved the project to apache-extras.org
>
> http://code.google.com/a/apache-extras.org/p/drupal-plugin-openmeetings/
>
> Sebastian
>
> 2012/9/13 Jukka Zitting 
>
>> Hi,
>>
>> On Thu, Sep 13, 2012 at 10:08 AM, seba.wag...@gmail.com
>>  wrote:
>> > I don't want to create a "claim" here. If the request raises too many
>> > concerns we will simply move it to apache-extras.org. Although it
>> > would be better if we could maintain those plugins within the ASF and
>> > contributors have the chance to become full members of our project.
>> > Also I don't understand in what sense implementing an API
>> > automatically requires all code to apply a certain License.
>>
>> I agree with that argument against the viral nature of GPL, but in
>> general the ASF has tended to honor the wishes of upstream copyright
>> owners also beyond the requirements of copyright law.
>>
>> > Somehow those issues just prevent progress. Maybe we should wait until
>> > the Incubator/Board meeting at the 19th takes place?
>>
>> The ASF legal team is best positioned to resolve this issue. LEGAL-147
>> [1] is the place to look at.
>>
>> [1] https://issues.apache.org/jira/browse/LEGAL-147
>>
>> BR,
>>
>> Jukka Zitting
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wag...@gmail.com

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

Re: [VOTE] Apache OpenMeetings Drupal Plugin 1.0 Incubating Release Candidate 1

[seba.wag...@gmail.com]

We've moved the project to apache-extras.org

http://code.google.com/a/apache-extras.org/p/drupal-plugin-openmeetings/

Sebastian

2012/9/13 Jukka Zitting 

> Hi,
>
> On Thu, Sep 13, 2012 at 10:08 AM, seba.wag...@gmail.com
>  wrote:
> > I don't want to create a "claim" here. If the request raises too many
> > concerns we will simply move it to apache-extras.org. Although it
> > would be better if we could maintain those plugins within the ASF and
> > contributors have the chance to become full members of our project.
> > Also I don't understand in what sense implementing an API
> > automatically requires all code to apply a certain License.
>
> I agree with that argument against the viral nature of GPL, but in
> general the ASF has tended to honor the wishes of upstream copyright
> owners also beyond the requirements of copyright law.
>
> > Somehow those issues just prevent progress. Maybe we should wait until
> > the Incubator/Board meeting at the 19th takes place?
>
> The ASF legal team is best positioned to resolve this issue. LEGAL-147
> [1] is the place to look at.
>
> [1] https://issues.apache.org/jira/browse/LEGAL-147
>
> BR,
>
> Jukka Zitting
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wag...@gmail.com

Re: key signing

[Noah Slater]

On Thu, Oct 11, 2012 at 9:48 AM, sebb  wrote:

> On 11 October 2012 02:39, Daniel Shahaf  wrote:
> > Greg Stein wrote on Wed, Oct 10, 2012 at 21:31:30 -0400:
> >> Not too much. We still instruct users "take the signatures and verify
> >> them against blah.apache.org/KEYS". John Blackhat could replace the
> >> signatures and install his entry into KEYS.
> >
> > If you use https://people.apache.org/keys/ instead of KEYS files in the
> > dist/ tree, John would have to crack two machines rather than one.
>
> Last time I looked, the process downloads the key from a PGP server
> (which does not provide any auth at all) using the key id(s) in LDAP.
>

The recommended procedure is to ask the users to download the KEYS file
directly from the root of the dist dir, and import all the keys directly
from that. As far as I know. That's how we do it on CouchDB. I think httpd
does that too.


-- 
NS

Re: key signing

[Noah Slater]

On Thu, Oct 11, 2012 at 9:01 AM, Nick Kew  wrote:

>
> You have to extend that assumption not only to our infrastructure but to
> every proxy that might come between us and a user, and that might
> substitute a trojan along with the trojan's own SHA1.
>

The same reasoning holds for the .asc file. A MITM attack might involve a
mirror replacing the release artefact, along with the .md5, .sha, and .asc
files. If the user is only verifying against those files, then everything
might look kushti. (Assuming they skip the step where they're supposed to
import the KEYS file, or assuming someone replaced that too.)

Which is why we link to the .md5, .sha, .asc, and KEYS files on our severs.
Unless you're assuming a MITM along the request/response path to apache.org,
in which case all bets are off anyway. No?

-- 
NS

Re: key signing

[sebb]

On 11 October 2012 02:39, Daniel Shahaf  wrote:
> Greg Stein wrote on Wed, Oct 10, 2012 at 21:31:30 -0400:
>> Not too much. We still instruct users "take the signatures and verify
>> them against blah.apache.org/KEYS". John Blackhat could replace the
>> signatures and install his entry into KEYS.
>
> If you use https://people.apache.org/keys/ instead of KEYS files in the
> dist/ tree, John would have to crack two machines rather than one.

Last time I looked, the process downloads the key from a PGP server
(which does not provide any auth at all) using the key id(s) in LDAP.

I assume you mean John would have to obtain credentials to be able to
alter the key id in the signer's LDAP record?

AFAIK, this is the same LDAP that is used to authenticate SVN access
(which is all that is needed to upload new archives and KEYS).

Seems like a single point of failure to me - or maybe I am missing
something here?

>  :-P
>
> -
> 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: [DISCUSS] Jr. Mentor role

[Upayavira]

There's that, and also the fact that no two mentors have the same level
of experience anyway, so what you describe is possible within the
current structures, just isn't formalised.

I guess I would encourage you to do as Luciano suggests, and to chat to
mentors on a project that you might help with. It is not uncommon for
mentors to feel stretched, and thus might appreciate some help with
their mentoring duties.

Upayavira

On Thu, Oct 11, 2012, at 06:19 AM, Luciano Resende wrote:
> On Wed, Oct 10, 2012 at 6:06 PM, Roman Shaposhnik  wrote:
> > Hi!
> >
> > ever since Bigtop has incubated I've been thinking
> > about the experience that I've had and that it would
> > be very nice if I could help the new projects at least
> > 1/10th the amount of help I received from some of the
> > mentors.
> >
> > Also, seeing a steady stream of graduating projects
> > I would imagine that some of the newly appointed
> > VPs might also want to help (especially while the
> > experience of going through the Incubator is still
> > fresh :-)).
> >
> > Now, as it stands it seems like there are two issues
> > that would prevent somebody like me to actually
> > help the existing pool of mentors shoulder the
> > responsibility of shepherding the new podlings:
> >#1 formal mentors are required to be IMPC
> >#2 the good mentoring skills need to be honed
> > over time and can't be assumed
> >
> > So here's what I'm wondering: is there a place for
> > a Jr. Mentor type of a role within the Incubator?
> > Basically somebody who can help more Sr. mentors
> > with more mundane tasks, but still deffer to their
> > judgement in certain cases.
> >
> > Thanks,
> > Roman.
> >
> 
> While official mentors are responsible to help the podling and also
> report back to IPMC when there are issues, anyone can join a community
> (podling or TLP) and help the community on "The Apache Way" and with
> time, you would be recognized by your peers and start building Karma
> towards different levels at Apache and the projects.
> 
> 
> -- 
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
> 
> -
> 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: key signing

[Nick Kew]

On 11 Oct 2012, at 00:44, Greg Stein wrote:

> Please explain how "keys" are needed for this ASF release? Consumers are
> already told to verify the SHA1 and nothing more. I doubt any more is
> needed.

SHA1 offers no more protection than a checksum against MITM attack.

> (assume secure Infrastructure)

You have to extend that assumption not only to our infrastructure but to
every proxy that might come between us and a user, and that might
substitute a trojan along with the trojan's own SHA1.

-- 
Nick Kew

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

Re: [VOTE] [DISCUSS] Recommend to the Board to establish the Apache OpenOffice Project

[Andrea Pescetti]

Jukka Zitting wrote:

On Wed, Oct 10, 2012 at 10:00 PM, Andrea Pescetti wrote:

Aim of the resolution is to establish the
Apache OpenOffice Project as a Top Level Project.


   [x] +1, recommend the resolution to the Board

Good luck, and a big thank you to everyone involved!


Thank you!


The recommended resolution template has changed a bit recently. I
suggest you update the text to (otherwise the board will likely do so
in any case):
 [...] charged with the creation and maintenance of
 open-source software, for distribution at no charge to
 the public, related to open-source software related to
 the OpenOffice personal productivity applications.


Thanks. Actually there's a repetition here, I assume you meant "to the 
public, related to the OpenOffice personal productivity applications."


The revised version is below and, since the text is unchanged besides 
two sentences being swapped, I assume we can go on with the current vote.


Resolution text:
  ---
WHEREAS, the Board of Directors deems it to be in the best interests of 
the Foundation and consistent with the Foundation's purpose to establish 
a Project Management Committee charged with the creation and maintenance 
of open-source software, for distribution at no charge to the public, 
related to the OpenOffice personal productivity applications.


NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee 
(PMC), to be known as the "Apache OpenOffice Project", be and hereby is 
established pursuant to Bylaws of the Foundation; and be it further


RESOLVED, that the Apache OpenOffice Project be and hereby is 
responsible for the creation and maintenance of software related to the 
OpenOffice personal productivity applications; and be it further


RESOLVED, that the office of "Vice President, OpenOffice" be and hereby 
is created, the person holding such office to serve at the direction of 
the Board of Directors as the chair of the Apache OpenOffice Project, 
and to have primary responsibility for management of the projects within 
the scope of responsibility of the Apache OpenOffice Project; and be it 
further


RESOLVED, that the persons listed immediately below be and hereby are 
appointed to serve as the initial members of the Apache OpenOffice Project:


* Andre Fischer (af)
* Andrea Pescetti (pescetti)
* Andrew Rist (arist)
* Ariel Constenla-Haile (arielch)
* Armin Le Grand (alg)
* Dave Fisher (wave)
* Donald Harbison (dpharbison)
* Drew Jensen (atjensen)
* Ian Lynch (ingotian)
* Jürgen Schmidt (jsc)
* Kay Schenk (kschenk)
* Kazunari Hirano (khirano)
* Louis Suarez-Potts (louis)
* Marcus Lange (marcus)
* Oliver-Rainer Wittmann (orw)
* Pedro Giffuni (pfg)
* Peter Junge (pj)
* Raphael Bircher (rbircher)
* Regina Henschel (regina)
* RGB.ES (rgb-es)
* Roberto Galoppini (galoppini)
* Yang Shih-Ching (imacat)
* Yong Lin Ma (mayongl)

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Andrea Pescetti be 
appointed to the office of Vice President, OpenOffice, to serve in 
accordance with and subject to the direction of the Board of Directors 
and the Bylaws of the Foundation until death, resignation, retirement, 
removal or disqualification, or until a successor is appointed; and be 
it further


RESOLVED, that the initial Apache OpenOffice Project be and hereby is 
tasked with the creation of a set of bylaws intended to encourage open 
development and increased participation in the OpenOffice Project; and 
be it further


RESOLVED, that the Apache OpenOffice Project be and hereby is tasked 
with the migration and rationalization of the Apache OpenOffice.org 
podling; and be it further


RESOLVED, that all responsibilities pertaining to the Apache Incubator 
OpenOffice.org podling encumbered upon the Apache Incubator Project are 
hereafter discharged.

  ---

Regards,
  Andrea.

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

Re: [VOTE] Recommend to the Board to establish the Apache OpenOffice Project

[Christian Grobmeier]

+1 (mentor)

Good luck!

On Wed, Oct 10, 2012 at 9:00 PM, Andrea Pescetti  wrote:
> Seeing no objections to my last message, and keeping into account that this
> list had been regularly informed about the steps Apache OpenOffice was
> taking towards graduation, I'm hereby asking the IPMC to recommend the
> following resolution to the Board. Aim of the resolution is to establish the
> Apache OpenOffice Project as a Top Level Project.
>
> Please cast your vote:
>
> [ ] +1, recommend the resolution to the Board
> [ ] +0, abstain/don't care
> [ ] -1, do not recommend the resolution to the Board, because...
>
> This vote will be open for 72 hours from now; only votes from the Incubator
> PMC are binding.
>
> Resolution text:
>   ---
> WHEREAS, the Board of Directors deems it to be in the best interests of the
> Foundation and consistent with the Foundation's purpose to establish a
> Project Management Committee charged with the creation and maintenance of
> open-source software related to the OpenOffice personal productivity
> applications, for distribution at no charge to the public.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC),
> to be known as the "Apache OpenOffice Project", be and hereby is established
> pursuant to Bylaws of the Foundation; and be it further
>
> RESOLVED, that the Apache OpenOffice Project be and hereby is responsible
> for the creation and maintenance of software related to the OpenOffice
> personal productivity applications; and be it further
>
> RESOLVED, that the office of "Vice President, OpenOffice" be and hereby is
> created, the person holding such office to serve at the direction of the
> Board of Directors as the chair of the Apache OpenOffice Project, and to
> have primary responsibility for management of the projects within the scope
> of responsibility of the Apache OpenOffice Project; and be it further
>
> RESOLVED, that the persons listed immediately below be and hereby are
> appointed to serve as the initial members of the Apache OpenOffice Project:
>
> * Andre Fischer (af)
> * Andrea Pescetti (pescetti)
> * Andrew Rist (arist)
> * Ariel Constenla-Haile (arielch)
> * Armin Le Grand (alg)
> * Dave Fisher (wave)
> * Donald Harbison (dpharbison)
> * Drew Jensen (atjensen)
> * Ian Lynch (ingotian)
> * Jürgen Schmidt (jsc)
> * Kay Schenk (kschenk)
> * Kazunari Hirano (khirano)
> * Louis Suarez-Potts (louis)
> * Marcus Lange (marcus)
> * Oliver-Rainer Wittmann (orw)
> * Pedro Giffuni (pfg)
> * Peter Junge (pj)
> * Raphael Bircher (rbircher)
> * Regina Henschel (regina)
> * RGB.ES (rgb-es)
> * Roberto Galoppini (galoppini)
> * Yang Shih-Ching (imacat)
> * Yong Lin Ma (mayongl)
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Andrea Pescetti be appointed to
> the office of Vice President, OpenOffice, to serve in accordance with and
> subject to the direction of the Board of Directors and the Bylaws of the
> Foundation until death, resignation, retirement, removal or
> disqualification, or until a successor is appointed; and be it further
>
> RESOLVED, that the initial Apache OpenOffice Project be and hereby is tasked
> with the creation of a set of bylaws intended to encourage open development
> and increased participation in the OpenOffice Project; and be it further
>
> RESOLVED, that the Apache OpenOffice Project be and hereby is tasked with
> the migration and rationalization of the Apache OpenOffice.org podling; and
> be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache Incubator
> OpenOffice.org podling encumbered upon the Apache Incubator Project are
> hereafter discharged.
>   ---
> Best regards,
>   Andrea Pescetti - Apache OpenOffice PPMC.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
http://www.grobmeier.de
https://www.timeandbill.de

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

Re: [VOTE] Graduate Cordova podling from Apache Incubator

[Ross Gardler]

+1 (mentor)

Sent from my tablet
On Oct 10, 2012 12:25 AM, "Steven Gill"  wrote:

> This is a call for vote to graduate the Cordova podling from Apache
> Incubator.
>
> Cordova entered the Incubator in October of 2011. We have made significant
> progress with the project since moving over to Apache. We have 30
> committers listed on our status page at [1]. We made our first official
> Cordova release last month. Results for that vote can be viewed at [2]. We
> have also added support for new platforms such as Tizen, Windows, Windows
> Phone 8 and more. You can view all of our repos at [3].
>
> The community of Cordova is active, healthy and growing and has
> demonstrated the ability to self-govern using accepted Apache practices.
>
> The Apache Cordova community are under consensus that we are ready to
> graduation. You can view the discussion at [4].
>
> We have prepared and reviewed our charter. You can view it at [5].
>
> Please cast your votes:
>
> [ ] +1 Graduate Isis podling from Apache Incubator [ ] +0 Indifferent to
> the graduation status of Isis podling [ ] -1 Reject graduation of Isis
> podling from Apache Incubator because ...
>
> This vote will be open for at least 72 hours.
>
>
> [1] http://incubator.apache.org/projects/callback.html
> [2] http://markmail.org/message/g5g32hnh223gj34m
> [3] https://git-wip-us.apache.org/repos/asf
> [4] http://markmail.org/message/3bcttovgyjrypiq4
> [5] http://wiki.apache.org/cordova/Draft%20Charter
>
> Cheers,
> -Steve Gill
>

Re: [VOTE] Recommend to the Board to establish the Apache OpenOffice Project

[Ross Gardler]

+1 (mentor)

Sent from my tablet
On Oct 10, 2012 9:00 PM, "Andrea Pescetti"  wrote:

> Seeing no objections to my last message, and keeping into account that
> this list had been regularly informed about the steps Apache OpenOffice was
> taking towards graduation, I'm hereby asking the IPMC to recommend the
> following resolution to the Board. Aim of the resolution is to establish
> the Apache OpenOffice Project as a Top Level Project.
>
> Please cast your vote:
>
> [ ] +1, recommend the resolution to the Board
> [ ] +0, abstain/don't care
> [ ] -1, do not recommend the resolution to the Board, because...
>
> This vote will be open for 72 hours from now; only votes from the
> Incubator PMC are binding.
>
> Resolution text:
>   ---
> WHEREAS, the Board of Directors deems it to be in the best interests of
> the Foundation and consistent with the Foundation's purpose to establish a
> Project Management Committee charged with the creation and maintenance of
> open-source software related to the OpenOffice personal productivity
> applications, for distribution at no charge to the public.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC),
> to be known as the "Apache OpenOffice Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
>
> RESOLVED, that the Apache OpenOffice Project be and hereby is responsible
> for the creation and maintenance of software related to the OpenOffice
> personal productivity applications; and be it further
>
> RESOLVED, that the office of "Vice President, OpenOffice" be and hereby is
> created, the person holding such office to serve at the direction of the
> Board of Directors as the chair of the Apache OpenOffice Project, and to
> have primary responsibility for management of the projects within the scope
> of responsibility of the Apache OpenOffice Project; and be it further
>
> RESOLVED, that the persons listed immediately below be and hereby are
> appointed to serve as the initial members of the Apache OpenOffice Project:
>
> * Andre Fischer (af)
> * Andrea Pescetti (pescetti)
> * Andrew Rist (arist)
> * Ariel Constenla-Haile (arielch)
> * Armin Le Grand (alg)
> * Dave Fisher (wave)
> * Donald Harbison (dpharbison)
> * Drew Jensen (atjensen)
> * Ian Lynch (ingotian)
> * Jürgen Schmidt (jsc)
> * Kay Schenk (kschenk)
> * Kazunari Hirano (khirano)
> * Louis Suarez-Potts (louis)
> * Marcus Lange (marcus)
> * Oliver-Rainer Wittmann (orw)
> * Pedro Giffuni (pfg)
> * Peter Junge (pj)
> * Raphael Bircher (rbircher)
> * Regina Henschel (regina)
> * RGB.ES (rgb-es)
> * Roberto Galoppini (galoppini)
> * Yang Shih-Ching (imacat)
> * Yong Lin Ma (mayongl)
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Andrea Pescetti be appointed
> to the office of Vice President, OpenOffice, to serve in accordance with
> and subject to the direction of the Board of Directors and the Bylaws of
> the Foundation until death, resignation, retirement, removal or
> disqualification, or until a successor is appointed; and be it further
>
> RESOLVED, that the initial Apache OpenOffice Project be and hereby is
> tasked with the creation of a set of bylaws intended to encourage open
> development and increased participation in the OpenOffice Project; and be
> it further
>
> RESOLVED, that the Apache OpenOffice Project be and hereby is tasked with
> the migration and rationalization of the Apache OpenOffice.org podling; and
> be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache Incubator
> OpenOffice.org podling encumbered upon the Apache Incubator Project are
> hereafter discharged.
>   ---
> Best regards,
>   Andrea Pescetti - Apache OpenOffice PPMC.
>
> --**--**-
> To unsubscribe, e-mail: 
> general-unsubscribe@incubator.**apache.org
> For additional commands, e-mail: 
> general-help@incubator.apache.**org
>
>

Re: key signing

[Branko Čibej]

On 10.10.2012 00:01, Marvin Humphrey wrote:
> While this protocol does not rely heavily on validating
> government-issued IDs, the Debian guidelines quoted above point out
> that some people object to giving such IDs too much creedence:

So instead of giving too much credence to government-issued IDs, you'd
prefer to give credence to a service provided "for free" by a commercial
entity with a conceivable interest in inserting backdoors in software or
subverting trust in certain keys (a.k.a. Google), with the whole thing
being archived in as system controlled by another commercial entity
(a.k.a. YouTube, incidentally a.k.a. Google), with no public oversight
of those archives.

I'm sure you'd sue Google and win if they fake the archive.

-- Brane


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