Re: Notes on branding

[Tim Williams]

On Fri, Jul 1, 2016 at 9:43 PM, John D. Ament  wrote:
> Mike,
>
>
> On Fri, Jul 1, 2016 at 9:12 PM Mike Jumper  wrote:
>
>> On Fri, Jul 1, 2016 at 3:44 PM, Gunnar Tapper 
>> wrote:
>>
>> > Let me offer up a concrete example since I struggle with the issue of
>> > branding: http://trafodion.apache.org/documentation.html
>> >
>> > I chose the following approach based on input from out mentor Stack:
>> >
>> > - Added (incubator) to the menu bar
>> > - Added the incubator logo on the top of the page
>> > - Placed the disclaimer on the bottom of the page
>> >
>> > I did you placeholders in the documentation for things like mailing list,
>> > project names, and cross-documentation links to make renaming a matter of
>> > updating pom.xml files and rebuilding.
>> >
>> > However, I did NOT put incubator disclaimers or even an incubator status
>> in
>> > the documentation simply because it felt like over communication of
>> > incubator status. As you'll see, the Apache license language is included
>> in
>> > PDF and web-book formats but not the incubator disclaimer. I don't know
>> > whether I made the right choice. If I didn't, then I'd think that the
>> > guidance should state that web pages and documentation should include
>> BOTH
>> > the ASL text and the incubator-disclaimer text.
>> >
>> > I hope this helps with the discussion.
>> >
>> > Thanks,
>> >
>> > Gunnar
>> >
>> > On Fri, Jul 1, 2016 at 1:31 PM, Mike Jumper 
>> > wrote:
>> >
>> > > On Fri, Jul 1, 2016 at 12:05 PM, Marvin Humphrey <
>> mar...@rectangular.com
>> > >
>> > > wrote:
>> > >
>> > > > On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase 
>> wrote:
>> > > >
>> > > > > The branding guidelines do not address feedback such as "logo in
>> > > footer"
>> > > > or
>> > > > > "disclaimer is buried deep or below the fold".
>> > > >
>> > > > Incubation disclaimers are intended to be substantive.  They are not
>> > CYA
>> > > > legal
>> > > > boilerplate that can be are buried in fine print. The intent is to
>> > > > communicate
>> > > > (effectively!) to consumers that a project is incubating. That way,
>> > > people
>> > > > will know that certain caveats apply:
>> > > >
>> > > > Apache Foo is an effort undergoing incubation at The Apache
>> > Software
>> > > > Foundation (ASF), sponsored by the Apache Incubator.  Incubation
>> is
>> > > > required of all newly accepted projects until a further review
>> > > > indicates
>> > > > that the infrastructure, communications, and decision making
>> > process
>> > > > have
>> > > > stabilized in a manner consistent with other successful ASF
>> > projects.
>> > > > While incubation status is not necessarily a reflection of the
>> > > > completeness or stability of the code, it does indicate that the
>> > > > project
>> > > > has yet to be fully endorsed by the ASF.
>> > > >
>> > > > What would be best is if podlings just understood that intent, and as
>> > and
>> > > > took
>> > > > it upon themselves to ensure that their incubating status was
>> > > communicated
>> > > > effectively -- in websites, in release announcements, etc.
>> > > >
>> > > >
>> > > Can you cite, as an example, an incubating project's website where you
>> > > would consider the incubating status effectively communicated, and the
>> > > disclaimer not buried?
>> > >
>> >
>> >
>> >
>> > --
>> > Thanks,
>> >
>> > Gunnar
>> > *If you think you can you can, if you think you can't you're right.*
>> >
>>
>> John and/or Roman, can you comment specifically on how the results of the
>> branding audit [1] should be interpreted by the podlings concerned, and
>> (please) provide some concrete examples of what podlings should and
>> shouldn't do with respect to the audit?
>>
>
> I would say that for now, podlings should take no action unless they are
> contacted directly to fix something about their branding.  I jumped the gun
> a little on contacting a few podlings that seemed to be way out, but were
> not actually against our current branding guidelines.  According to the
> list I put together, there are eight that are not in compliance at all with
> the established policies.  That policy being that you must include the
> disclaimer, and it must be worded in a specific way.
>
> I asked a few podlings to add the incubator logo.  This was mostly because
> most links to the podling were not using the incubator domain.
>
>
>>
>> Where is the threshold between "Present, in footer, smaller font" and the
>> much more colorful "Buried in footer"? Are not footers generally expected
>> to be in a smaller font?
>>
>
> Not saying that at all.  The thing I'm trying to weigh is how easily can I
> discern whether this project is fully vetted or not.
>
> If you take Wave for example, while its at the bottom of the page, their
> entire page fits within the fold.  If you take Guacamole as another
> example, the placement makes 

Re: Notes on branding

[Tim Williams]

On Fri, Jul 1, 2016 at 3:05 PM, Marvin Humphrey  wrote:
> On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase  wrote:
>
>> The branding guidelines do not address feedback such as "logo in footer" or
>> "disclaimer is buried deep or below the fold".
>
> Incubation disclaimers are intended to be substantive.  They are not CYA legal
> boilerplate that can be are buried in fine print. The intent is to communicate
> (effectively!) to consumers that a project is incubating.

I haven't heard anyone suggesting "CYA" or "buried in fine print"?
Most sites put notices at the bottom of a page similar to how we put
our equally important copyright/trademark notices at the bottom of our
home page.  That, along with having the page saying "(Incubating)" all
over the place is surely enough of a notice... this "must be above the
fold" stuff is overreaching and encroaching on the PPMC.  They have
the disclaimer, let's not overcome our boredom by being helicopter
parents...

--tim

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

Re: Policy should be simple (was "Allowed Champions on podlings")

[Tim Williams]

is this just personal catharsis?

On Tue, Mar 22, 2016 at 4:19 PM, Marvin Humphrey  wrote:
> On Mon, Mar 21, 2016 at 9:57 AM, Craig Russell  
> wrote:
>> There is a sorta technical reason for the Champion to be a member of the PMC
>> of the sponsor.
>>
>> I’d expect the Champion to subscribe to the private@ list and to have
>> binding votes on podling releases. These both require PMC membership.
>>
>> The alternative is to create two different “exceptions” that would allow
>> Champions to subscribe to private@ and to have binding release votes.
>
> These are legitimate concerns that would need to be dealt should such an
> unlikely scenario arise.  However, I don't think we need to carve exceptions
> into policy here -- other creative solutions are available, like voting the
> Champion onto the Sponsor PMC.
>
> And I'd like to take this opportunity to make a more general point:
>
> Policy should be simple.
>
> There are many reasons that policy should be simple, and I'm sure others will
> be happy to weigh in with their own favorites.  But for me, this is the
> most compelling:
>
> Complexity harms newcomers.
>
> Right now, Apache's rules are so complex that we are all in perpetual
> violation.  You can't even know what all the rules are!
>
> In such an environment, success is dependent, not on your own ability, but on
> securing alliances with powerful insiders who can help you bend or break
> the rules.
>
> This state of affairs is not worthy of our core principles.  Particularly
> since the ASF does not exercise technical control over its projects, what we
> do here is not really that complicated.
>
> Apache, and the Incubator in particular, welcomes newcomers.  It should be
> possible for a newcomers to discover and follow our rules largely through
> their own efforts.
>
> Of course a rejoinder to "Policy should be simple" is "As simple as possible
> and no simpler".  But how close are we to "as simple as possible"?
>
> 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: Allowed Champions on podlings

[Tim Williams]

On Fri, Mar 18, 2016 at 12:33 AM, John D. Ament  wrote:
> All,
>
> It was recently pointed out that some of our docs are a bit inconsistent
> around who can champion a candidate podling.
>
> http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Champion
> http://incubator.apache.org/incubation/Incubation_Policy.html#Champion
>
> In the former, officers and members are allowed to, but in the latter only
> members.  I'd like to propose to make these two consistent, and allow both
> officers and members to be champions.  I'll make this change in about 72
> hours via lazy consensus unless someone comes up with a $reason why it
> should be members only.

Without judging the goodness of it... I'd just point out that
currently in the non-Member Officer case, they must be a member of the
Sponsoring PMC.  I thought that was true of Members as well, btw, but
thought I'd point out that it's not simply Members and Officers.

--tim

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

Re: DRAFT report February 2016 -- please review

[Tim Williams]

On Thu, Feb 11, 2016 at 12:40 AM, Marvin Humphrey <mar...@rectangular.com>
wrote:

> > 
> > Blur
> >
> > Blur is a search platform capable of searching massive amounts of data
> > in a cloud computing environment.
> >
> > Blur has been incubating since 2012-07-24.
> >
> > Three most important issues to address in the move towards graduation:
> >
> >   1. Greater community involvement.
> >   2. Produce releases.
> >   3.
> >
> > Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
> > aware of?
> >
> >  - No
> >
> > How has the community developed since the last report?
> >
> >  - Subscriptions: user@ - 56[+1]; dev@ - 72[+2]
> >  - The community involvement has not really changed over the past few
> >months.
> >
> > How has the project developed since the last report?
> >
> >  - The software has a few additional features, and bug fixes.
> >
> > Date of last release:
> >
> >   2014-07-29
> >
> > When were the last committers or PMC members elected?
> >
> >   2014-07-28
> >
> > Signed-off-by:
> >
> >   [ ](blur) Doug Cutting
> >   [X](blur) Patrick Hunt
> >   [ ](blur) Tim Williams
> >
> > Shepherd/Mentor notes:
>
> Blur has now been incubating for a while: 3 1/2 years.  The Incubator has a
> lot of podlings right now and at some point there's going to be an "up or
> out"
> push.  What is holding back Blur from graduation and how can progress be
> expedited?
>

Hi Marvin,
As the report mentions, community growth/involvement is the most
important/only issue holding Blur back from graduating.  I think a key
ingredient to progress on this could be someone stepping up to give some
"Intro to Blur" presentations (or some other outreach) to get the name out
there as an alternative to the other two popular search systems, which has
only happened sporadically thus far.

I must have missed an IPMC discussion of an "up or out" push somewhere... I
think it's a fair nudge in any case.  I'll take it back to the Blur list
and see if we can come up with a plan either way...

Thanks,
--tim

Re: [PORPOSAL] Fineract

[Tim Williams]

On Fri, Dec 4, 2015 at 11:10 AM, Ross Gardler
 wrote:
> I'm replying top of thread as this is a general reply regarding mentors.
>
> We just added Greg Stein as a third mentor. He wasn't on the originally 
> submitted proposal as he was just checking on availability before confirming.
>
> Based on recent conversations in the IPMC I (as champion) advised the project 
> stick to a single mentor who was willing to put his/her head on the block. 
> This individual would take full responsibility for rapid turnaround on all 
> items needing mentor feedback. However, the team had already discussed the 
> proposal with a number of other people. As a result they feel that 3 mentors 
> is appropriate, respecting both IPMC traditions and those already advising 
> the community. Hence we have three mentors. We are not seeking more.

This isn't about "seeking more" - literally a perfectly qualified
[potential] mentor fell in your lap.  Do what you want, this just
feels incredibly counter-cultural to me - that is, to actively turn
away an eminently qualified volunteer.  I think it's both unwise in
this specific instance and a poor example to hint that its
acceptable/desirable in general.

Anyway, best wishes to Fineract...

Thanks,
--tim

** Just to be clear, I'm well aware that the other three mentors are
rock solid as well:)

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

Re: [PORPOSAL] Fineract

[Tim Williams]

On Sat, Dec 5, 2015 at 12:41 PM, Ross Gardler
 wrote:
> Nobody is turned away.

Jedi mind tricks won't work on me Ross:)  When someone says, "We are
not seeking more." it is the same as being turned away.

For the rest of it, I reckon we'll have to agree to disagree.  The
bottom line is, someone [Jim] who's eminently qualified to help mentor
a new group of folks volunteered.  It's fair to assume that he, I, and
you understand that he understood what that role was when he
volunteered.

>Mentors don't do the work. Contributors do. Mentors do not make decisions. 
>Contributors so. Mentors have " binding votes" but that is just because of the 
>structure we have in the ASF, a good mentor will only ever use that vote to 
>enact the wishes of the community.

I understand just as well as you how things work Ross. Please check
yourself before going into condescending-lecture-mode, it's remarkably
uncool and uninviting. As a dood, its really weird to be mansplained
to!  But, thanks Champ!

> This is the opposite of "counter cultural".

Which would be... cultural?  Meaning, you're suggesting it's the norm
to turn away ridiculously qualified volunteers for a particular role
in a community?

> Contributors are what matter not mentors.

Seems another mind trick.  While in incubation mentors are
contributors - contributors to cultural understanding.  They
contribute to helping a podling bootstrap in our infrastructure and
grok the Apache Way.  To turn away a potential mentor is to turn away
a contributor.  Ignoring a mentor's impact/contributions to a
community seems naive at best.

Regardless of the semantics, on a practical level, a person like Jim
shows up offering to help a new community understand how to develop
community-driven software, I say *you take the help*.  Period.  Same
for Greg, which you apparently agreed based on some arbitrary N<=3.

Again, I wish you and Fineract the best...

--tim

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

Re: [PORPOSAL] Fineract

[Tim Williams]

On Fri, Dec 4, 2015 at 1:37 PM, Markus Geiß  wrote:
> Hey Pierre, James, Jim
>
> thanks for your interest in mentoring, we will talk about that with our
> current mentors to see what will be a good number of overall mentors for
> the project.

Prolly your mentors will say that if Jim offers to help, you should
readily accept:)

--tim

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

Re: Mentor disengagement - a suggestion

[Tim Williams]

On Mon, Oct 12, 2015 at 6:37 PM, Sam Ruby  wrote:
> On Mon, Oct 12, 2015 at 11:06 AM, Rich Bowen  wrote:
>>
>> On 10/12/2015 10:10 AM, Emmanuel Lécharny wrote:
>>>
>>> Regarding inactive mentors, this is quite simple : we have a monthly
>>> report that has to be signed off by mentors, if one mentor does not sign
>>> it three time in a raw, shouldn't we consider that this mentor has
>>> already stepped down ?
>>
>> No, it's not simple. Actively removing people from volunteer roles is much
>> more complicated than you might suppose. I'd rather focus on making myself a
>> better mentor than any measures against other mentors which might be seen as
>> punitive.
>
> Getting some things out of the way:
>
> I agree that it is not simple.  I agree that it is complicated.  I
> disagree that it needs to be viewed as punitive.  I suggest it would
> be worthwhile to do.  I respect that this may not be something you
> personally would want to volunteer for.  I believe that you can't fix
> what you don't measure.  I acknowledge that measuring may lead to
> gaming, though in this case I think the rewards are so vanishingly
> small that that is unlikely to be a major issue.
>
> Whew!
>
> Now on to the substance of my reply:
>
> https://whimsy.apache.org/incubator/signoff

Hi Sam,
A small request - any chance you can adjust the colors for that page?
David added some notes to Clutch[1] for details but I reckon
#009e73 and #d55e00 would be better.

Thanks,
--tim

[1] - http://incubator.apache.org/clutch.html#notes-cud

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

Re: Mentor disengagement - a suggestion

[Tim Williams]

On Tue, Oct 13, 2015 at 2:32 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> On Tue, Oct 13, 2015 at 8:28 AM, Tim Williams <william...@gmail.com> wrote:
>> On Mon, Oct 12, 2015 at 6:37 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>>> On Mon, Oct 12, 2015 at 11:06 AM, Rich Bowen <rbo...@rcbowen.com> wrote:
>>>>
>>>> On 10/12/2015 10:10 AM, Emmanuel Lécharny wrote:
>>>>>
>>>>> Regarding inactive mentors, this is quite simple : we have a monthly
>>>>> report that has to be signed off by mentors, if one mentor does not sign
>>>>> it three time in a raw, shouldn't we consider that this mentor has
>>>>> already stepped down ?
>>>>
>>>> No, it's not simple. Actively removing people from volunteer roles is much
>>>> more complicated than you might suppose. I'd rather focus on making myself 
>>>> a
>>>> better mentor than any measures against other mentors which might be seen 
>>>> as
>>>> punitive.
>>>
>>> Getting some things out of the way:
>>>
>>> I agree that it is not simple.  I agree that it is complicated.  I
>>> disagree that it needs to be viewed as punitive.  I suggest it would
>>> be worthwhile to do.  I respect that this may not be something you
>>> personally would want to volunteer for.  I believe that you can't fix
>>> what you don't measure.  I acknowledge that measuring may lead to
>>> gaming, though in this case I think the rewards are so vanishingly
>>> small that that is unlikely to be a major issue.
>>>
>>> Whew!
>>>
>>> Now on to the substance of my reply:
>>>
>>> https://whimsy.apache.org/incubator/signoff
>>
>> Hi Sam,
>> A small request - any chance you can adjust the colors for that page?
>> David added some notes to Clutch[1] for details but I reckon
>> #009e73 and #d55e00 would be better.
>
> I did a small amount of research, and made a different color
> choice[2].  For extra measure, I varied both the font-weight and
> font-style.  Let me know if this doesn't work for you.

That's fantastic!  Thanks for taking the extra time Sam, it's just
great to see a distinction.

Thanks again,
--tim

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

Re: A question: Is it alright to say no to potential podlings?

[Tim Williams]

On Tue, Oct 13, 2015 at 2:32 PM, Andrew Bayer  wrote:
> But - and I wanna be very clear that this is a hypothetical - if I were to
> still have significant concerns (either ones that weren't addressed in the
> DISCUSS thread or I missed the DISCUSS thread, etc), it'd still be socially
> permissible (not just procedurally permissible) to -1 a VOTE? I ask 'cos,
> well, I'm easily cowed by social pressure on this sort of thing, so bucking
> the herd isn't easy. If I feel that a potential podling has reached VOTE
> stage while still having issues that in my mind make it a bad candidate to
> enter the Incubator, I want to be sure I can still -1 it without being
> turned into a pariah in the process. =)

Yes, as an example, take a look at the OpenOffice vote[1] that Nick referred to.

Thanks,
--tim

[1] - 
http://mail-archives.apache.org/mod_mbox/incubator-general/201106.mbox/%3cbanlktinv5a3zpk_9fwhgg8wc3qmafkr...@mail.gmail.com%3E

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

Re: Incubator PMC/Board report for Oct 2015 ([ppmc])

[Tim Williams]

On Tue, Oct 13, 2015 at 5:10 PM, Ted Dunning  wrote:
> It isn't OK. It may have to happen, but it isn't really OK.

Looks like this got written, but I'm not sure why such an unforgiving
stance - this happens fairly often on TLPs and the board is always
gracious and understanding.

Thanks,
--tim

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

Re: [VOTE] Release Blur version 0.2.4-incubating RC1

[Tim Williams]

Thanks for taking the time to review Justin, we appreciate it.

On Fri, Jul 17, 2015 at 8:01 PM, Justin Mclean jus...@classsoftware.com wrote:
 Hi,

 Sorry but it’s -1 (binding) until the MPL issue can be resolved / explained, 
 other issues can be fixed next release. For the MPL issue it may be that For 
 small amounts of source that is directly consumed by the ASF product at 
 runtime in source form” may apply. [2]

I think we just missed it, based on the example, I don't think we can
use that escape-clause/rationale for its inclusion.  We should take it
back to the dev list at this point.

 For the source release I checked:
 - filename contains incubating
 - signatures and hashes good
 - DISCLAIMER exists
 - LICENSE has minor issues + MPL issue [2]
 - NOTICE good
 - Some unexpected binaries in source (see below)
 - All source file have headers
 - Can compile form source?

 LiCENSE is missing:
  - MIT licensed normalize.css (see 
 ./apache-blur-0.2.4-incubating-src/blur-console/src/main/webapp/public/css/blurconsole.css
  + 
 ./apache-blur-0.2.4-incubating-src/blur-console/src/main/webapp/libs/bootstrap/less/normalize.less)
 - MIT/BSD licensed polyfill (see ./docs/resources/js/respond.min.js)

 There is an issue with 
 ./blur-console/src/main/webapp/libs/tagmanager/tagmanager.js as this is MPL 
 licensed [2] which is weak copy left and considered a category B license. In 
 this case it looks like it isn’t been handled correctly as it being included 
 in source not binary form. I’m not sure how this should be handled given 
 there is no compiled JS form.


 There are a couple of test files that contain compiled code, can this be 
 produced via the build process?
 ./blur-core/src/test/resources/org/apache/blur/command/test1/test1.jar
 ./blur-core/src/test/resources/org/apache/blur/command/test2/test2.jar

Yeah, these were just to drive some tests but I reckon we should craft
another way that ships in source form.

 Something a little odd that caught my eye is all of the 
 ./distribution/src/main/resources-hadoop1/notices/*.jar.src files. Is there 
 any reason for these files to be in the source release? It look that they are 
 used to generate the binary NOTICE file?


They're sources needed to produce a [valid] binary package so it
seemed reasonable to me include them.

 For the binary release you may want to check the LICENSE as it is identical 
 to the source release [3]. For the binary NOTICE file a minor issue in that 
 there is no need to repeat This product includes software developed by The 
 Apache Software Foundation “ [4].

 Re compiling from source some instructions in the README would be helpful as 
 it seems a mvn install in the top directory may not do what is expected. (As 
 far as I can see it seems to be doing a rat check and nothing else?)

Yeah, we should add something to the README that hints at the
quickstart or profiles: mvn install -Dhadoop2

Thanks again for taking your time...

Thanks,
--tim

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

Re: [DRAFT] May 2015 Board Report

[Tim Williams]

 report?
 
The SGA has been signed and the code has been imported.
More discussions happen on the Apache lists now.
 
  How has the project developed since the last report?
 
SGA and code drop done, need to get the site (and maybe the Wiki) up as
well.
 
  Date of last release:
 
No Releases yet.
 
  When were the last committers or PMC members elected?
 
No elected PMC and/or committers
 
  Signed-off-by:
 
[x](asterixdb) Ate Douma
[x](asterixdb) Chris Mattmann
[x](asterixdb) Henry Saputra
[x](asterixdb) Jochen Wiedmann
[x](asterixdb) Ted Dunning
 
  Shepherd/Mentor notes:
 
 
 
  
  Blur
 
  Blur is a search platform capable of searching massive amounts of data
  in a cloud computing environment.
 
  Blur has been incubating since 2012-07-24.
 
  Three most important issues to address in the move towards graduation:
 
1.  We anticipate pursuing graduation after our upcoming release.
2.
3.
 
  Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
  aware of?
 
  None.
 
  How has the community developed since the last report?
 
- Subscriptions: user@ - 57[-3]; dev@ - 67[+1]
 
  How has the project developed since the last report?
 
  Many bug fixes related to stability and bulk incremental ingestion.
 
  Date of last release:
 
2014-07-29
 
  When were the last committers or PMC members elected?
 
2014-07-28
 
  Signed-off-by:
 
[ ](blur) Doug Cutting
[X](blur) Patrick Hunt
[X](blur) Tim Williams
 
  Shepherd/Mentor notes:
 
 
 
  
  CommonsRDF
 
  Commons RDF is a set of interfaces and classes for RDF 1.1 concepts and
  behaviours.  The commons-rdf-api module defines interfaces and testing
  harness.  The commons-rdf-simple module provides a basic reference
  implementation to exercise the test harness and clarify API contracts.
 
  CommonsRDF has been incubating since 2015-03-06.
 
  Three most important issues to address in the move towards graduation:
 
1. Grow the CommonsRDF Community such that we can progress
   towards graduation
2. Further engage the podling with the nuances of the Apache
   Incubation process
3. Drive towards the first incubating release
 
  Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
  aware of?
 
Peter Ansell resigned from the PPMC, but remains affiliated with the
project.
 
  How has the community developed since the last report?
 
Development and coding practices agreed.
Newcomers are joining discussions, adding feature requests.
 
Mailing list subscribers numbers were not included in last report.
  Numbers
for April 2015:
 
dev@  == 16 subscribers, 333 messages
commits@  == 9 subscribers, 248 messages
 
  How has the project developed since the last report?
 
There has been a bunch of development activity going on at CommonsRDF
  with
over 200 dev@ messages in March and 300 in April.  Website and
documentation established at http://commonsrdf.incubator.apache.org.
  All
project communication and development has been migrated to Apache
Infrastructure.  The project has been introduced to the W3C Data on the
Web Best Practices Working Group to increase the community.  There is
  also
an ongoing thread relating to the first project incubating release
 with a
release candidate currently being voted on.
 
  Date of last release:
 
-XX-XX
 
  When were the last committers or PMC members elected?
 
N/A
 
  Signed-off-by:
 
[X](commonsrdf) Rob Vesse
[X](commonsrdf) John D Ament
[ ](commonsrdf) Gary Gregory
[X](commonsrdf) Lewis J. McGibbney (Champion)
[X](ipmc)   Chris Mattmann
 
  Shepherd/Mentor notes:
 
Chris Mattmann:
Peter Ansell's resignation from the IPMC isn't related to this project,
right?
Rob Vesse:
Peter Ansell's resignation was due to frustrations at the speed of
  progress particularly
around some technical discussions that he had felt had previously been
  resolved prior to this
project entering the Incubator and so he has chosen to focus his
 efforts
  on other projects.
The project does seem to now have resolved those issues and has been
 able
  to move forward
with a first release candidate.
John Ament:
Peter Ansell resigned from the PPMC/Podling, not the IPMC.
 
 
  
  Droids
 
  Droids aims to be an intelligent standalone robot framework that allows
 to
  create and extend existing droids (robots).
 
  Droids has been incubating since 2008-10-09.
 
  Three most important issues to address in the move towards graduation:
 
1. Activity
2. Name Search
 
  Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
  aware of?
 
None.
 
Name search needs to be concluded. Availability looks better this
 quarter
for completing that task.
 
  How has the community developed since the last

Re: [DRAFT] May 2015 Board Report

[Tim Williams]

On Mon, May 11, 2015 at 11:49 PM, Dave Lester d...@davelester.org wrote:
 Hi Tim,

 I found Konstantin's comment to be helpful. Could it have provided
 additional details? Sure. But I don't think there's a need to make this
 personal. Shepherd comments tend to be quite brief.

 We should celebrate volunteer efforts instead of calling others
 unhelpful and lazy.

FWIW, those adjectives were describing the quality of the work - not
the person.  Mediocre, again, was descriptive of the work/comments,
not the person. I don't think Cos, the person, is lazy, unhelpful, and
he's certainly not mediocre:)  Anyway, I didn't mean to make it
personal - it was an honest assessment of the work, that's all...

--tim

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

Re: [DRAFT] May 2015 Board Report

[Tim Williams]

On Mon, May 11, 2015 at 10:11 PM, Konstantin Boudnik c...@apache.org wrote:

 - Blur:  Human activity on Dev list is almost zero: high 90% of the emails 
 are from CI system or JIRA notificaitons.

Human's drive nearly all of that traffic.  What is your point?
Honestly, this shepherd comment seems unhelpful and lazy.  I'd suggest
it's better to admit that you've run out of time than offer mediocre
shepherd comments.

--tim

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

Re: P. An Excessive Fascination with the Apache Brand

[Tim Williams]

On Mon, Dec 22, 2014 at 8:21 AM, Jim Jagielski j...@jagunet.com wrote:
 I was wondering... What we *REALLY* want are projects
 that are interested more in The Apache Way than in the
 Apache Brand. We need to make it more clear, somehow,
 that new projects want to enter the ASF because they
 approve of, and want to follow, the *how* of creating
 projects and communities. Lately, it appears, that we
 have graduated projects which are more interested in
 simply being able to add 'Apache' to their name, and
 then deride/minimize/ignore/dispute most/all of the
 aspects of The Apache Way which is what made the Apache
 brand so valuable and noteworthy.

 Maybe we need to change the proposal guide.

This wasn't well-received 4.5 years ago[1] :/  I still think it's a
more valuable question than the brand one - which is likely what
brought them here in the first place.  Good luck...

--tim

[1] - 
http://mail-archives.apache.org/mod_mbox/incubator-general/201005.mbox/%3caanlktikxhpvpaqheqna02ptmix8lqwwjqznbay9lc...@mail.gmail.com%3E

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

Re: [VOTE] accept NiFi into the incubator

[Tim Williams]

+1, best wishes... based on revision #25[1]

--tim

[1] - http://wiki.apache.org/incubator/NiFiProposal?action=recallrev=25

On Fri, Nov 21, 2014 at 1:55 PM, Benson Margulies bimargul...@gmail.com wrote:
 http://wiki.apache.org/incubator/NiFiProposal has elicited a cheerful and
 positive conversation, so I offer this vote.

 Vote will be open for the usual 72 hours ...

 Here is my [+1]

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

Re: [PROPOSAL] NiFi for Incubation

[Tim Williams]

+1, good stuff...

--tim

On Wed, Nov 19, 2014 at 9:02 PM, Joe Witt joe.w...@gmail.com wrote:
 Hello,


 I would like to propose NiFi as an Apache Incubator Project.

 In addition to the copy provided below the Wiki version of the
 proposal can be found here:
 http://wiki.apache.org/incubator/NiFiProposal

 Thanks

 Joe


 = NiFi Proposal =

 == Abstract ==
 NiFi is a dataflow system based on the concepts of flow-based programming.

 == Proposal ==
 NiFi supports powerful and scalable directed graphs of data routing,
 transformation, and system mediation logic.  Some of the high-level
 capabilities and objectives of NiFi include:
   * Web-based user interface for seamless experience between design,
 control, feedback, and monitoring of data flows
   * Highly configurable along several dimensions of quality of service
 such as loss tolerant versus guaranteed delivery, low latency versus
 high throughput, and priority based queuing
   * Fine-grained data provenance for all data received, forked,
 joined, cloned, modified, sent, and ultimately dropped as data reaches
 its configured end-state
   * Component-based extension model along well defined interfaces
 enabling rapid development and effective testing

 == Background ==
 Reliable and effective dataflow between systems can be difficult
 whether you're running scripts on a laptop or have a massive
 distributed computing system operated by numerous teams and
 organizations.  As the volume and rate of data grows and as the number
 of systems, protocols, and formats increase and evolve so too does the
 complexity and need for greater insight and agility.  These are the
 dataflow challenges that NiFi was built to tackle.

 NiFi is designed in a manner consistent with the core concepts
 described in flow-based programming as originally documented by J.
 Paul Morrison in the 1970s.  This model lends itself well to visual
 diagramming, concurrency, componentization, testing, and reuse.  In
 addition to staying close to the fundamentals of flow-based
 programming, NiFi provides integration system specific features such
 as: guaranteed delivery; back pressure; ability to gracefully handle
 backlogs and data surges; and an operator interface that enables
 on-the-fly data flow generation, modification, and observation.

 == Rationale ==
 NiFi provides a reliable, scalable, manageable and accountable
 platform for developers and technical staff to create and evolve
 powerful data flows.  Such a system is useful in many contexts
 including large-scale enterprise integration, interaction with cloud
 services and frameworks, business to business, intra-departmental, and
 inter-departmental flows.  NiFi fits well within the Apache Software
 Foundation (ASF) family as it depends on numerous ASF projects and
 integrates with several others.  We also anticipate developing
 extensions for several other ASF projects such as Cassandra, Kafka,
 and Storm in the near future.

 == Initial Goals ==
   * Ensure all dependencies are compliant with Apache License version
 2.0 and all that all code and documentation artifacts have the correct
 Apache licensing markings and notice.
   * Establish a formal release process and schedule, allowing for
 dependable release cycles in a manner consistent with the Apache
 development process.
   * Determine and establish a mechanism, possibly including a
 sub-project construct, that allows for extensions to the core
 application to occur at a pace that differs from the core application
 itself.

 == Current Status ==
 === Meritocracy ===
 An integration platform is only as good as its ability to integrate
 systems in a reliable, timely, and repeatable manner.  The same can be
 said of its ability to attract talent and a variety of perspectives as
 integration systems by their nature are always evolving.  We will
 actively seek help and encourage promotion of influence in the project
 through meritocracy.

 === Community ===
 Over the past several years, NiFi has developed a strong community of
 both developers and operators within the U.S. government.  We look
 forward to helping grow this to a broader base of industries.

 === Core Developers ===
 The initial core developers are employed by the National Security
 Agency and defense contractors.  We will work to grow the community
 among a more diverse set of developers and industries.

 === Alignment ===
 From its inception, NiFi was developed with an open source philosophy
 in mind and with the hopes of eventually being truly open sourced.
 The Apache way is consistent with the approach we have taken to date.
 The ASF clearly provides a mature and effective environment for
 successful development as is evident across the spectrum of well-known
 projects.  Further, NiFi depends on numerous ASF libraries and
 projects including; ActiveMQ, Ant, Commons, Lucene, Hadoop,
 HttpClient, Jakarta and Maven.  We also anticipate extensions and
 dependencies with several more ASF projects, including 

Re: [VOTE] Accept HTrace into the Apache Incubator

[Tim Williams]

+1

--tim

On Wed, Nov 5, 2014 at 2:36 PM, Roman Shaposhnik r...@apache.org wrote:
 On Wed, Nov 5, 2014 at 11:16 AM, Roman Shaposhnik r...@apache.org wrote:
 Following the discussion earlier in the thread:
http://s.apache.org/Dk7

 I would like to call a VOTE for accepting HTrace
 as a new incubator project.

 The proposal is available at:

 https://wiki.apache.org/incubator/HTraceProposal
(a full version of the proposal is attached)

 Vote is open until at least Sunday, 9th November 2014, 23:59:00 UTC

  [ ] +1 accept Lens in the Incubator
  [ ] ±0
  [ ] -1 because...

 Thanks,
 Roman.

 == Abstract ==
 HTrace is a tracing framework intended for use with distributed
 systems written in java.

 == Proposal ==
 HTrace is an aid for understanding system behavior and for reasoning
 about performance
 issues in distributed systems. HTrace is primarily a low impedance
 library that a java
 distributed system can incorporate to generate ‘breadcrumbs’ or
 ‘traces’ along the path
 of execution, even as it crosses processes and machines. HTrace also
 includes various
 tools and glue for collecting, processing and ‘visualizing’ captured
 execution traces
 for analysis ex post facto of where time was spent and what resources
 were consumed.

 == Background ==
 Distributed systems are made up of multiple software components
 running on multiple
 computers connected by networks. Debugging or profiling operations run
 over non-trivial
 distributed systems -- figuring execution paths and what services, machines, 
 and
 libraries participated in the processing of a request -- can be involved.

 == Rationale ==
 Rather than have each distributed system build its own custom
 ‘tracing’ libraries,
 ideally all would use a single project that provides necessary
 primitives and saves
 each project building its own visualizations and processing tools anew.

 Google described “...[a] large-scale distributed systems tracing 
 infrastructure”
 in Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. The paper
 tells a compelling story of what is possible when disparate systems 
 standardize
 on a single tracing library and cooperate, ‘passing the baton’, filling out
 trace context as executions cross systems.

 HTrace aims to provide a rough equivalent in open source of the described core
 Dapper tools and library.  As it is adopted by more projects, there will be a
 ‘network effect’ as HTrace will provide a more comprehensive view of activity
 on the cluster.  For example, as HDFS gets HTrace support, we can connect this
 with the HTrace support in HBase to follow HBase requests as they enter HDFS.

 Given the success of HTrace depends on its being integrated by many  projects,
 HTrace should be perceived as unhampered, free of any commercial, political,
 or legal ‘taint’. Being an Apache project would help in this regard.

 == Initial Goals ==
 HTrace is a small project of narrow scope but with a grand vision:
   * Move the HTrace source and repository to Apache, a vendor-neutral
 location. Currently HTrace resides at a Cloudera-hosted repository.
   * Add past contributors as committers and institute Apache governance.
   * Evangelize and encourage HTrace diffusion. Initially we will
 continue a focus on the Hadoop space since that is where most of the
 initial contributors work and it is where HTrace has been initially
 deployed.
   * Building out the standalone visualization tool that ships with HTrace.
   * Build more community and add more committers

 == Current Status ==
 Currently HTrace has a viable Java trace library that can be interpolated
 to create ‘traces’.  The work that needs to be done on this library is mostly
 bug fixes, ease-of-use improvements, and performance tweaks.  In the future,
 we may add libraries for other languages besides Java.

 HTrace has means of dumping traces to the filesystem, Twitters’ Zipkin
 (a tracing
 sink and visualization system developed by Twitter
 https://github.com/twitter/zipkin),
 or Apache HBase.  Executions can be viewed either in Zipkin or in pygraph
 (https://code.google.com/p/python-graph/).

 Since the initial sprint in the summer of 2012 which saw HTrace patches 
 proposed
 for Apache HDFS and committed to Apache HBase, development has been sporadic;
 mostly a single developer or two adding a feature or bug fixing. HTrace is
 currently undergoing a new “spurt” of development with the effort to get 
 HTrace
 added to Apache HDFS revived and a new standalone viewing facility being added
 in to HTrace itself.

 HTrace has been integrated by Apache Phoenix.


 === Meritocracy ===
 HTrace, up to this, has been run by Apache committers and PMC members.
 We want to
 build out a diverse developer and user community and run the HTrace project in
 the Apache way.  Users and new contributors will be treated with respect and
 welcomed; they will earn merit in the project by tendering quality patches
 and support that move the project forward.  Those with a proven 

Re: Mentors heartbeat

[Tim Williams]

On Thu, Sep 4, 2014 at 10:31 AM, Chris Mattmann mattm...@apache.org wrote:
 Seriously, give me a break.

 This has been discussed ad naseum - It's a quick simple measure
 to see if one of the stated requirements for mentors (reading the
 monthly report, and *signing that you read it*) has been fulfilled.

The initial query was about finding MIA mentors - I reckon changing
the mentor_tick_pattern to look for unsigned reports would help with
that?

--tim

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

Re: Podling binding votes

[Tim Williams]

On Fri, Jul 25, 2014 at 12:33 PM, Henry Saputra henry.sapu...@gmail.com wrote:
 This is conflicting from what the site said about governance of podling.
 PPMC is a part of podling and responsible to manage the podling on behalf
 of IPMC.

 I suppose you meant that their votes do not bind but saying it was never
 part of the structure is misleading or we need to update the ASF website
 about incubator roles page.

The conflicting bit is how you two are resolving the pronoun our in
Ross' statement below the PPMC is not a formal part of the ASF's
formal structure the PPMC is a formal part of the IPMC's internal
organization.

--tim

 On Friday, July 25, 2014, Ross Gardler rgard...@opendirective.com wrote:

 The PPMC is not, and never has been, a formally recognized part of our
 structure. But as I said that's a technicality in this context, the project
 (PPMC) are the people who really matter from the projects perspective, even
 though their votes are not binding.

 The thread seems to be in agreement in response to Justin's specific
 question.

 On 25 Jul 2014 01:20, John D. Ament john.d.am...@gmail.com
 javascript:; wrote:
 
  Ross,
 
  The incubator website would be inclined to disagree, and seems to
  acknowledge there is formally a PPMC at [1].
 
  Justin,
 
  I think formally, if you review [2] (you may also want to scroll down,
 and
  review later parts of this page on voting), you'll see that the PPMC
 votes
  really don't count for anything other than merit.  The IPMC vote is what
  really counts.  If you follow that page verbatim, the votes by the IPMC
 are
  the only ones that count.
 
  If you follow the alternative voting method, found at [3], you'll see
 that
  votes via PPMC are acceptable if and only if the IPMC has agreed to such.
 
 
  [1]: http://incubator.apache.org/guides/ppmc.html
  [2]:
 

 http://incubator.apache.org/guides/releasemanagement.html#best-practice-incubator-release-vote
  [3]:
 http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
 
 
 
  On Thu, Jul 24, 2014 at 7:48 PM, Ross Gardler 
 rgard...@opendirective.com javascript:;
  wrote:
 
   There is no formal PPMC. When a podling is created all initial
 committers
   are equal. I guess some podlings might create the concept of a separate
   PPMC during incubation. I've never advised that in my own podlings
   (probably because I'm a believer in an absolute minimum barrier to
 entry).
   I guess it's up to individual projects and mentors just as our top
 level
   projects can decide if the PMC is the whole set or a subset of the
   committers
   On 25 Jul 2014 00:33, Justin Mclean jus...@classsoftware.com
 javascript:; wrote:
  
Hi,
   
 As a mentor I've (nearly) always advised that if there are three
 IPMC
votes on the dev list then there is no need to make further noise on
 the
general list with unnecessary +1's. I therefore point out in the
 general@
vote mail that 3 binding (IPMC) +1's have been received and therefore
   there
is only a need to vote if there is an objection.
Fair enough + seem reasonable to me.
   
 TECHNICALITY: PPMC votes are not binding (although they absolutely
should be considered as such by the project). Only IPMC votes are
considered binding at the foundational level since PPMC members are
 not
   yet
a member of a formal committee.
You need 3 +1 votes first on the podlings dev list, and PPMC votes do
count there, we wouldn't see a lot of podling releases otherwise. :-)
   Does
that mean any +1 vote (say by a committer or user) on the dev list
 also
counts if PPMC votes aren't actually considered binding? (I'd assume
 not
but again it's not clear from the document).
   
Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 javascript:;
For additional commands, e-mail: general-h...@incubator.apache.org
 javascript:;
   
   
  


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

Re: [VOTE] Release Blur version 0.2.3-incubating RC2

[Tim Williams]

On Wed, Jul 23, 2014 at 8:48 PM, Justin Mclean jus...@classsoftware.com wrote:
 HI,

 2 x +1 binding votes
 2 x +1 non-binding votes

 Aren't IPMC votes binding so that would be 4 +1 binding votes?

Hi Justin,
Apache Blur isn't under the [new] alternate process, if that's what
you're referring to.  I'm still under that impression [as one of the
mentors] that we require 3 binding IPMC votes. If that's changed and I
missed it, let me be the first to buy you a beer at the next ApacheCon
for enlightening us:)

Thanks,
--tim

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

Re: [VOTE] Release Blur version 0.2.3-incubating RC2

[Tim Williams]

On Wed, Jul 23, 2014 at 9:31 PM, Justin Mclean jus...@classsoftware.com wrote:
 Hi

 Apache Blur isn't under the [new] alternate process, if that's what
 you're referring to.  I'm still under that impression [as one of the
 mentors] that we require 3 binding IPMC votes.

 I may be mistaken but I thought it required 3 +1 binding votes on the podling 
 dev list and then 3 +1 IPMC votes on this list for a release? [1]

 I read +1 votes as +1 binding votes in  [1]. Anyone want to clarify?

It requires 3 +1 votes on the podling list, they then bring it here
for the 3+1 *binding* votes. In our case we got 4 total +1 {2 IPMC
members; 2 PPMC members} and came here for the third binding vote.  I
think the Aaron was precise in his usage of +1 votes and +1 binding
votes. Mine and Patrick's vote carry through here leaving us 1 shy of
3 binding +1 votes from IPMC members. I'm not seeing the point of
confusion here.

Thanks,
--tim

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

Re: [VOTE] Release Blur version 0.2.3-incubating RC2

[Tim Williams]

On Wed, Jul 23, 2014 at 10:50 PM, Justin Mclean
jus...@classsoftware.com wrote:
 Hi,

 It requires 3 +1 votes on the podling list, they then bring it here
 for the 3+1 *binding* votes. In our case we got 4 total +1 {2 IPMC
 members; 2 PPMC members} and came here for the third binding vote.  I
 think the Aaron was precise in his usage of +1 votes and +1 binding
 votes. Mine and Patrick's vote carry through here leaving us 1 shy of
 3 binding +1 votes from IPMC members. I'm not seeing the point of
 confusion here.

 The confusion is that the 2 PPMC votes were not stated as votes by the PPMC 
 and could of been from anyone.

Thanks Justin, yes they're both PPMC members.

 Are IPMC votes consider binding on a podlings dev list and count toward the 
 initial +3? I'm assuming so but I can't find it stated anywhere.

Yes. If you're a member of the IPMC and cast a vote on a podling list,
it's binding. -there. stated somewhere now:)

 If the other two votes were not by PPMC then there only +2 votes and so it's 
 not valid.

They were, so this is a non-issue.

 I note that Chris is not listed here [1] but is on the initial committer list 
 [2] and there's no
 team page on the Blur site listing out the PPMC members. I assume they are 
 PPMC
 votes but as an outsider it's hard to know.

Honestly, I'm not sure what the canonical place for you to look up
PPMC members - I've never really cared because they're not binding.
Since you give some meaning to [1] - I've done what needs to be done
to get Chris added there, not sure how long it will take to show up.

Are you interested in helping review/vote on our release or just
debating the incubator policy stuffs?

Thanks,
--tim

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

Re: binary release artifacts

[Tim Williams]

On Sun, Sep 15, 2013 at 5:19 AM, ant elder ant.el...@gmail.com wrote:
 Tim, one of the things we're trying to teach podlings is how to handle
 disputes and resolve problems in a happy respectful manner. You've out
 of the blue come on to their dev list without introducing yourself
 demanding that something that happened nearly two years ago be undone.

My mail on their list wasn't intended to be 'demanding' or rude - my
apologies if it came across that way.  I honestly went in thinking it
was a mistake - a simple misunderstanding.

 Its a testament to Chukwa that they've engaged in discussing the
 matter with you promptly and politely, never the less in under 48
 hours of starting the discussion you've escalated this to general@
 with a fairly negative email.

I agree, Eric was prompt and polite.  I escalated this for two reasons:

1) It became apparent that it wasn't a misunderstanding - it's a
question of policy and it doesn't seem fair to hash that out on their
dev list.  It wasn't so much escalation as taking policy discussions
to the right audience - if there were a mentor@ list, I would have
aimed there.

2) This PMC has a release artifact published that was never voted
upon.  That was news to me and, I felt, worthy of sunlight -
especially after the [prompt/polite] defensive reaction received.

Sorry for the negativity, it was borne of frustration.  It's
frustrating to ask podlings to work hard dotting I's and crossing T's
only to look around and see other podling's  lackadaisical approach.

 Lets take your LICENSE/NOTICE file issue, you initially said the
 binary artifact didn't have any, it was then pointed out that in fact
 it did have them just not where you were looking, you then asserted
 that is not acceptable and they must only be right at the top
 directory, it was then pointed out other types of binary distributions
 like jars also don't have them at the top either, but you have ignored
 that and instead come here to general@.

I guess I viewed that as a frustrating rationalization.  Their distro
is a standard tarball - where those files are well expected to be in
the standard place by both policy and social norm - not some other
artifact type where an difference is obvious.  Anyway, moving it here
was less about that and more about the fact that they released an
artifact without voting.

Though, since you bring it up I'd appreciate that if there's going to
be no accountability for podlings to locate those source files in the
right place[1], then yeah, I think we should change the policy to
state that anywhere in the artifact is acceptable.

--tim

[1] - http://apache.org/legal/src-headers.html#notice

 I have no doubt that Chukwa will be happy to help resolve this in
 whatever way is necessary to satisfy all the ASF policy's, but we
 don't need a big general@ flame thread to do that.

...ant

 On Sun, Sep 15, 2013 at 3:46 AM, Tim Williams william...@gmail.com wrote:
 Moving this[1] to general@

 On Sat, Sep 14, 2013 at 2:55 AM, ant elder ant.el...@gmail.com wrote:
 On Saturday, September 14, 2013, Tim Williams william...@gmail.com wrote:
 Hi Eric,
 I've included references inline for your convenience.  I'll once again
 [strongly] suggest you guys remove that artifact.

 Thanks,
 --tim

 On Fri, Sep 13, 2013 at 6:53 PM, Eric Yang eric...@gmail.com wrote:
 Hi Tim,

 There is LICENSE.txt and NOTICES.txt in both source and binary package.
  In
 the binary package, the files are located in $PREFIX/share/doc/chukwa to
 match what standard Linux file system layout.  We voted for source
 release
 and there is no Apache restriction that a source release, can not
 procedure
 a binary package.

 Votes on whether a package is ready to be released use majority
 approval -- i.e., at least three PMC members must vote affirmatively
 for release, and there must be more positive than negative votes.

 Each vote is on signed, hashed artifacts, so yes, if you say it's a
 source vote then no binary should accompany it.

 http://www.apache.org/dev/release.html#approving-a-release

 There is also no restriction that binary release must
 have LICENSE.txt and NOTICES.txt in the top level directory.

 How do you reach that understanding from the sentence below?

 Every Apache distribution should include a NOTICE file in the top
 directory, along with the standard LICENSE file.


 Plenty of other release artifacts from other projects have these files
 somewhere other than the top directory, eg most jar releases have them in
 the meta-inf directory.

 There is also ambiguity around convenience binary releases in the ASF docs
 and the historical mailing list discussions around those, so a little
 flexibility is warranted. I recall there was once a some bugs in the maven
 plugin for building jars which meant several projects distributing jar
 artifacts with missing or completely incorrect license/notice files, and
 those artifacts weren't pulled . I also recall on one project where an
 artifact was discovered

Re: binary release artifacts

[Tim Williams]

Moving this[1] to general@

On Sat, Sep 14, 2013 at 2:55 AM, ant elder ant.el...@gmail.com wrote:
 On Saturday, September 14, 2013, Tim Williams william...@gmail.com wrote:
 Hi Eric,
 I've included references inline for your convenience.  I'll once again
 [strongly] suggest you guys remove that artifact.

 Thanks,
 --tim

 On Fri, Sep 13, 2013 at 6:53 PM, Eric Yang eric...@gmail.com wrote:
 Hi Tim,

 There is LICENSE.txt and NOTICES.txt in both source and binary package.
  In
 the binary package, the files are located in $PREFIX/share/doc/chukwa to
 match what standard Linux file system layout.  We voted for source
 release
 and there is no Apache restriction that a source release, can not
 procedure
 a binary package.

 Votes on whether a package is ready to be released use majority
 approval -- i.e., at least three PMC members must vote affirmatively
 for release, and there must be more positive than negative votes.

 Each vote is on signed, hashed artifacts, so yes, if you say it's a
 source vote then no binary should accompany it.

 http://www.apache.org/dev/release.html#approving-a-release

 There is also no restriction that binary release must
 have LICENSE.txt and NOTICES.txt in the top level directory.

 How do you reach that understanding from the sentence below?

 Every Apache distribution should include a NOTICE file in the top
 directory, along with the standard LICENSE file.


 Plenty of other release artifacts from other projects have these files
 somewhere other than the top directory, eg most jar releases have them in
 the meta-inf directory.

 There is also ambiguity around convenience binary releases in the ASF docs
 and the historical mailing list discussions around those, so a little
 flexibility is warranted. I recall there was once a some bugs in the maven
 plugin for building jars which meant several projects distributing jar
 artifacts with missing or completely incorrect license/notice files, and
 those artifacts weren't pulled . I also recall on one project where an
 artifact was discovered distributed without a release vote and the solution
 was just to have a posthumous vote. The important thing here in my opinion
 is to get a common understanding of how convenience binary artifacts will
 be handled in the future that everyone is happy with.

No offense, but this is ridiculous. If our job as mentors is to help
podlings rationalize violations of most basic policies (e.g. release
artifacts require a vote, NOTICE/LICENSE files), to play the
well-they-got-away-with-it game, then this process is really a joke
and we should close up shop. If such basic things as this are really
up for debate by seemingly clueful folk, then the incubator isn't
serving a useful purpose and should be dissolved as it means we're
actively graduating podlings that are somewhere between just not
getting it and putting the foundation at risk. (alarmingly, discussion
of Chukwa's graduation was recently had!).  I dunno, that podlings are
defending the idea of releasing unvoted on artifacts only to have
their mentor follow suit is frustrating  - I really assumed this was
as simply case of oh, we didn't understand that...

Thanks,
--tim

[1] - 
http://mail-archives.apache.org/mod_mbox/incubator-chukwa-dev/201309.mbox/browser

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

Re: KEYS and keys

[Tim Williams]

On Wed, Sep 4, 2013 at 7:18 PM, sebb seb...@gmail.com wrote:
 On 4 September 2013 02:31, Tim Williams william...@gmail.com wrote:
 I notice that Chris just pointed[1] spark to the nifty keys
 listing[1].  Our docs still imply manual maintenance of the typical
 KEYS file[2].  Honestly, I didn't even know the ldap-driven one was
 around.  I assume its fair for projects to just point to the
 p.a.o/keys/groups/${project}.asc file nowadays vs. copying that over
 periodically to KEYS?

 The KEYS file has historically been manually maintained.
 As new keys are used for signing releases, they are added to the file.
 However entries should not be deleted if they have ever been used to
 sign a release, otherwise it may not be possible to check the sigs of
 archived artifacts.

 LDAP does not have all historic keys, or even all historic RMs.

 So replacing the KEYS file with a copy from LDAP may lose keys needed
 for validating archived files.

 Directing users to the p.a.o/keys/groups/${project}.asc files should
 work for current releases.
 But even that has an problem - if the RM leaves a project whilst the
 release is still current, the project.asc file will no longer contain
 the RM's key

 The problem is even worse for older releases.
 People may create new keys and drop old ones which have been used for signing.
 People leave a project or the ASF and the LDAP entry is changed.

 I don't think the LDAP keys are really suitable for use as a KEYS file
 at present.

Great points, makes total sense, thanks for the clarification sebb!

--tim

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

Re: [PROPOSAL] Storm for Apache Incubator

[Tim Williams]

+1

--tim

On Wed, Sep 4, 2013 at 4:07 AM, Nathan Marz nat...@nathanmarz.com wrote:
 Hi everyone,

 I'd like to propose Storm to be an Apache Incubator project. After much
 thought I believe this is the right next step for the project, and I look
 forward to hearing everyone's thoughts and feedback!

 Here's a link to the proposal:
 https://wiki.apache.org/incubator/StormProposal

 The proposal is also pasted below.

 -Nathan


 = Storm Proposal =

 == Abstract ==

 Storm is a distributed, fault-tolerant, and high-performance realtime
 computation system that provides strong guarantees on the processing of
 data.

 == Proposal ==

 Storm is a distributed real-time computation system. Similar to how Hadoop
 provides a set of general primitives for doing batch processing, Storm
 provides a set of general primitives for doing real-time computation. Its
 use cases span stream processing, distributed RPC, continuous computation,
 and more. Storm has become a preferred technology for near-realtime
 big-data processing by many organizations worldwide (see a partial list at
 https://github.com/nathanmarz/storm/wiki/Powered-By). As an open source
 project, Storm’s developer community has grown rapidly to 46 members.

 == Background ==

 The past decade has seen a revolution in data processing. MapReduce,
 Hadoop, and related technologies have made it possible to store and process
 data at scales previously unthinkable. Unfortunately, these data processing
 technologies are not realtime systems, nor are they meant to be. The lack
 of a Hadoop of realtime has become the biggest hole in the data
 processing ecosystem. Storm fills that hole.

 Storm was initially developed and deployed at BackType in 2011. After 7
 months of development BackType was acquired by Twitter in July 2011. Storm
 was open sourced in September 2011.

 Storm has been under continuous development on its Github repository since
 being open-sourced. It has undergone four major releases (0.5, 0.6, 0.7,
 0.8) and many minor ones.

 == Rationale ==

 Storm is a general platform for low-latency big-data processing. It is
 complementary to the existing Apache projects, such as Hadoop. Many
 applications are actually exploring using both Hadoop and Storm for
 big-data processing. Bringing Storm into Apache is very beneficial to both
 Apache community and Storm community.

 The rapid growth of Storm community is empowered by open source. We believe
 the Apache foundation is a great fit as the long-term home for Storm, as it
 provides an established process for community-driven development and
 decision making by consensus. This is exactly the model we want for future
 Storm development.

 == Initial Goals ==

   * Move the existing codebase to Apache
   * Integrate with the Apache development process
   * Ensure all dependencies are compliant with Apache License version 2.0
   * Incremental development and releases per Apache guidelines

 == Current Status ==

 Storm has undergone four major releases (0.5, 0.6, 0.7, 0.8) and many minor
 ones. Storm 0.9 is about to be released. Storm is being used in production
 by over 50 organizations. Storm codebase is currently hosted at github.com,
 which will seed the Apache git repository.

 === Meritocracy ===

 We plan to invest in supporting a meritocracy. We will discuss the
 requirements in an open forum. Several companies have already expressed
 interest in this project, and we intend to invite additional developers to
 participate. We will encourage and monitor community participation so that
 privileges can be extended to those that contribute.

 === Community ===

 The need for a low-latency big-data processing platform in the open source
 is tremendous. Storm is currently being used by at least 50 organizations
 worldwide (see https://github.com/nathanmarz/storm/wiki/Powered-By), and is
 the most starred Java project on Github. By bringing Storm into Apache, we
 believe that the community will grow even bigger.

 === Core Developers ===

 Storm was started by Nathan Marz at BackType, and now has developers from
 Yahoo!, Microsoft, Alibaba, Infochimps, and many other companies.

 === Alignment ===

 In the big-data processing ecosystem, Storm is a very popular low-latency
 platform, while Hadoop is the primary platform for batch processing. We
 believe that it will help the further growth of big-data community by
 having Hadoop and Storm aligned within Apache foundation. The alignment is
 also beneficial to other Apache communities (such as Zookeeper, Thrift,
 Mesos). We could include additional sub-projects, Storm-on-YARN and
 Storm-on-Mesos, in the near future.

 == Known Risks ==

 === Orphaned Products ===

 The risk of the Storm project being abandoned is minimal. There are at
 least 50 organizations (Twitter, Yahoo!, Microsoft, Groupon, Baidu,
 Alibaba, Alipay, Taobao, PARC, RocketFuel etc) are highly incentivized to
 continue development. Many of these organizations have built critical
 business 

KEYS and keys

[Tim Williams]

I notice that Chris just pointed[1] spark to the nifty keys
listing[1].  Our docs still imply manual maintenance of the typical
KEYS file[2].  Honestly, I didn't even know the ldap-driven one was
around.  I assume its fair for projects to just point to the
p.a.o/keys/groups/${project}.asc file nowadays vs. copying that over
periodically to KEYS?

Thanks,
--tim


[1] - http://people.apache.org/keys/group/spark.asc
[2] - 
http://incubator.apache.org/guides/releasemanagement.html#distribution-signing

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

Re: Canonical podling count

[Tim Williams]

Why not take it from the number Clutch reports?

On Monday, July 8, 2013, Marvin Humphrey wrote:

 Greets,

 For our report, I'd like to supply an official count of podlings under
 incubation.  Here's one way of doing it from the incubator svn checkout:

   grep . content/report_due_* | wc -l

 Any better ideas, or is that algo good enough?  Would a podling_count.py
 make sense or do we already have something like that?

 For the purposes of the report, the important thing is to provide
 consistent
 numbers over time.  Up-to-the-minute accuracy is less of a concern.

 Marvin Humphrey

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

Re: Stratos proposal: is it possible to add another initial committer?

[Tim Williams]

On Tue, Jun 18, 2013 at 3:08 AM, Ross Gardler
rgard...@opendirective.com wrote:
 I respectfully suggest your intervention is an example of ISSUE 03 (too
 many cooks). As a champion I'm interested in podlings learning the Apache
 Way - a significant part of this is to not let unnecessary process get in
 the way of software development.

 The vote is still open and can be stopped with a veto. This is a reversible
 step. It is done in full view of the voting community. No harm is done and
 a little extra work for a number of volunteers is avoided.

C'mon, it's frustrating that folks are now casting Marvin as an
annoying rule follower. For all votes here, you review a
proposal/RC/committer candidate, you vote.  And that vote is based on
the state of the proposal as it were when you voted. That the proposal
is immutable is a well-established social norm, certainly not news to
you, Sanjiva, or anyone else...

A voter should be able to vote and forget about it.  They shouldn't
need to constantly go back and look for changes since casting their
vote.  No one would, for example, allow this sort of nonsense in a
release candidate vote.

Debo didn't have things worked out in time, not a big deal; vote them
in after the proposal succeeds, that's truly a trivial exercise for
such a distinguished list of folks.

Another option is to discount votes prior to the last mutation.  Or,
we add a wiki page that explains to new folks how the social norms can
be overridden/bullied occasionally by headstrong, salty old-timers as
they see fit...

Thanks,
--tim

 Sent from a mobile device, please excuse mistakes and brevity
 On 18 Jun 2013 03:18, Marvin Humphrey mar...@rectangular.com wrote:

 On Mon, Jun 17, 2013 at 11:04 AM, Ross Gardler
 rgard...@opendirective.com wrote:
  C'mon Marvin. The project has enough ASF committers on the initial
  commiter list (ignoring mentors) to be able to conduct a committer
  vote.
 
  Lets not add unnecessary bureaucracy during the initial set-up phase.

 Voting in a new committer isn't a lot of work, and Stratos has a lot of
 resources behind it.  Following the rules wouldn't have been a big deal.

 I'm not prepared to blow up the Incubator over this issue, though -- only
 to
 ask nicely.

 If Stratos later experiences frustration regarding the Incubator's
 conflicting
 rules and inconsistent enforcement of rules, now they'll know where that
 comes
 from.

 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: [VOTE] Accept Stratos proposal as an incubating project

[Tim Williams]

On Fri, Jun 14, 2013 at 5:49 PM, Ross Gardler
rgard...@opendirective.com wrote:
 I would like to invite the IPMC vote to accept the Stratos proposal [1].

 I want to clarify that this vote is for the Stratos project to enter
 the incubator as a standard podling under the existing incubation
 policy. The acceptance or otherwise of the probationary TLP idea is a
 separate issue that will be explored during the first month of
 incubation, potentially resulting in a further IPMC vote.

 This vote is *only* for accepting the Stratos project as a podling.

 [ ] +1 Accept the Stratos project as an incubating project
 [ ] +0
 [ ] -1 Do not accept the Stratos project as an incubating project
 because... (provide reason)

+1 (check-my-binding-status-and-dont-rely-on-the-caller-asserts-model)

Thanks,
--tim

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

Re: [VOTE] Apache Spark for the Incubator

[Tim Williams]

+1

--tim

On Sat, Jun 8, 2013 at 1:34 AM, Mattmann, Chris A (398J)
chris.a.mattm...@jpl.nasa.gov wrote:
 Hi Folks,

 OK discussion has died down, time to VOTE to accept Spark into the
 Apache Incubator. I'll let the VOTE run for at least a week.

 So far I've heard +1s from the following folks, so no need for them
 to VOTE again unless they want to change their VOTE:

 +1

 Chris Mattmann*
 Konstantin Boudnik
 Henry Saputra*
 Reynold Xin
 Pei Chen
 Roman Shaposhnik*
 Suresh Marru*

 * -indicates IPMC

 [ ] +1 Accept Spark into the Apache Incubator.
 [ ] +0 Don't care.
 [ ] -1 Don't accept Spark into the Apache Incubator because..

 Proposal text is below.

 === Abstract ===
 Spark is an open source system for large-scale data analysis on clusters.

 === Proposal ===
 Spark is an open source system for fast and flexible large-scale data
 analysis. Spark provides a general purpose runtime that supports
 low-latency execution in several forms. These include interactive
 exploration of very large datasets, near real-time stream processing, and
 ad-hoc SQL analytics (through higher layer extensions). Spark interfaces
 with HDFS, HBase, Cassandra and several other storage storage layers, and
 exposes APIs in Scala, Java and Python.
 Background
 Spark started as U.C. Berkeley research project, designed to efficiently
 run machine learning algorithms on large datasets. Over time, it has
 evolved into a general computing engine as outlined above. Spark¹s
 developer community has also grown to include additional institutions,
 such as universities, research labs, and corporations. Funding has been
 provided by various institutions including the U.S. National Science
 Foundation, DARPA, and a number of industry sponsors. See:
 https://amplab.cs.berkeley.edu/sponsors/ for full details.

 === Rationale ===
 As the number of contributors to Spark has grown, we have sought for a
 long-term home for the project, and we believe the Apache foundation would
 be a great fit. Spark is a natural fit for the Apache foundation: Spark
 already interoperates with several existing Apache projects (HDFS, HBase,
 Hive, Cassandra, Avro and Flume to name a few). The Spark team is familiar
 with the Apache process and and subscribes to the Apache mission - the
 team includes multiple Apache committers already. Finally, joining Apache
 will help coordinate the development effort of the growing number of
 organizations which contribute to Spark.

 == Initial Goals ==
 The initial goals will most likely be to move the existing codebase to
 Apache and integrate with the Apache development process. Furthermore, we
 plan for incremental development, and releases along with the Apache
 guidelines.

 === Current Status ===
 == Meritocracy ==
 The Spark project already operates on meritocratic principles. Today,
 Spark has several developers and has accepted multiple major patches from
 outside of U.C. Berkeley. While this process has remained mostly informal
 (we do not have an official committer list), an implicit organization
 exists in which individuals who contribute major components act as
 maintainers for those modules. If accepted, the Spark project would
 include several of these participants as committers from the onset. We
 will work to identify all committers and PPMC members for the project and
 to operate under the ASF meritocratic principles.

 === Community ===
 Acceptance into the Apache foundation would bolster the already strong
 user and developer community around Spark. That community includes dozens
 of contributors from several institutions, a meetup group with several
 hundred members, and an active mailing list composed of hundreds of users.
 Core Developers
 The core developers of our project are listed in our contributors and
 initial PPMC below. Though many exist at UC Berkeley, there is a
 representative cross sampling of other organizations including Quantifind,
 Microsoft, Yahoo!, ClearStory Data, Bizo, Intel, Tagged and Webtrends.


 === Alignment ===
 Our proposed effort aligns with several ongoing BIGDATA and U.S. National
 priority funding interests including the NSF and its Expeditions program,
 and the DARPA XDATA project. Our industry partners and collaborators are
 well aligned with our code base.

 There are also a number of related Apache projects and dependencies, that
 will be mentioned in the Relationships with Other Apache products section.

 == Known Risks ==

 === Orphaned Products ===
 Given the current level of investment in Spark - the risk of the project
 being abandoned is minimal. There are several constituents who are highly
 incentivized to continue development. The U.C. Berkeley AMPLab relies on
 Spark as a platform for a large number of long-term research projects.
 Several companies have build verticalized products which are tightly
 dependent on Spark. Other companies have devoted significant internal
 infrastructure investment in Spark.

 === Inexperience with Open Source ===
 Spark 

Re: If I were king of the forest

[Tim Williams]

On Wed, May 8, 2013 at 3:31 AM, Alan Cabrera a...@toolazydogs.com wrote:
 ...
 Podlings would be required to have a minimum of two active mentors.  A mentor 
 is free to become inactive but must explicitly
 state this else the mentor risks being removed for not performing their 
 duties.

I like it all.  A lot.  It's an attempt to solve the real problem.
But how do you define inactive and how do you identify them and on
what periodicity?  And, if they're a Member how long must such a
person wait before re-signing up to be a mentor?

Thanks,
--tim

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

Re: [META DISCUSS] talking about the overall state of this PMC

[Tim Williams]

On Tue, May 7, 2013 at 11:20 AM, Benson Margulies bimargul...@gmail.com wrote:
 There was a consensus to add the Champion role, and we haven't even
 tried it seriously, and now you propose to eliminate it.  That doesn't
 seem reasonable to me. I'd rather try to make it useful and then
 evaluate it. In other words, +1 to Bertrand.

 'Holding mentors to their responsibility' as a completely generic
 concept is an idea that constantly fails to reach a consensus, due to
 the 'volunteer dilemma'.

 For others in this thread, I completely disagree that a monthly one
 line edit to the XML file or a one line email is an unreasonable
 burden.

Fair enough, disagree.

 Any mentor, let alone champion, for whom that is an
 unreasonable burden should not have signed up in the first place.

That's unfair.  I signed up to *mentor* not send silly heartbeat
checks that exist because other podling's mentors failed to live up to
their responsibility.  This feels beyond the minimal governance
necessary and a solution to the wrong problem.  It'd helpful to say
precisely what problem that this heartbeat is intended to solve, in
that way, we are afforded the opportunity to propose an alternative
solution - for example, by focusing on highlighting the problem
mentors/podlings.

Thanks,
--tim

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

Re: [META DISCUSS] talking about the overall state of this PMC

[Tim Williams]

On Sun, May 5, 2013 at 9:56 PM, Benson Margulies bimargul...@gmail.com wrote:
 Discussions on Ross' and Chris' proposals ground to a halt.

 In my view, there are real issues that drove those discussions, even if
 those discussions drove some of us to distraction.

 A bit before the wiki crashed, I wrote:

 http://wiki.apache.org/incubator/BensonApril2013ProcessProposals

 The TL;DR version of this is:

 1: let's take Champions seriously as a role
 2: let's ask for a minimal heartbeat from every podling every month

Monthly reporting is overly burdensome (yes, even a
tiny-little-heartbeat report).  Let's please not add overhead/burden
to healthy podlings for the sake of the few unhealthy.

Thanks,
--tim

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

Re: svn commit: r1441762 - /incubator/public/trunk/content/projects/onami.xml

[Tim Williams]

On Saturday, February 2, 2013, wrote:

 Author: grobmeier
 Date: Sat Feb  2 15:22:33 2013
 New Revision: 1441762

 URL: http://svn.apache.org/viewvc?rev=1441762view=rev
 Log:
 updated status page for onami

 Modified:
 incubator/public/trunk/content/projects/onami.xml

 Modified: incubator/public/trunk/content/projects/onami.xml
 URL:
 http://svn.apache.org/viewvc/incubator/public/trunk/content/projects/onami.xml?rev=1441762r1=1441761r2=1441762view=diff

 ==
 --- incubator/public/trunk/content/projects/onami.xml [utf-8] (original)
 +++ incubator/public/trunk/content/projects/onami.xml [utf-8] Sat Feb  2
 15:22:33 2013
 @@ -18,6 +18,10 @@
titleNews/title
ul
  !--li-MM-DD New committer: Fred Nerk/li--
 +li2013-01-24 New committer: Mikhail Mazursky/li
 +li2013-01-24 New committer:  Eric Charles/li
 +li2013-01-19 Onami Parent 2 released/li
 +li2013-01-ß4 Onami Parent 1 released/li


I think an unintended character slipped in there:)



  li2012-11-14 Project enters incubation./li
/ul
  /section
 @@ -37,11 +41,6 @@
/td
  /tr
  tr
 -  td./td
 -  tdwiki/td
 -  td./td
 -/tr
 -tr
tdMailing list/td
tddev/td
td id=mail-devcodedev/codecode@/codecode
 onami.incubator.apache.org/code/td
 @@ -95,17 +94,17 @@
  /tr
  tr
td/td
 -  td./td
 +  tdcodyaray/td
tdCody Ray/td
  /tr
  tr
td/td
 -  td./td
 +  tdgtouratier/td
tdGhislain Picpoc Touratier/td
  /tr
  tr
td/td
 -  td./td
 +  tddanielmanzke/td
tdDaniel Manzke/td
  /tr
  tr
 @@ -121,7 +120,7 @@

  tr
td/td
 -  td/td
 +  tdjordi/td
tdJordi Gerona/td
  /tr

 @@ -131,12 +130,14 @@
tdMarco Speranza/td
  /tr

 +!--
  tr
td/td
td/td
tdMarzia Forli/td
  /tr
 -
 +--
 +
  tr
td/td
tdmnour/td
 @@ -145,7 +146,7 @@

  tr
td/td
 -  td/td
 +  tdnmwael/td
tdNino Martinez Wael/td
  /tr

 @@ -155,12 +156,14 @@
tdOlivier Lamy/td
  /tr

 +!--
  tr
td/td
td/td
tdPawel Poltorak/td
  /tr
 -
 +--
 +
  tr
td/td
tdsimonetripodi/td
 @@ -173,18 +176,13 @@
tdStuart McCulloch/td
  /tr

 +!--
  tr
td/td
td/td
tdThilo-Alexander Ginkel/td
  /tr
 -!--
 -tr
 -  tdExtra/td
 -  td./td
 -  td./td
 -/tr
 ---
 +--
/table
  /section
  section id=Incubation+status+reports
 @@ -242,24 +240,24 @@
thitem/th
  /tr
  tr
 -  td-..-../td
 +  td2012-12-26/td
tdAsk infrastructure to create source repository modules
and grant the committers karma./td
  /tr
  tr
 -  td-..-../td
 +  td2012-12-26/td
tdAsk infrastructure to set up and archive mailing
 lists./td
  /tr
  tr
 -  td-..-../td
 +  td2012-12-26/td
tdAsk infrastructure to set up issue tracker (JIRA,
 Bugzilla)./td
  /tr
  tr
 -  td-..-../td
 -  tdAsk infrastructure to set up wiki (Confluence,
 Moin)./td
 +  tdNA/td
 +  tdstrikeAsk infrastructure to set up wiki (Confluence,
 Moin)./strike/td
  /tr
  tr
 -  td-..-../td
 +  td2012-12-26/td
tdMigrate the project to our infrastructure./td
  /tr
/table
 @@ -272,22 +270,22 @@
thitem/th
  /tr
  tr
 -  td-..-../td
 +  td2012-12-15/td
tdIdentify all the Mentors for the incubation, by asking
 all
that can be Mentors./td
  /tr
  tr
 -  td-..-../td
 +  td2012-12-26/td
tdSubscribe all Mentors on the pmc and general lists./td
  /tr
  tr
 -  td-..-../td
 +  td2012-12-26/td
tdGive all Mentors access to the incubator SVN repository.
  (to be done by the Incubator PMC chair or an Incubator PMC
  Member wih karma for the authorizations file)/td
  /tr
  tr
 -  td-..-../td
 +  td2012-12-26/td
  

Re: First attempt at January2013 report template

[Tim Williams]

Hmm... is that the right reporting group?

http://incubator.apache.org/report-groups.txt

Thanks,
--tim


On Sat, Dec 29, 2012 at 8:03 PM, Greg Stein gst...@gmail.com wrote:
 Looks good.

 btw: http://wiki.apache.org/incubator/January2013
  On Dec 29, 2012 6:42 PM, Benson Margulies bimargul...@gmail.com wrote:

 On Sat, Dec 29, 2012 at 5:50 PM, Christian Grobmeier
 grobme...@gmail.com wrote:
  On Sat, Dec 29, 2012 at 11:25 PM, Benson Margulies
  bimargul...@gmail.com wrote:
  On Sat, Dec 29, 2012 at 4:57 PM, Christian Grobmeier
  grobme...@gmail.com wrote:
  I like these templates.
  Not sure if it is that important, but I always wanted to have some
  kind of table of content which shows which projects are reporting. I
  am usually only reading the reports of a few projects (except those i
  am involved of course). Now as it is generated it might be just a
  minor mod to your python. If not I still like the tool
 
  Yes. I can make a TOC go tick. No links, because the eventual board
  delivery is plain text.
 
  I would enjoy that very much, even without clickable links

 there is a TOC in the latest posted version.

 Keep those suggestions coming :-)



 
  Thanks!
 
 
 
 
  Cheers
 
  On Sat, Dec 29, 2012 at 10:29 PM, Benson Margulies
  bimargul...@gmail.com wrote:
  Sort Order Is Repaired.
 
  On Sat, Dec 29, 2012 at 4:00 PM, Benson Margulies 
 bimargul...@gmail.com wrote:
  On Sat, Dec 29, 2012 at 3:34 PM, Dave Fisher dave2w...@comcast.net
 wrote:
 
  On Dec 29, 2012, at 11:39 AM, Benson Margulies wrote:
 
  I've used my improved clutch2report.py tool to push a template for
  January 2013. It includes some extra bits to help me (or anyone
 else)
  notice missing signoffs and reports.
 
  I like these.
 
  Prior versions were sorted alphabetically by name.
 
  Well, *that* would be sensible. Please no one add any reports, I
  definitely want to fix that.
 
 
 
 
  Of course, it uses the clutch as of today.
 
  Would folks prefer that I wipe this out until closer to the event,
 or
  should I leave it?
 
  It should be changed to reflect other events like Photark
 retirement and Openmeetings delay. I'm not sure it matters if you do that
 in the wiki or with the script.
 
  that requires the clutch to be up to date. Note that OM isn't really
 graduated.
 
 
 
 
 -
  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
 
 
 
 
  --
  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
 
 
  -
  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
 

 -
 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: More and better report nagging

[Tim Williams]

On Mon, Dec 17, 2012 at 7:56 AM, Christian Grobmeier
grobme...@gmail.com wrote:
 On Mon, Dec 17, 2012 at 1:24 PM, Benson Margulies bimargul...@gmail.com 
 wrote:
 On Mon, Dec 17, 2012 at 5:54 AM, Christian Grobmeier
 grobme...@gmail.com wrote:
 I really don't object, but when the podling has graduated, they don't
 have such a reminder.

 What I am trying to say: the podling gets an reminder. It should be
 possible to just write this report without nagging. If they don't do
 it, it's a signal that something went wrong. Now if you nag,
 somebody would do it finally. But it would no longer reflect if people
 actually care on the project or just want to make these e-mails stop.

 Please have mercy upon me. I'm the chair. I'm responsible for a
 complete report. I found it labor intensive to check for all the
 reports, and to manually nag the laggards. If it makes you feel
 better, you could view this as my personal tool to automate a task
 that I have to do anyway.

 I have mercy. Do whatever you think fits best to you.

 In my opinion constant nagging is not necessary - did not report
 does the job as well as this line is a report as well; if a project
 constantly fails report to report its more a matter to retirement than
 to play kindergardener.

FWIW, I feel the same.  I'd rather see 'did not report' and let the
IPMC look for that pattern. Maybe just have your template generator
default to DNR in the text?

--tim

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

Re: More and better report nagging

[Tim Williams]

On Mon, Dec 17, 2012 at 7:48 PM, Benson Margulies bimargul...@gmail.com wrote:
 On Mon, Dec 17, 2012 at 7:35 PM, Marvin Humphrey mar...@rectangular.com 
 wrote:
 On Mon, Dec 17, 2012 at 4:04 PM, Tim Williams william...@gmail.com wrote:
 FWIW, I feel the same.  I'd rather see 'did not report' and let the
 IPMC look for that pattern. Maybe just have your template generator
 default to DNR in the text?

 +1 on defaulting to DNR.

 How about sending out the whole Incubator report to all podling dev lists,
 every month?  That way the DNR shows up without an IPMC member having to
 notice and take action.  But in addition, it increases podling exposure to
 other projects and to the ASF at large.

 An alternative is to send it out to only the podlings that are reporting for 
 a
 cycle, but that's more work and doesn't serve the purpose of connecting the
 podling to being in the Incubator quite so cleanly.


 I feel  all that we are all volunteers, that podlings are volunteers
 who don't necessarily have their organizational act together, and that
 calling them out for DNR is not a very effective technique to
 providing the supervision that we, as a PMC, are on the hook for.  So
 I'm inclined for now to nag, and to spend a few minutes making that
 job less labor-intensive.

I'm beginning to think your mind's made up and the original question
was a pleasantry, but in case not...

I hold a different view of things.  While I think that we, ok you, are
on the hook for a board report, we've (PMC) delegated[1] the reporting
of each podling to the mentors that we approved for that podling.  We
aren't calling out the podling as DNR - we're calling out their
mentor as DNR.  If there's additional nags to go out, I'd do my
default to DNR and send the nag to the mentors directly.

Ultimately, making that job less labor-intensive involves getting
mentors and would-be-mentors to realize they can't simply go around
spewing their seeds as absentee fathers - it's a real commitment; to
the podling and to the foundation.  Shucks, keeping a record of
deadbeat mentors would prolly help...

In the end though, you've a thankless and tough job, so consider these
as constructive thoughts to be readily ignored in favor of whatever it
takes to get your job done:)

Thanks,
--tim

[1] - 
http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Mentor

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

Re: [Incubator Wiki] Update of December2012 by BensonMargulies

[Tim Williams]

fyi, Blur just finished their monthly reporting obligation.  I
miscalculated where we'd end up when I set it up initially and we
should be in group 2 vs. group 3. I've updated podlings.xml, I'll
remove us from December, if anyone knows anywhere else needing updated
let me know...

--tim

On Mon, Dec 3, 2012 at 7:13 PM, Apache Wiki wikidi...@apache.org wrote:
 Dear Wiki user,

 You have subscribed to a wiki page or wiki category on Incubator Wiki for 
 change notification.

 The December2012 page has been changed by BensonMargulies:
 http://wiki.apache.org/incubator/December2012?action=diffrev1=11rev2=12

   = Incubator board report, December 2012 =
 +
 +
 + == Shepherd Assignments ==
 +
 + Dave Fisher: Allura, Etch
 +
 + Jukka Zitting: Bloodhound
 +
 + Matt Franklin: HCatalog
 +
 + Matt Hogstrom: Ripple, Kalumet
 +
 + Ross Gardler: Wave, Open Meeting
 +
 + Roman Shaposhnik: cTakes, S4
 +
 + Suresh Marru: Blur, Drill
 +
 + Alan Cabrera: Flex, Hadoop Development Tools

   {{{
   Chair report goes here

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


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

Re: December reporting: All Mentors Please Sign Off and general note

[Tim Williams]

On Sat, Dec 1, 2012 at 12:54 PM, Benson Margulies bimargul...@gmail.com wrote:
 First of several reminders:

 For podlings reporting in December, we'd like *all* mentors to sign
 off on the reports. I hope to use this to get a clearer picture of
 where we have mentor weaknesses.

 General note: if you are a PPMC member or mentor, and you feel that
 your community is undersupplied with Mentor attention (e.g., you have
 trouble getting votes for releases), please start a thread here.

The report is meant to communicate this sort of health info...

--tim

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

Re: Retirement decision making

[Tim Williams]

On Wed, Nov 28, 2012 at 8:42 AM, Benson Margulies bimargul...@gmail.com wrote:

 2: While I appreciate that mentors are not entirely fungible, I tend
 to think in terms of a limited pool of volunteer effort, so indefinite
 incubation worries me.

It's their decision to volunteer their efforts in that way so I don't
think the IPMC should have any worries with how mentors spend their
time - let's leave that for their spouses to worry with.

I suggest a policy of A project will be retired from the incubator
when it is the consensus of the PPMC or when the PPMC fails to attract
enough qualified mentors.  ... in hopes that the second half of that
will ultimately address the 'indefinite' concern...

Thanks,
--tim

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

Re: September Reports

[Tim Williams]

Hi Jukka,
You'll need to add Blur to these rotations I reckon

Thanks,
--tim

On Saturday, September 8, 2012, Jukka Zitting wrote:

 Hi,

 With apologies for the lateness, here are the shepherd assignments for
 this month:

   Benson Margulies - Cordova, Flex, S4
   Dave Fisher  - Ambari, HCatalog
   Jukka Zitting- Bloodhound, Kalumet, OpenOffice
   Matt Franklin- Isis, NPanday, Wave
   Matt Hogstrom- Bigtop, Openmeetings
   Ross Gardler - Etch

 Let me know if you won't have time for the review by Wednesday.

 For background to this month's reports, here's how the projects got
 categorized last time they reported:

   No release: Bloodhound, Cordova, Flex, Kalumet, S4, Openmeetings, Wave
   Low activity: Ambari
   Low diversity: Bigtop
   Ready to graduate: Etch, HCatalog, Isis, NPanday, OpenOffice

 Has there been progress since then, and if not, is there a concrete
 plan for moving forward?

 BR,

 Jukka Zitting

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

reporting schedule

[Tim Williams]

is there a new page that lists the reporting schedule?  The old
page[1] just has a link to next month but I'm interested in knowing
*this* month.

Thanks,
--tim

[1] - http://wiki.apache.org/incubator/ReportingSchedule

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

Re: reporting schedule

[Tim Williams]

Drats, found it as soon as i hit send...

http://incubator.apache.org/report-groups.txt

--tim

On Sat, Sep 1, 2012 at 7:09 AM, Tim Williams william...@gmail.com wrote:
 is there a new page that lists the reporting schedule?  The old
 page[1] just has a link to next month but I'm interested in knowing
 *this* month.

 Thanks,
 --tim

 [1] - http://wiki.apache.org/incubator/ReportingSchedule

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

Re: [VOTE] Apache OpenOffice Community Graduation Vote

[Tim Williams]

On Sat, Aug 25, 2012 at 10:53 PM, Rob Weir robw...@apache.org wrote:
 On Fri, Aug 24, 2012 at 4:35 PM, Greg Stein gst...@gmail.com wrote:
 On Fri, Aug 24, 2012 at 4:00 PM, Rob Weir robw...@apache.org wrote:

 snip

 I can give the IPMC a hand here, if my point is too obscure.  A policy
 might look like this:

 Resolved:   An Apache project's release consists of a canonical source
 artifact, voted on and approved by the PMC.  A PMC can also distribute
 additional, non-source artifacts, including documentation, binaries,
 samples, etc., that are provided for the convenience of the user.
 These non-source artifacts must must be buildable from the canonical
 source artifact.  Additional 3rd party libraries may be included
 solely in compliance with license policies defined by Apache Legal
 Affairs.  Additionally the non-source artifacts (or the PMC) must
 and must not _.

 That's existing policy. As people keep saying (most recently, Joe, in
 no uncertain terms).


 Hi Greg,

 And Joe, as I'm sure you noticed, also said:

 THERE IS NO PROBLEM HERE,
 CURRENT POLICY FULLY COVERS WHAT AOO ACTUALLY
 DOES.  END OF DISCUSSION.

 This is my understanding as well.

 In any case, you seem to agree with the wording that I gave above,
 since you say it represents existing policy.  Since I can find no
 place on the IPMC or ASF website where this policy is actually stated
 (and please correct me if I missed it), it might be good if we took my
 summary from above and put it into the Podling Release Guide.  I know
 there is an ongoing effort to clean up the IPMC website.  I'd be happy
 to submit a patch.

Marvin gave the link earlier in this thread. 4th para is the relevant bit.

http://www.apache.org/dev/release.html#what

--tim

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

Re: Status of Blur?

[Tim Williams]

Hi Otis,
Nice!  yeah, we're bootstrapping now...  join us on blur-dev@i.a.o and
blur-user@i.a.o

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

The ticket's in now to get the git repo up too.

Thanks,
--tim

On Tue, Aug 7, 2012 at 8:05 PM, Otis Gospodnetic
otis_gospodne...@yahoo.com wrote:
 Hi,

 What's the word on Blur?  The Proposal went well, VOTE thread got all +1s 
 back on July 20th, but not sure if anything is happening with it now and 
 I'm itching! :)

 Thanks,
 Otis
 

 Search Analytics - http://sematext.com/search-analytics/index.html
 Scalable Performance Monitoring - http://sematext.com/spm/index.html

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

Re: [VOTE] Graduation of DirectMemory as a TLP

[Tim Williams]

With the following votes, this vote passes.  I'll submit a suggested
resolution to the board shortly.  Thanks everyone who voted and
supported the DirectMemory community through their incubation...

+1's Binding:
- Tim Williams
-  Olivier Lamy
- Jean-Baptiste Onofre
- Jukka Zitting
- Daniel Kulp
- Ant Elder
- Christian Grobmeier
- Bertrand Delacretaz

+1's Non-Binding:
- Raffaele Guidi
- Gaurav Sharma
- Tommaso Teofill
- Alexei Fedotov
- Maurizio Cucchiara
- Simone Tripodi
- Benoit Perroud
- Daniel Manzke
- Ashish

Concluded with no -1's
--tim

On Tue, Jul 31, 2012 at 6:22 PM, Tim Williams william...@gmail.com wrote:
 The DirectMemory community is ready to graduate and become a full TLP.
  We began incubation in October 2011 and have demonstrated our ability
 to function according to the Apache Way.  We've successfully made a
 release.  We have begun to grow the community.  We didn't hold a
 separate formal vote - it's not a requirement - but the sense of the
 community is that we're ready to go[1].

 Please VOTE to submit the below resolution to the board for consideration:

 [ ] +1 DirectMemory graduates to TLP
 [ ] -1 DirectMemory isn't ready, because...

 Vote will remain open for 72hrs...

 Thanks,
 --tim

 [1] - http://markmail.org/thread/3j4q7xehzn72dhk4



 X. Resolution to establish the Apache DirectMemory Project

 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 a
second level, off-heap, cache able to store large amounts of
 data without filling
up the Java heap and thus avoiding long garbage collection cycles.

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

RESOLVED, that The Apache DirectMemory Project be and hereby is
responsible for the creation and maintenance of a software
project related to a second level off-heap cache; and be it further

RESOLVED, that the office of Vice President, DirectMemory 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
DirectMemory Project, and to have primary responsibility for
management of the projects within the scope of responsibility of
The Apache DirectMemory 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 DirectMemory Project:

  * Ioannic Canellos (iocanel)
  * Maurizio Cucchiara (mcucchiara)
  * Christian Grobmeier (grobmeier)
  * Olivier Lamy (olamy)
  * Raffaele P. Guidi (raffaeleguidi)
  * Simone Gianni (simoneg)
  * Simone Tripodi (simonetripodi)
  * Tommaso Teofill (tommaso)
  * Benoit Perroud (bperroud)

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Raffaele P.
Guidi be and hereby is appointed to the office of Vice
President, DirectMemory, 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 DirectMemory Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator DirectMemory podling; and be it further

RESOLVED, that all responsibility pertaining to the Apache
Incubator DirectMemory podling encumbered upon the Apache Incubator
PMC are hereafter discharged.

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

Re: [VOTE] Graduation of DirectMemory as a TLP

[Tim Williams]

On Wed, Aug 1, 2012 at 7:57 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
 Hi,

 On Wed, Aug 1, 2012 at 12:22 AM, Tim Williams william...@gmail.com wrote:
 The DirectMemory community is ready to graduate and become a full TLP.
 [...]
 Please VOTE to submit the below resolution to the board for consideration:

 [x] +1 DirectMemory graduates to TLP

 second level, off-heap, cache able to store large amounts of data without
 filling up the Java heap and thus avoiding long garbage collection cycles.

 That's a pretty tight definition of scope. How about just off-heap
 cache for the Java platform? That should be specific enough to
 differentiate DirectMemory from other similar projects, and generic
 enough to better allow evolution of your architecture and key use
 cases down the line.

Sounds good, hopefully such a small change wouldn't require revoting?

--tim

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

[VOTE] Graduation of DirectMemory as a TLP

[Tim Williams]

The DirectMemory community is ready to graduate and become a full TLP.
 We began incubation in October 2011 and have demonstrated our ability
to function according to the Apache Way.  We've successfully made a
release.  We have begun to grow the community.  We didn't hold a
separate formal vote - it's not a requirement - but the sense of the
community is that we're ready to go[1].

Please VOTE to submit the below resolution to the board for consideration:

[ ] +1 DirectMemory graduates to TLP
[ ] -1 DirectMemory isn't ready, because...

Vote will remain open for 72hrs...

Thanks,
--tim

[1] - http://markmail.org/thread/3j4q7xehzn72dhk4



X. Resolution to establish the Apache DirectMemory Project

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 a
   second level, off-heap, cache able to store large amounts of
data without filling
   up the Java heap and thus avoiding long garbage collection cycles.

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

   RESOLVED, that The Apache DirectMemory Project be and hereby is
   responsible for the creation and maintenance of a software
   project related to a second level off-heap cache; and be it further

   RESOLVED, that the office of Vice President, DirectMemory 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
   DirectMemory Project, and to have primary responsibility for
   management of the projects within the scope of responsibility of
   The Apache DirectMemory 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 DirectMemory Project:

 * Ioannic Canellos (iocanel)
 * Maurizio Cucchiara (mcucchiara)
 * Christian Grobmeier (grobmeier)
 * Olivier Lamy (olamy)
 * Raffaele P. Guidi (raffaeleguidi)
 * Simone Gianni (simoneg)
 * Simone Tripodi (simonetripodi)
 * Tommaso Teofill (tommaso)
 * Benoit Perroud (bperroud)

   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Raffaele P.
   Guidi be and hereby is appointed to the office of Vice
   President, DirectMemory, 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 DirectMemory Project be and hereby
   is tasked with the migration and rationalization of the Apache
   Incubator DirectMemory podling; and be it further

   RESOLVED, that all responsibility pertaining to the Apache
   Incubator DirectMemory podling encumbered upon the Apache Incubator
   PMC are hereafter discharged.

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

Re: [VOTE] Graduation of DirectMemory as a TLP

[Tim Williams]

On Tue, Jul 31, 2012 at 6:22 PM, Tim Williams william...@gmail.com wrote:
 The DirectMemory community is ready to graduate and become a full TLP.
  We began incubation in October 2011 and have demonstrated our ability
 to function according to the Apache Way.  We've successfully made a
 release.  We have begun to grow the community.  We didn't hold a
 separate formal vote - it's not a requirement - but the sense of the
 community is that we're ready to go[1].

 Please VOTE to submit the below resolution to the board for consideration:

 [ ] +1 DirectMemory graduates to TLP
 [ ] -1 DirectMemory isn't ready, because...

My own +1...

--tim

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

Re: [VOTE] Accept Blur into the Apache Incubator

[Tim Williams]

 that
 currently use Blur are committed to improving the codebase of the
 project due to its fulfilling needs not addressed by any other
 software. In addition, one customer is providing financial support to
 further develop Blur given its importance on mission-critical
 projects.

 === Inexperience with Open Source ===
 The codebase has been treated internally as an open source project
 since its beginning, and Near Infinity has extensive experience
 developing and releasing open source projects
 (http://www.nearinfinity.com/products/open_source). We do not
 anticipate difficulty in operating under the Apache Way.

 === Homogeneous Developers ===
 Current developers are all employed by Near Infinity but we are
 actively seeking contributors from different companies and would
 welcome their participation.

 === Reliance on Salaried Developers ===
 Blur was originally created by Aaron !McCurry as a personal project
 and he remains the primary contributor.  Currently, Aaron’s employer
 (Near Infinity) fully supports his continued participation with paid,
 dedicated time to work on Blur. All other current developers are paid
 by Near Infinity to work on Blur as well.

 === Relationships with Other Apache Products ===
 Blur dependencies:

  * Apache Hadoop
  * Apache Lucene
  * Apache !ZooKeeper
  * Apache Thrift
  * Apache log4j

 === Apache Brand ===
 Our interest in releasing this code as an Apache project is due to its
 strong relationship with other Apache projects, i.e. Blur has
 dependencies on Hadoop, Lucene, !ZooKeeper, and Thrift and its
 uniqueness within the Hadoop ecosystem.

 == Documentation ==
 Current documentation can be found at http://blur.io and
 https://github.com/nearinfinity/blur.

 == Initial Source ==
 Blur has been in development since summer 2010. The core codebase
 consists of about ~29,000 (~10,000 if the generated RPC code is not
 included) lines of code mainly Java.

 == Source and Intellectual Property Submission Plan ==
 Blur core code, examples, documentation, and training materials will
 be submitted by Near Infinity Corporation.

 == External Dependencies ==
  * concurrentlinkedhashmap - Apache 2.0 License -
 http://code.google.com/p/concurrentlinkedhashmap/

 == Cryptography ==
 none

 == Required Resources ==
  * Mailing Lists
* blur-private
* blur-dev
* blur-commits
* blur-user
  * Subversion Directory
* https://git-wip-us.apache.org/repos/asf/blur.git
  * Issue Tracking
* JIRA
  * Continuous Integration
* Jenkins
  * Web
* http://incubator.apache.org/blur/wiki at http://wiki.apache.org
 or http://cwiki.apache.org

 == Initial Committers ==
  * Aaron !McCurry (aaron.mccurry at nearinfinity dot com)
  * Scott Leberknight (scott.leberknight at nearinfinity dot com)
  * Ryan Gimmy (ryan.gimmy at nearinfinity dot com)
  * Tim Williams (twilliams at apache dot org)
  * Patrick Hunt (phunt at apache dot org)
  * Doug Cutting (cutting at apache dot org)

 == Affiliations ==
  * Aaron !McCurry, Near Infinity
  * Scott Leberknight, Near Infinity
  * Ryan Gimmy, Near Infinity
  * Patrick Hunt, Cloudera
  * Doug Cutting, Cloudera

 == Sponsors ==
  * Champion: Patrick Hunt

 == Nominated Mentors ==
  * Tim Williams  (twilliams at apache dot org)
  * Doug Cutting (cutting at apache dot org)
  * Patrick Hunt (phunt at apache dot org)

 == Sponsoring Entity ==
  * Apache Incubator

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

Re: inadequate graduation requests being filed with infra

[Tim Williams]

On Wed, Jul 11, 2012 at 10:22 AM, Joe Schaefer joe_schae...@yahoo.com wrote:
 While the new move to push podlings towards graduation is
 something I'm happy to see, lately the quality of the tickets
 being filed with INFRA has hit new lows, bogging down the
 process considerably.

 I don't know if some docs have recently changed or need fixing,
 but the situation sucks for the sysadmins trying to complete
 this work in a timely fashion.  Whether we need to go back to
 filing a single ticket containing all the necessary details or
 continue to break things down into subtickets does not concern
 me, but the lack of detail in these requests is strikingly bad
 and needs to be addressed by the IPMC.  Thanks.

Hi Joe,
Can you point to a ticket [or tickets] from a graduating podling that
got it right?

Thanks,
--tim

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

Re: DirectMemory status (Was: Shepherding: chukwa, mesos, directmemory)

[Tim Williams]

On Tue, Jul 10, 2012 at 2:36 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
 Hi,

 On Sun, Jul 1, 2012 at 11:59 PM, Niall Pemberton
 niall.pember...@gmail.com wrote:
 On Sun, Jul 1, 2012 at 8:46 PM, Benson Margulies bimargul...@gmail.com 
 wrote:
 DirectMemory lacks only a release to be green across the launch control 
 board.

 Looks like a release is imminent:
 markmail.org/message/a3yczwysqognrtg4

 The release is now out, so given Benson's overview from above I
 classified DirectMemory as ready to graduate.

 The DirectMemory report says the following on this topic:

 + There is only one important issue to address in the move towards graduation
 +
 +- Understanding process/decision making guidelines (new committer process
 +  is undergoing testing, release process still yet to be worked out)

 I suppose the release process is now covered. I notice DirectMemory
 has already added a committer since incubation started, so there's
 already some experience on that as well. And with many Apache members
 as committers I think the project is in any case pretty well covered
 on the process side.

 So from my perspective it looks like DirectMemory is close to
 graduation. The only bit I'm a bit uncertain about is the burstiness
 of DirectMemory activity (with notable spikes in November, February
 and June), though that shouldn't be too troublesome as there's a
 steady level of base activity and it looks like the June burst is
 continuing well into this month.

 Does that (and my classification as ready to graduate) sound like an
 accurate assessment of DirectMemory status?

I suppose.  Though, it's not clear why we're answering that question
on general@ instead of letting the mentors run through the graduation
guide with the community?  This list is chatty though, so perhaps I
missed something?

FWIW, this shepherd thing is starting to feel like [duplicative]
middle-management.  I'd strongly encourage a more passive board-style
role (e.g. stepping in only when a problem exists).

The burstiness, btw, is likely a result of this being a true
volunteer effort - AFAIK, no one's being paid to hack on it.

Thanks,
--tim

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

Re: Board will be proposing a new TLP

[Tim Williams]

Incubation is unnecessary process in this case.  I don't see any reason
this should go through incubation.

--tim

On Saturday, June 30, 2012, Jim Jagielski wrote:

 For those not following board@, the board is proposing the creation
 of a new TLP (tentatively called Apache Steve) which will serve as
 the project behind our STV and voting tools.

 The impetus behind this was when I suggested to the OpenStack
 people to use STV for their voting system, which kind of re-kicked
 the idea in my head that our voting tools were too good to not
 provide as releasable code to the world at large.

 Since all code was developed w/i the ASF, by ASF people, and
 is under the ALv2 (either implied/confirmed by the authors or
 explicit in the code itself), there is some debate on whether
 or not Incubation is even required... The board would like to
 recommend to the Incubator that the board simply proceed with
 the creation of this project at the next board meeting.

 Thx.

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

Re: svn commit: r1354971 - /incubator/public/trunk/content/guides/graduation.xml

[Tim Williams]

On Thu, Jun 28, 2012 at 8:38 AM, sebb seb...@gmail.com wrote:
 On 28 June 2012 13:12,  twilli...@apache.org wrote:
 Author: twilliams
 Date: Thu Jun 28 12:12:43 2012
 New Revision: 1354971

 URL: http://svn.apache.org/viewvc?rev=1354971view=rev
 Log:
 typo

 Modified:
    incubator/public/trunk/content/guides/graduation.xml

 Modified: incubator/public/trunk/content/guides/graduation.xml
 URL: 
 http://svn.apache.org/viewvc/incubator/public/trunk/content/guides/graduation.xml?rev=1354971r1=1354970r2=1354971view=diff
 ==
 --- incubator/public/trunk/content/guides/graduation.xml [utf-8] (original)
 +++ incubator/public/trunk/content/guides/graduation.xml [utf-8] Thu Jun 28 
 12:12:43 2012
 @@ -72,7 +72,7 @@
             /p
             p

 -                The road to graduation pretty clear: depending on wether 
 your
 +                The road to graduation pretty clear: depending on whether 
 your

 Missing verb in first phrase?

I was actually fixing the wether mispelling - I didn't even catch that one:)

--tim

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

Re: [VOTE] [PROPOSAL] Allura to enter the Incubator

[Tim Williams]

+1
--tim

On Thu, Jun 21, 2012 at 12:34 PM, Rich Bowen rbo...@rcbowen.com wrote:
 Hi,

 We are proposing Allura to be admitted to the Apache Incubator, and would 
 like to request that the IPMC votes on this issue. The requisite 72 hours has 
 passed since the initial proposal.

 The proposal may be found at http://wiki.apache.org/incubator/AlluraProposal

 Please cast your vote.
 [ ] +1 I recommend that Allura becomes an Apache Incubator project
 [ ] 0 Abstain or don't care
 [ ] -1 No, I do not recommend that Allura becomes an Apache Incubator project 
 yet (because ...)



 --
 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: Rich you need to requestg IPMC membership (was: Re: [VOTE] [PROPOSAL] Allura to enter the Incubator)

[Tim Williams]

On Thu, Jun 21, 2012 at 4:06 PM, Ross Gardler
rgard...@opendirective.com wrote:
 Rich, I note you mark your vote as non-binding.

 To be a champion/mentor you need to be an IPMC member. Since you are
 already an SF member you just need to ask and Jukka will sort it out.

For the archives... it's his Apache membership that allows that to happen:)

--tim

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

Re: [VOTE] CloudStack for Apache Incubator

[Tim Williams]

On Mon, Apr 9, 2012 at 9:32 PM, Kevin Kluge kevin.kl...@citrix.com wrote:
 Hi All.  I'd like to call for a VOTE for CloudStack to enter the Incubator.  
 The proposal is available at [1] and I have also included it below.   Please 
 vote with:
 +1: accept CloudStack into Incubator
 +0: don't care
 -1: do not accept CloudStack into Incubator (please explain the objection)

 The vote is open for at least 72 hours from now (until at least 19:00 US-PST 
 on April 12, 2012).

+1

Thanks,
--tim

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

Re: [VOTE] Jukka Zitting for IPMC Chair (was Re: NOMINATIONS for Incubator PMC Chair)

[Tim Williams]

On Thu, Feb 9, 2012 at 10:16 AM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
 Hi Folks,

 OK there has been enough discussion here. It's time to VOTE for a new IPMC
 chair and it looks like the remaining folks (including me) that were in the 
 running
 have aligned beyond the following nominee: Jukka Zitting. Suffice to say, he 
 was
 *my first choice* :)

 In the interest of moving the current discussion matters forward, please VOTE
 on this recommendation to the board by the IPMC. I'll leave the VOTE open
 for at least the next 72 hours:

 [ ] +1 Recommend Jukka Zitting for the IPMC chair position.
 [ ] +0 Don't care.
 [ ]  -1 Don't recommend Jukka Zitting for the IPMC chair position because...

+1

--tim

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

Re: [VOTE] Jukka Zitting for IPMC Chair (was Re: NOMINATIONS for Incubator PMC Chair)

[Tim Williams]

On Thu, Feb 9, 2012 at 2:31 PM, Jim Jagielski j...@jagunet.com wrote:

 On Feb 9, 2012, at 2:00 PM, Sam Ruby wrote:

 On Thu, Feb 9, 2012 at 10:24 AM, Benson Margulies bimargul...@gmail.com 
 wrote:
 +1 (binding)

 +1 (binding)

 From my perspective, Chris's proposal and Benson's vote above
 effectively turned this into a single issue question: is now the time
 for Noah to be replaced by Jukka?

 There are no question that all four individuals in question are great
 guys.  However despite the protestations to the contrary, all
 available evidence at the present time show that Jukka has more time
 available to devote to the Incubator.  This means that we have here a
 (possibly only modestly incremental) improvement, and one that is
 readily reversible if necessary.  What's not to like?


 I'd still like a definitive list of who is running and a real
 vote that includes all candidates. Is the presumption that Jukka
 is the only candidate valid??

Not as far as I can find...

http://mail-archives.apache.org/mod_mbox/incubator-general/201202.mbox/%3ccmeclhigikfcophdfpnooeifpaab.n...@devtech.com%3E

--tim

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

Re: principles of Apache communities

[Tim Williams]

On Thu, Feb 2, 2012 at 1:08 AM, David Crossley cross...@apache.org wrote:
 Joe Schaefer wrote:
 Here are some of the things that guide me in my decision-
 making about governance and Apache communities.  Please
 feel to add you own thoughts on the subject!

 1) Fairness and Equitable Treatment- that it is wrong to apply
 different standards to different people based solely on their
 (external) accrued status.

 2) Tolerance- that we respect the diversity of opinion without
 the need for tit-for-tat arguments about who is right.

 3) Fun- that the nature of participation here is personally
 satisfying and not onerous.

 4) Consistency- that we don't apply different standards to
 different people based on whatever hot topic is currently being
 debated.

 5) Competence- that we entrust people who are most familiar with
 the work being performed to exercise their oversight and judgement
 about the codebase.

 6) Empowerment- that people who show sustained levels of competence
 and oversight capabilities are rewarded with higher levels of
 organizational responsibility.

 [more later]

 Good stuff.

 For ages i have wanted to add a page somewhere that explains
 very clearly principles and constraints for the ASF.
 Alas little time and none now.

It's funny you use 'constraints', I did a little thought experiment[1]
with an analogy comparing system constraints-system properties to
organizational constraints-desired properties a while back.  As I
mentioned there, I'm sure the analogy breaks down somewhere but it'd
sure be nice to have some framework to agree on our desired
organizational/cultural properties, then reason about what real
constraints are in place and how/why they evoke those desired
properties.  I forget what motivated me then, I think it was a round
of debate over some phantom constraints/rules/policy.

--tim

[1] - 
http://williamstw.blogspot.com/2010/05/architecture-of-governance-structures.html

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

Re: [Incubator Wiki] Update of February2011 by brianleroux

[Tim Williams]

Wrong year:)

--tim

On Tue, Jan 31, 2012 at 6:02 PM, Apache Wiki wikidi...@apache.org wrote:
 Dear Wiki user,

 You have subscribed to a wiki page or wiki category on Incubator Wiki for 
 change notification.

 The February2011 page has been changed by brianleroux:
 http://wiki.apache.org/incubator/February2011?action=diffrev1=62rev2=63



  Signed off by mentor: bdelacretaz (champion)
 +
 + 
 + Cordova
 +
 + Apache Cordova is a platform for building native mobile applications using 
 HTML, CSS and JavaScript. The project entered incubation as Apache Callback 
 in October, 2011, before changing its name to Cordova.
 +
 + January could be characterized as the month where we hit our stride on 
 Apache infra. Tonnes of updates to the code. Huge activity on the mailing 
 list. Two new committers voted in.
 +
 + Currently, we recognize the majority of commits are currently coming from 
 Adobe and IBM actively pushing to our repositories on git-wip-us (6 and 4 
 active pushers respectively). We aim to add more contributors in coming 
 releases as per The Apache Way.
 +
 + * shipped 1.4 (NOTE: we aim to make 1.5 our first official apache release)
 + * continued code migration to Cordova name
 + * new Apache Cordova logo!
 + * project web site design iteration
 + * new automated build system code named 'coho'
 + * Yohei Shimomae voted as committer
 + * Steve Gill voted as committer
 + * made progress on the IP review
 +
 + Graduation concerns:
 +
 + * Complete the IP review (source headers, license metadata, etc.)
 + * Continue to foster more community committers
 + * Ship an official Apache release
 +
 + Signed off by mentor:
 +
 +
 +
 +

  
  Deltacloud

 -
 To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org
 For additional commands, e-mail: cvs-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] Apache ACE as a TLP

[Tim Williams]

+1

--tim

On Sat, Dec 17, 2011 at 6:55 AM, Marcel Offermans
marcel.offerm...@luminis.nl wrote:
 Hello all,

 As the discussion about the resolution [1] offered no further feedback, it is 
 time for the Apache ACE community to request that the IPMC vote on 
 recommending this resolution [2] to the ASF board.

 Please cast your vote:

 [ ] +1 to recommend ACE's graduation
 [ ]  0 don't care
 [ ] -1 no, don't recommend yet, (because...)

 The vote will be open for 72 hours.

 Greetings, Marcel


 [1] http://markmail.org/thread/wfrvwmnu3y22oxys

 [2] see below:

 ## Resolution to create a TLP from graduating Incubator podling

    X. Establish the Apache ACE Project

       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 management and deployment
       of OSGi based and other software artifacts 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 ACE Project,
       be and hereby is established pursuant to Bylaws of the
       Foundation; and be it further

       RESOLVED, that the Apache ACE Project be and hereby is
       responsible for the creation and maintenance of software
       related to the management and deployment of OSGi based and
       other software artifacts;
       and be it further

       RESOLVED, that the office of Vice President, Apache ACE 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 ACE Project, and to have primary responsibility
       for management of the projects within the scope of
       responsibility of the Apache ACE 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 ACE Project:

         * Angelo van der Sijpt     ange...@apache.org
         * Brian Topping            btopp...@apache.org
         * Clement Escoffier        clem...@apache.org
         * Carsten Ziegeler         cziege...@apache.org
         * Jean-Baptiste Onofre     jbono...@apache.org
         * Karl Pauls               kpa...@apache.org
         * Marcel Offermans         ma...@apache.org
         * Toni Menzel              to...@apache.org

       NOW, THEREFORE, BE IT FURTHER RESOLVED, that Marcel Offermans
       be appointed to the office of Vice President, Apache ACE, 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 ACE PMC be and hereby is
       tasked with the creation of a set of bylaws intended to
       encourage open development and increased participation in the
       Apache ACE Project; and be it further

       RESOLVED, that the Apache ACE Project be and hereby
       is tasked with the migration and rationalization of the Apache
       Incubator ACE podling; and be it further

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


 Note to moderators: I sent this message before, over 24 hours ago, with my 
 apache e-mail address (that is not subscribed to this list). It's still stuck 
 in moderation, which is why I'm sending it again today. If ultimately both 
 end up on the list, my apologies, I will summarize the responses over both 
 messages.


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

When are board reports due?

[Tim Williams]

Marvin says... supply board reports 2 weeks before the above date
(Wed, Dec 7th).

The December report[1] says... reports are due here by the first day
of the month

And the reporting schedule[2] says... should have their reports ready
by no later than the second Wednesday of that month (Wed, Dec 14th in
this case).

I reckon the board's recent decision of 1 week notice has caused some
docs to be out of sync and I've probably missed the discussion.  What
is the correct due date?

Thanks,
--tim

[1] -  http://wiki.apache.org/incubator/December2011

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

Re: When are board reports due?

[Tim Williams]

On Fri, Dec 2, 2011 at 8:33 AM, sebb seb...@gmail.com wrote:
 On 2 December 2011 13:11, Tim Williams william...@gmail.com wrote:
 Marvin says... supply board reports 2 weeks before the above date
 (Wed, Dec 7th).

 That's Incubator Marvin, who requires podlings to provide an extra week's 
 notice

 The December report[1] says... reports are due here by the first day
 of the month

 Not sure about that discrepancy.

 And the reporting schedule[2] says... should have their reports ready
 by no later than the second Wednesday of that month (Wed, Dec 14th in
 this case).

 The link is missing, but I assume that's Board Marvin who e-mails PMCs.

Ooops... no, that's the ReportSchedule wiki page - I didn't look at
board's marvin:

http://wiki.apache.org/incubator/ReportingSchedule

Unless someone says otherwise, I'll stick with Incubator's marvin as
sebb suggested...

Thanks,
--tim

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

Re: [VOTE] Release for Bigtop version 0.2.0-incubating RC2

[Tim Williams]

On Sun, Nov 6, 2011 at 6:33 PM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 Since the official vote cut-off date has passed, I'd like to gently
 remind that, with 6 +1 votes from the community members we
 would be very grateful if somebody from the IPMC can take a look
 at the bits and give us the feedback.

Hi Roman,
Is there a KEYS file?  I'm getting a public key not found and I
don't see a KEYS file to import them from?

Thanks,
--tim

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

Re: Establishing New Committers

[Tim Williams]

On Fri, Nov 4, 2011 at 9:32 AM, Ross Gardler rgard...@opendirective.com wrote:
 You might consider this nit-picking but it might also be important at
 some point in the future.

 You use the phrase committ rights in this template. They are not
 rights they are privileges. The reason this might be important is
 that very occasionally it is necessary for a PMC to remove these
 privileges, it is one of the few blunt instruments available for
 solving community issues that have got out of hand.

 The wording of this template won't change this, but this is your first
 opportunity to communicate that this is a privilege and not a right.
 The PMC can choose to give and take this privilege as they see fit.

 That being said, thank you for improving this template, I've added
 your enhancements to the original template over at ComDev (along with
 the modification suggested by Craig).

Hi Ross,
These look familiar, where in svn can I look for these improved
versions? and, are they accessible to all committers?

Thanks,
--tim

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

Incubator docs

[Tim Williams]

The PMC Guide page[1] seems to be redundant information with the
Mentor Guide page[2].  Is there a reason for the PMC Guide to
remain?  The reason I ask is, they're currently inconsistent (re: svn
auth) and - while the PMC Guide appears correct - I found the Mentor
Guide more helpful.

Thanks,
--tim

[1] - http://incubator.apache.org/guides/pmc.html
[2] - http://incubator.apache.org/guides/mentor.html#Set+Up+Repository

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

Re: [VOTE] accept DirectMemory as new Apache Incubator podling

[Tim Williams]

+1

--tim

On Sunday, October 2, 2011, Ashish paliwalash...@gmail.com wrote:
 +1

 On Sun, Oct 2, 2011 at 1:06 PM, Simone Tripodi simonetrip...@apache.org
wrote:
 Hi all guys,

 I'm now calling a formal VOTE on the DirectMemory proposal located here:

 http://wiki.apache.org/incubator/DirectMemoryProposal

 Proposal text copied at the bottom of this email.

 VOTE close on Tuesday, October 4, early 7:30 AM CET.

 Please VOTE:

 [ ] +1 Accept DirectMemory into the Apache Incubator
 [ ] +0 Don't care
 [ ] -1  Don't Accept DirectMemory into the Apache Incubator because...

 Thanks in advance for participating!

 All the best, have a nice day,
 Simo

 P.S. Here's my +1

 http://people.apache.org/~simonetripodi/
 http://www.99soft.org/

 = DirectMemory =

 == Abstract ==
 The following proposal is about Apache !DirectMemory, a Java
 !OpenSource multi-layered cache implementation featuring off-heap
 memory storage (a-la Terracotta !BigMemory) to enable caching of Java
 objects without degrading JVM performance

 == Proposal ==
 !DirectMemory's main purpose is to to act as a second level cache
 (after a heap based one) able to store large amounts of data without
 filling up the Java heap and thus avoiding long garbage collection
 cycles. Although serialization has a runtime cost store/retrieve
 operations are in the sub-millisecond range being pretty acceptable in
 every usage scenario even as a first level cache and, most of all,
 outperforms heap storage when the count of the entries goes over a
 certain amount. !DirectMemory implements cache eviction based on a
 simple LFU (Least Frequently Used) algorythm and also on item
 expiration. Included in the box is a small set of utility classes to
 easily handle off-heap memory buffers.

 == Background ==
 !DirectMemory is a project was born in the 2010 thanks to Raffaele P.
 Guidi initial effort under
 [[https://github.com/raffaeleguidi/!DirectMemory/|GitHub 
https://github.com/raffaeleguidi/!DirectMemory/%7CGitHub]] and already
 licensed under the Apache License 2.0.

 == Rationale ==
 The rationale behind !DirectMemory is bringing off-heap caching to the
 open source world, empowering FOSS developers and products with a tool
 that enables breaking the heap barrier and override the JVM garbage
 collection mechanism collection - which could be useful in scenarios
 where RAM needs are over the usual limits (more than 8, 12, 24gb) and
 to ease usage of off-heap memory in general

 = Current Status =

 == Meritocracy ==
 As a majority of the initial project members are existing ASF
 committers, we recognize the desirability of running the project as a
 meritocracy.  We are eager to engage other members of the community
 and operate to the standard of meritocracy that Apache emphasizes; we
 believe this is the most effective method of growing our community and
 enabling widespread adoption.

 == Core Developers ==
 In alphabetical order:

  * Christian Grobmeier grobmeier at apache dot org
  * Maurizio Cucchiara mcucchiara at apache dot org
  * Olivier Lamy olamy at apache dot org
  * Raffaele P. Guidi raffaele dot p dot guidi at gmail dot com
  * Simone Gianni simoneg at apache dot org
  * Simone Tripodi simonetripodi at apache dot org
  * Tommaso Teofili tommaso at apache dot org

 == Alignment ==
 The purpose of the project is to develop and maintain !DirectMemory
 implementation that can be used by other Apache projects.

 = Known Risks =
 == Orphaned Products ==
 !DirectMemory does not have any reported production usage, yet, but is
 getting traction with developers and being evaluated by potential
 users and thus the risks of it being orphaned are minimal

 == Inexperience with Open Source ==
 All of the committers have experience working in one or more open
 source projects insi--
 thanks
 ashish

 Blog: http://www.ashishpaliwal.com/blog
 My Photo Galleries: http://www.pbase.com/ashishpaliwal

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

Re: [DISCUSS] DirectMemory to join the Apache Incubator

[Tim Williams]

Discussion seems to have waned and with an overall positive vibe - are
we ready to call the vote?

Thanks,
--tim

On Tue, Sep 20, 2011 at 5:48 AM, Simone Tripodi
simonetrip...@apache.org wrote:
 Hi all guys,
 I would like to propose DirectMemory, a Java OpenSource multi-layered
 cache implementation featuring off-heap memory storage (a-la
 Terracotta BigMemory) originally developed by Raffaele P. Guidi on
 GitHub[1], to be an Apache Incubator project. For those interested on
 knowing more about DirectMemory, you can read Raffaele's related
 blog[2].

 Here's a link to the proposal in the Incubator wiki[3] where we
 started collecting all needed info.

 As you will note, the list of mentors is in need of some volunteers,
 so if you find this interesting, feel free to sign up or let us know
 you are interested :).

 Hope to read from you soon, thanks in advance and have a nice day!
 All the best,
 Simo

 [1] https://github.com/raffaeleguidi/DirectMemory
 [2] http://raffaeleguidi.wordpress.com/
 [3] http://wiki.apache.org/incubator/DirectMemoryProposal

 http://people.apache.org/~simonetripodi/
 http://www.99soft.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] S4 to join the Incubator

[Tim Williams]

On Tue, Sep 20, 2011 at 4:56 PM, Patrick Hunt ph...@apache.org wrote:
 It's been a nearly a week since the S4 proposal was submitted for
 discussion.  A few questions were asked, and the proposal was clarified
 in response.  Sufficient mentors have volunteered.  I thus feel we are
 now ready for a vote.

 The latest proposal can be found at the end of this email and at:

  http://wiki.apache.org/incubator/S4Proposal

 The discussion regarding the proposal can be found at:

  http://s.apache.org/RMU

 Please cast your votes:

 [  ] +1 Accept S4 for incubation
 [  ] +0 Indifferent to S4 incubation
 [  ] -1 Reject S4 for incubation

+1

--tim

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

Re: [DISCUSS] DirectMemory to join the Apache Incubator

[Tim Williams]

On Tue, Sep 20, 2011 at 5:48 AM, Simone Tripodi
simonetrip...@apache.org wrote:
 Hi all guys,
 I would like to propose DirectMemory, a Java OpenSource multi-layered
 cache implementation featuring off-heap memory storage (a-la
 Terracotta BigMemory) originally developed by Raffaele P. Guidi on
 GitHub[1], to be an Apache Incubator project. For those interested on
 knowing more about DirectMemory, you can read Raffaele's related
 blog[2].

 Here's a link to the proposal in the Incubator wiki[3] where we
 started collecting all needed info.

 As you will note, the list of mentors is in need of some volunteers,
 so if you find this interesting, feel free to sign up or let us know
 you are interested :).

 Hope to read from you soon, thanks in advance and have a nice day!
 All the best,
 Simo

Hi Simo, well done, a couple questions:

- the proposal doesn't have a champion, wouldn't that be you?

- are the core developers listed actively committing code to the project?

I like it, happy to help mentor if needed...
Thanks,
--tim

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

Re: Confusion: Sponsoring entity and Champions

[Tim Williams]

On Tue, Sep 20, 2011 at 12:46 PM, Christian Grobmeier
grobme...@gmail.com wrote:
 On Tue, Sep 20, 2011 at 5:56 PM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
 On Tue, Sep 20, 2011 at 5:46 PM, Martijn Dashorst
 martijn.dasho...@gmail.com wrote:
 IMO the champion helps clarify the incubator process up to acceptance
 of the podling into the incubator. For example the champion for Wicket
 was not a singular person, but both Alex Karasulu and Upayavira were
 both very instrumental in smoothing our transition into the incubator.

 general@ can be very confusing and sometimes even hostile towards new
 podlings. Having a champion watching out for the podling is rather
 useful

 Agreed, IMO the role of the champion is to help the podling get
 started (which might include help find a sponsor, mentors etc) and
 they might only follow things from afar once that's done.

 So, why do we need a role for that?

 I rarely see the call We need a champion on the mailinglsit. So I
 assume that these persons are somehow connected to the project before.
 Or they read the draft-proposal and contact people directly.

 At the moment it looks as it is required to have a Champion. I don't
 think so. It should be optional, if we really need such a role.

It seems to that it is a mostly pre-incubation job in only certain
projects.  But it seems useful that one person would step forth and
claim to be the champion of bringing a certain project to the ASF and
[implicitly] agree to pushing down any artificial process hurdles.  It
seems like we've had such hurdles and brave champions in the past but
I'm too lazy to dig right now...

--tim

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

Re: [VOTE] Accumulo to join the Incubator

[Tim Williams]

On Fri, Sep 9, 2011 at 12:22 PM, Doug Cutting cutt...@apache.org wrote:
 It's been a week since the Accumulo proposal was submitted for
 discussion.  A few questions were asked, and the proposal was clarified
 in response.  Sufficient mentors have volunteered.  I thus feel we are
 now ready for a vote.

 The latest proposal can be found at the end of this email and at:

  http://wiki.apache.org/incubator/AccumuloProposal

 The discussion regarding the proposal can be found at:

  http://s.apache.org/oi

 Please cast your votes:

 [  ] +1 Accept Accumulo for incubation
 [  ] +0 Indifferent to Accumulo incubation
 [  ] -1 Reject Accumulo for incubation

+1, welcome!

--tim

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

Re: [VOTE] Deft to join the incubator

[Tim Williams]

On Tue, Jul 5, 2011 at 6:35 AM, Niklas Gustavsson nik...@protocol7.com wrote:
 Hi,

 With three mentors graciously signed up and the discussion around the
 proposal settling, it's time for a vote on Deft joining the incubator.

 The latest proposal can be found below, or in the wiki:

 http://wiki.apache.org/incubator/DeftProposal

 For discussions:
 http://www.mail-archive.com/general@incubator.apache.org/msg29659.html

 Please cast your votes:

 [  ] +1 Accept Deft for incubation
 [  ] +0 Indifferent to Deft incubation
 [  ] -1 Reject Deft for incubation

 Vote will be running for 72 hours.

+1, best wishes...

--tim

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

Re: [VOTE] Accept OpenOffice.org for incubation

[Tim Williams]

-1

As a foundation, we are optimized to support delivery of open source
code, it seems to me OOo and its user/community/the public would be
best served by an organization built for the delivery of a finished
end-user product.  OOo would be such an anomaly for us I fear would
lead to an embarrassing chapter.

--tim

On Fri, Jun 10, 2011 at 12:02 PM, Sam Ruby ru...@intertwingly.net wrote:
 *** Please change your Subject: line for any [DISCUSSION] of this [VOTE]

 As the discussions on the OpenOfficeProposal threads seem to be winding
 down, I would like to initiate the vote to accept OpenOffice.org as an
 Apache Incubator project.

 At the end of this mail, I've put a copy of the current proposal.  Here is a
 link to the document in the wiki:

 http://wiki.apache.org/incubator/OpenOfficeProposal?action=recallrev=207

 As the proposal discussion threads are numerous, I encourage people to scan
 and review the archives for this month:

 http://mail-archives.apache.org/mod_mbox/incubator-general/201106.mbox/browser

 Please cast your votes:

 [  ] +1 Accept OpenOffice.org for incubation
 [  ] +0 Indifferent to OpenOffice.org incubation
 [  ] -1 Reject OpenOffice.org for incubation

 This vote will close 72 hours from now.

 - Sam Ruby

 = OpenOffice.org - An open productivity environment =
 == Abstract ==
 !OpenOffice.org is comprised of six personal productivity applications: a
 word processor (and its web-authoring component), spreadsheet, presentation
 graphics, drawing, equation editor, and database. !OpenOffice.org is
 released on Windows, Solaris, Linux and Macintosh operation systems, with
 more [[http://porting.openoffice.org/|communities]] joining, including a
 mature  [[http://porting.openoffice.org/freebsd/|FreeBSD port]].
 !OpenOffice.org is localized, supporting over 110 languages worldwide.

 == Proposal ==
 Apache !OpenOffice.org will continue the mission pursued by the
 !OpenOffice.org project while under the sponsorship of Sun and Oracle,
 namely:

 To create, as a community, the leading international office suite that
  will run on all major platforms and provide access to all functionality and
  data through open-component based APIs and an XML-based file format.

 In addition to to building the !OpenOffice.org product, as an end-user
 facing product with many existing individual and corporate users, this
 project will also be active in supporting end-users via tutorials, user
 forums, document template repositories, etc.  The project will also work to
 further enable !OpenOffice.org to be used as a programmable module in
 document automation scenarios.

 == Background ==
 !OpenOffice.org was launched as an open source project by Sun Microsystems
 in June 2000.  !OpenOffice.org was originally developed under the name of
 StarOffice by Star Division, a German company, which was acquired by Sun
 Microsystems in 1999.  Sun released this as open source in 2000.
  !OpenOffice.org is the leading alternative to MS-Office available.  Its
 most recent major version, the 3.x series saw over
 [[http://www.webmasterpro.de/portal/news/2010/02/05/international-openoffice-market-shares.html|100
 million downloads]] in its first year.  The
 [[http://www.webmasterpro.de/portal/news/2010/02/05/international-openoffice-market-shares.html|most
 recent estimates]] suggest a market share on the order of 8-15%.

 The !OpenOffice source is written in C++ and delivers language-neutral and
 scriptable functionality. This source technology introduces the next-stage
 architecture, allowing use of the suite elements as separate applications or
 as embedded components in other applications. Numerous other features are
 also present including XML-based file formats based on the vendor-neutral
 !OpenDocument Format (ODF) standard from OASIS and other resources.

 == Rationale ==
 !OpenOffice.org core development would continue at Apache following the
 contribution by Oracle, in accordance with Apache bylaws and its usual open
 development processes. Both Oracle and ASF agree that the !OpenOffice.org
 development community, previously fragmented, would re-unite under ASF to
 ensure a stable and long term future for OpenOffice.org. ASF would enable
 corporate, non-profit, and volunteer stakeholders to contribute code in a
 collaborative fashion.

 Supporting tooling projects will accompany the !OpenOffice.org contribution,
 providing APIs for extending and customizing !OpenOffice.org.

 Both !OpenOffice.org and the related tooling projects support the OASIS Open
 Document Format, and will attract an ecosystem of developers, ISVs and
 Systems Integrators. ODF ensures the users of !OpenOffice.org and related
 solutions will own their document data, and be free to choose the
 application or solution that best meets their requirements.

 The !OpenOffice.org implementation will serve as a reference implementation
 of the Open Document Format standard.

 = Current Status =
 == Meritocracy ==
 We understand the intention and value 

Re: [PROPOSAL] Mesos Project

[Tim Williams]

On Mon, Dec 13, 2010 at 5:08 PM, Matei Zaharia ma...@apache.org wrote:
 We would like to propose Mesos as an incubator proposal.

+1, best wishes...

--tim

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

Re: [VOTE] Accept Wave into the incubator

[Tim Williams]

On Tue, Nov 30, 2010 at 1:52 AM, Dan Peterson dpeter...@google.com wrote:
 Hi everyone,

 Please vote on the acceptance of Wave into the Apache incubator.

 The proposal is available at: http://wiki.apache.org/incubator/WaveProposal
 (for your convenience, a snapshot is also copied below)

 The earlier discussion thread can be found at:
 http://apache.markmail.org/message/3ebtccdxvipp2732?q=general%40incubator.apache.org+list:org.apache.incubator.general+order:date-backwardpage=2

 The vote options:

 [ ] +1 Accept Wave for incubation
 [ ] +0 Don't care
 [ ] -1 Reject for the following reason:

+1

--tim

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

Re: [Proposal] Accept Jena into the Incubator

[Tim Williams]

+1

On Fri, Nov 12, 2010 at 12:00 PM, Sander W G van der Waal
sander.vanderw...@oucs.ox.ac.uk wrote:
 +1 (non-binding)

 Sander

 From: Ross Gardler [mailto:rgard...@apache.org]
 Sent: 08 November 2010 23:37
 To: general@incubator.apache.org
 Subject: [Proposal] Accept Jena into the Incubator

 I am pleased to offer, for your consideration, the following proposal to
 accept Jena, a semantic web framework into the incubator. The text of
 the proposal is copied here for your convenience and can be found at
 http://wiki.apache.org/incubator/JenaProposal

 We currently have two mentors so we're looking for at least one more.

 Note that there is already an overlapping discussion about interaction
 between this and other semantic web projects in the incubator. As
 champion of this proposal I have recommended that the Jena team
 participate in this discussion. I'm not able to speak for the Jena
 committers, but I am keen to see *appropriate* sharing of code between
 projects.

 However, I don't believe that this should be forced upon the three
 projects as part of their incubation. Such collaboration should emerge
 through community engagement, with mentor guidance, rather than through
 incubator conditions of entry or graduation.

 Comments and volunteers welcome.

 Now for the proposal:

 = Jena, a Semantic Web Framework =
 == Abstract ==
 Jena is a semantic web framework for Java, based on W3C standards.

 == Proposal ==
 Jena provides a semantic web framework in Java that implements the key
 W3C recommendations for the core semantic web technologies of RDF and
 SPARQL.  Jena is a number of components and modules built on this core
 system.  It currently includes:

   * an API for working with RDF
   * Parsers and writers for the RDF formats (RDF/XML, Turtle, N-triples,
 NQuads, TriG)
   * an implementation of SPARQL, the W3C standard RDF query language
   * multiple storage systems for RDF data including in-memory,
 file-backed, in SQL databases and in custom scalable storage systems
   * an API for manipulation of OWL
   * a rule-based inference engine
   * an implementation of GRDDL for extraction of RDF from XML formats
   * a standards compliant IRI library.

 The project includes facilities based around this core to encourage the
   creation of components and contributions both as part of Jena and also
   as companion open source activities.

 This proposal includes the main components of Jena: the main Jena
 download, ARQ, GRDDL, SDB, TDB, the IRI  library and Joseki.  Other
 components may be contributed later - we're  just starting with the main
 part of Jena for now.

 == Background ==
 The W3C recommendations provide detailed specifications and it is
 important to follow these standards so that independently built
 applications can exchange data over the web.  Jena provides high quality
   Java implementations of RDF input/output and storage so that
 application  writers can concentrate on the application, not the
 low-level details.

 W3C Semantic Web: http://www.w3.org/standards/semanticweb/

 Jena has been on !SourceForge since 2001.
 http://sourceforge.net/projects/jena/

 == Rationale ==
 The open source project was originally created as part of a research
 activity in HPLabs.  In building new systems, the researchers identified
   the value of a common platform that dealt with the low level details
 of  the standards.  This lead to engagement with the standards process
 and  the creation of a framework that provided a library to deal with
 the  details of semantic web standards.  This work was released as Jena.
 The  developers have contributed implementation experience back to the
 working groups.

 None of the contributors now work for HP.  Providing a uniform
 contributor and licensing framework assists commercial use of Jena.

 == Current Status ==
 Jena is already an established project with a large user base in
 industry and academia.  It currently uses a BSD-style three-clause
 license with a number of contributing copyright holders. Support is
 primarily provided via the jena-...@groups.yahoo.com mailing list. The
 majority of the team was employed in HPLabs, and HP holds the majority
 of the copyright over the code - there are contributions from non-HP
 companies.  HP decided to close the research group as of October 2009
 and the people from HPLabs connected with the project have moved on to
 several different semantic web companies.

 This change does not immediately affect Jena because the people who were
   in HP still remain active contributors to Jena.  The project continues
 to be supported and actively enhanced.  There is now the  opportunity to
 become an open source project without a single large  organisation
 involved.

 === Meritocracy ===
 The Jena team has always been self-determining; there has not been a
 project manager in charge of the effort.  Instead, it has grown through
   individuals contributing to the codebase as part of their research
 activities.  The 

Re: [VOTE] ALOIS to enter the incubator

[Tim Williams]

On Thu, Sep 16, 2010 at 7:16 AM, Christian Grobmeier
grobme...@gmail.com wrote:
 All,

 this vote will fail in three hours because nobody responds to it. Are
 there any objections against this proposal? Or why is this vote
 ignored?

Hi Christian,
I ignored it because it was odd to me that there's essentially no
further info about the project.  I'm wondering why they don't/haven't
begun open development (e.g. via Google Code or somesuch) on their own
initiative since the code's already GPL.  I dunno, they don't have
licensing problems and, so, if they believe in open source it's not
clear what was stopping them from open development already.

Well, that's part of the story anyway... I had those thoughts and,
upon reflecting on those thoughts, I began to realize that I have no
clue what the objective criteria is for entering incubation.  I am
unsure what would cause us to say no.  My vote here is now binding so
I thought it better to watch and learn how more experienced folk
rationalize this.  Anyway, that's bordering on too much information
but that's why *I* ignored it:)

--tim

 On Wed, Sep 15, 2010 at 4:06 PM, Urs Lerch m...@ulerch.net wrote:
 Hi everybody out there

 The vote for ALOIS ends in about 24 hours. Are there any more comments
 or votes? We would appreciate it to get to know your opinion.

 Best
 Urs



 Am Montag, den 13.09.2010, 11:33 -0400 schrieb Urs Lerch:
 Hi

 Since the first call a few weeks ago didn't suceed (more mentors were
 asked), I would like to call a second vote for accepting the security
 information and event management tool ALOIS for incubation in the
 Apache Incubator. Thanks Christian Grobmeier we now have two mentors at
 least. But any additional mentors are still warmly welcome. The full
 proposal is available below and on the proposal wiki page
 (http://wiki.apache.org/incubator/AloisProposal).

 Please cast your vote:

 [ ] +1, bring ALOIS into Incubator
 [ ] +0, I don't care either way,
 [ ] -1, do not bring ALOIS into Incubator, because...

 This vote will be open for 72 hours and, at least that's the way I
 understood, only votes from the Incubator PMC are binding.

 Thanks,
 Urs



 ---


 = Preface =

 ALOIS is a log collection and correlation software with reporting and
 alarming functionalities. It has been implemented by the Swiss company
 IMSEC for a customer about five years ago. GPL-licenced, implemented in
 Ruby and completely based on other OSS-licensed components, it was
 designed for the open source community right from the start. Now that
 the software has shown its functioning over several years in production
 with the one customer and one IMSEC-internal installation, it seems to
 be the right time to open it to a wider community.


 = Abstract =

 ALOIS stands for „Advanced Logging and Intrusion Detection System“ and
 is meant to be a fully implemented open source SIEM (security
 information and event management) system.


 = Proposal =

 While almost all other SIEM software, be it closed or open source,
 concentrate on the technological part of security monitoring, ALOIS is
 aimed to monitor the security of the content. It intends to be
 pro-active in the detection of potential loss, theft, mistaken
 modification or unauthorized access. ALOIS works on log messages and
 thus contains all the basic functionality of a conventional SIEM, as
 centralized collecting, normalizing, aggregation, analyzing and
 correlating of all log messages, as well as reporting all security
 related events. Therefore it can be used as any other SIEM.

 ALOIS consists of five modules interacting to ensure a scaleable
 functionality of a SIEM:

   * Insink is the message sink, which is the receiving entry point for
 all the different log messages into ALOIS. It is partly based on the
 syslog-ng software. Insink listens for messages (UDP), waits for
 messages (TCP), receives message collections (files, emails) and
 pre-filters them to prevent from message flow overload.

   * Pumpy is the incoming FIFO buffer, implemented as a relational
 database tables. which contain the incoming original messages (in raw
 format). In a complex system setup, there may be several insink
 instances, e.g. for a group of hosts, for specific types of messages, or
 for high-avaliablity.

   * Prisma contains logic to split up the text of log messages into
 separate fields, based on regular expressions. Actually, prisma is a
 set of prismi, each one prisma for one type of log message (apache,
 cisco etc. Several prismi can be applied to the same message. This
 allows for stacked messages, i.e. forwarded log messages contained in
 compressed files contained in e-mail messages. The data retrieved form
 the log messages is stored in a database called Dobby. Due to prisma
 being written in Ruby, prismi can be applied interactively (when having
 system access).

   * Dobby is the central log database. It should be separated from the
 

Re: [VOTE] ALOIS to enter the incubator

[Tim Williams]

I might be missing it, but is there a link to the existing GPL project/code?
Thanks
--tim

On Mon, Sep 13, 2010 at 11:33 AM, Urs Lerch m...@ulerch.net wrote:
 Hi

 Since the first call a few weeks ago didn't suceed (more mentors were
 asked), I would like to call a second vote for accepting the security
 information and event management tool ALOIS for incubation in the
 Apache Incubator. Thanks Christian Grobmeier we now have two mentors at
 least. But any additional mentors are still warmly welcome. The full
 proposal is available below and on the proposal wiki page
 (http://wiki.apache.org/incubator/AloisProposal).

 Please cast your vote:

 [ ] +1, bring ALOIS into Incubator
 [ ] +0, I don't care either way,
 [ ] -1, do not bring ALOIS into Incubator, because...

 This vote will be open for 72 hours and, at least that's the way I
 understood, only votes from the Incubator PMC are binding.

 Thanks,
 Urs



 ---


 = Preface =

 ALOIS is a log collection and correlation software with reporting and
 alarming functionalities. It has been implemented by the Swiss company
 IMSEC for a customer about five years ago. GPL-licenced, implemented in
 Ruby and completely based on other OSS-licensed components, it was
 designed for the open source community right from the start. Now that
 the software has shown its functioning over several years in production
 with the one customer and one IMSEC-internal installation, it seems to
 be the right time to open it to a wider community.


 = Abstract =

 ALOIS stands for „Advanced Logging and Intrusion Detection System“ and
 is meant to be a fully implemented open source SIEM (security
 information and event management) system.


 = Proposal =

 While almost all other SIEM software, be it closed or open source,
 concentrate on the technological part of security monitoring, ALOIS is
 aimed to monitor the security of the content. It intends to be
 pro-active in the detection of potential loss, theft, mistaken
 modification or unauthorized access. ALOIS works on log messages and
 thus contains all the basic functionality of a conventional SIEM, as
 centralized collecting, normalizing, aggregation, analyzing and
 correlating of all log messages, as well as reporting all security
 related events. Therefore it can be used as any other SIEM.

 ALOIS consists of five modules interacting to ensure a scaleable
 functionality of a SIEM:

  * Insink is the message sink, which is the receiving entry point for
 all the different log messages into ALOIS. It is partly based on the
 syslog-ng software. Insink listens for messages (UDP), waits for
 messages (TCP), receives message collections (files, emails) and
 pre-filters them to prevent from message flow overload.

  * Pumpy is the incoming FIFO buffer, implemented as a relational
 database tables. which contain the incoming original messages (in raw
 format). In a complex system setup, there may be several insink
 instances, e.g. for a group of hosts, for specific types of messages, or
 for high-avaliablity.

  * Prisma contains logic to split up the text of log messages into
 separate fields, based on regular expressions. Actually, prisma is a
 set of prismi, each one prisma for one type of log message (apache,
 cisco etc. Several prismi can be applied to the same message. This
 allows for stacked messages, i.e. forwarded log messages contained in
 compressed files contained in e-mail messages. The data retrieved form
 the log messages is stored in a database called Dobby. Due to prisma
 being written in Ruby, prismi can be applied interactively (when having
 system access).

  * Dobby is the central log database. It should be separated from the
 Pumpy database for availability and performance reasons. The current
 implementation is based on MySQL.

  * The Analyzer contains the two sub-systems Lizard and Reptor. Lizard
 is the analysis engine and user interface of ALOIS, implemented in Ruby
 on Rails using AJAX. It allows for interactive browsing through the
 collected data, exclusion/inclusion/selection of data, data sorting,
 data filtering, creation of views, ad-hoc textual and graphical
 reporting. Reptor allows for automatic activation of views and
 comparison of these views' results to a predefined result (pattern
 matching). In case of mismatch, Reptor sends the result to predefined
 e-mail addresses.

 Its modular design guarantees ALOIS to scale from little to large
 organizations. Since there exists a Debian package, it's easy to build a
 test system or even a productive system for small environments.

 Although the software has been in productive use for a few years, there
 is still a lot of desired functionality missing. The plugability of new
 connected systems is given, but needs some revision. It is a given goal
 of the project to allow modules in other programming language.
 Furthermore, it has been discussed if parts of the existing
 implementation 

Re: Role of Incubator PMC Votes

[Tim Williams]

On Thu, Sep 9, 2010 at 3:13 PM, Greg Stein gst...@gmail.com wrote:
 On Thu, Sep 9, 2010 at 14:11, Kalle Korhonen kalle.o.korho...@gmail.com 
 wrote:
 On Thu, Sep 9, 2010 at 10:51 AM, Greg Stein gst...@gmail.com wrote:
 On Thu, Sep 9, 2010 at 08:47, James Carman ja...@carmanconsulting.com 
 wrote:
 I haven't followed this particular issue because it seems like a
 slamdunk easy thing. If the podling wants to change their name, then
 fine. Sounds easy enough. I would see no reason for anybody outside
 the podling to -1 that choice, and might even say that I'd be upset if
 they did...

 Sure, the podling can change the name and it can be completely dealt
 with an internal matter. However, in this case, the name change was
 put up for a procedural/opinion vote on the incubator general list. As
 such, I might be upset if people are criticized for giving the wrong
 vote. Most non-positive votes in the thread are non-binding so the
 project can ignore them if they like, but if you don't want the
 opinion, don't put it up for a vote.

 As I said, I haven't followed it. I meant if the -1 was a veto. If the
 IPMC was vetoing a podling's choices on stuff like this. If you're
 only using a vote as a preference/opinion marker, then sure...
 definitely no problems with that!

That vote is majority rules, so the IPMC could in effect overrule the
project - the preference/opinion had already previously been
gathered.  In any case, I was using that instance to ask the broader
question of why we (IPMC) get binding votes on project matters.  It
seems to me that the healthy thing to do is closer to the board model
where we trust projects to do the right thing, ask for an ack, and
then only challenge the project on the basis of a
legal/release/trademark/etc issue.

If we tell the projects that you have to re-vote with the peanut
gallery, then the peanut gallery effect is predictable.  Those votes,
for example, are because they don't *like* the new name personally,
not because there's any real problems with it.

--tim

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

Role of Incubator PMC Votes

[Tim Williams]

I'm watching the renaming vote thread and I find it odd that folks
are -1-ing the project's vote.  I've read the role of the IPMC[1] and
the policy[2] and can't find the basis for our (IPMC) doing anything
other than ack-ing they're vote.  It seems like votes from the IPMC
should only be relevant/binding when the matter in question is
release/legal/trademark/etc-type issues that could [legally] effect
the foundation.  I dunno, this seems purely a project matter to me
(like a logo, code, etc.) - second-guessing a project team on these
sort of subjective things seems counter-productive to grooming
self-sustaining projects to me.  So, is this normal - why does the
IPMC really get anything more than an advising role in these sorts
of matters (and why is that healthy)?

Thanks,
--tim

[1] - 
http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29
[2] - 
http://incubator.apache.org/incubation/Incubation_Policy.html#Incubation+Policy

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

Re: Role of Incubator PMC Votes

[Tim Williams]

On Thu, Sep 9, 2010 at 8:32 AM, James Carman ja...@carmanconsulting.com wrote:
 name=trademark

Are you suggesting there are trademark concerns with the name the
project has chosen?  If so, then yes, that's a valid reason for the
IPMC to challenge a project's vote - as a part of 'grooming' them to
think through these things...  in other words, the basis for us
challenging the vote is trademark concern rather than I don't like
that name, it's too broad...

... but I haven't seen a mark concern brought up...

--tim

 On Thu, Sep 9, 2010 at 8:30 AM, Tim Williams william...@gmail.com wrote:
 I'm watching the renaming vote thread and I find it odd that folks
 are -1-ing the project's vote.  I've read the role of the IPMC[1] and
 the policy[2] and can't find the basis for our (IPMC) doing anything
 other than ack-ing they're vote.  It seems like votes from the IPMC
 should only be relevant/binding when the matter in question is
 release/legal/trademark/etc-type issues that could [legally] effect
 the foundation.  I dunno, this seems purely a project matter to me
 (like a logo, code, etc.) - second-guessing a project team on these
 sort of subjective things seems counter-productive to grooming
 self-sustaining projects to me.  So, is this normal - why does the
 IPMC really get anything more than an advising role in these sorts
 of matters (and why is that healthy)?

 Thanks,
 --tim

 [1] - 
 http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29
 [2] - 
 http://incubator.apache.org/incubation/Incubation_Policy.html#Incubation+Policy

 -
 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] Change name of Lucene Connectors Framework to Apache Connectors Framework

[Tim Williams]

On Wed, Sep 8, 2010 at 8:18 AM, Grant Ingersoll gsing...@apache.org wrote:
 Hi,

 After much debate both here and on the connectors mailing list, the LCF 
 community has voted (see 
 http://mail-archives.apache.org/mod_mbox/incubator-connectors-dev/201008.mbox/browser)
  and would like to officially change our name to be the Apache Connectors 
 Framework.  We would like the Incubator PMC to vote to make this official.

 [] +1 Change the Lucene Connector Framework to the Apache Connector Framework
 [] 0 Don't care
 [] -1 Don't change it

+1

...I don't personally like the name but not sure what the basis would
possibly be that the IPMC wouldn't just Ack this

--tim

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

Re: [VOTE] Isis to enter the incubator

[Tim Williams]

On Wed, Sep 1, 2010 at 5:42 AM, Dan Haywood dkhayw...@gmail.com wrote:
  The Isis proposal has now been updated with a champion and several new
 mentors (thanks again guys), and is ready to be voted on.

 The proposal is at: http://wiki.apache.org/incubator/IsisProposal , the text
 is also copied below.

 Please, cast your vote.

 [ ] +1, please indicate whether binding
 [ ] =0
 [ ] -1, please indicate your reason

+1, binding...

--tim

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

Re: [PROPOSAL] Apache Isis

[Tim Williams]

On Tue, Aug 31, 2010 at 6:28 AM, Dan Haywood dkhayw...@gmail.com wrote:
  On 30/08/2010 07:26, Tim Williams wrote:

 Your proposal caused me to poke around the NO site and the first forum
 topic I came upon[1] had someone providing a [simple] patch.  This has
 me curious about the code provenance.  Assuming this isn't the only
 one, could you say something about getting clearance from outside
 contributors?  At least, it seems to me that it could be slightly more
 complicated than the two parties you mention above.

 Just to update this thread... there have been very few patches historically.
  Indeed, we've searched through our email archives (back to 2002), through
 the SVN commit logs, and through the current codebase for any comments, and
 found only 1 one-liner from 2008, and the three patches in 2010 all from the
 same user (one of which was the patch you quoted).

 In addition, we have three contributors/committers who have made changes.

 What we're doing is contacting the guy who gave us these patches, and
 getting a formal ok from the existing contributors/committers; when I have
 this I'll update the proposal.

Hi Dan, that's great, you can just update your proposal to acknowledge
this and then solve it during incubation.  I think it's important to
identify these things prior to incubation but you can work it while
you're incubating [and, obviously, prior to any release]...

--tim

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

Re: [PROPOSAL] Apache Isis

[Tim Williams]

On Tue, Aug 24, 2010 at 1:12 PM, Dan Haywood dkhayw...@gmail.com wrote:
  I'd like to formally propose a new project for the incubator, Apache Isis.

... snipped

 == Source and IP Submission Plan ==
 As mentioned earlier, the NO framework is ASLv2 but copyright belongs to
 Naked Objects Group Ltd. NOGL is happy to donate the relevant rights to
 Apache, while Dan is also happy to donate the various sister projects that
 he has written. Having a single legal entity - ASF - owning the relevant
 rights to all this software would be very desirable.

Your proposal caused me to poke around the NO site and the first forum
topic I came upon[1] had someone providing a [simple] patch.  This has
me curious about the code provenance.  Assuming this isn't the only
one, could you say something about getting clearance from outside
contributors?  At least, it seems to me that it could be slightly more
complicated than the two parties you mention above.

Thanks,
--tim

[1] - 
http://sourceforge.net/projects/nakedobjects/forums/forum/544071/topic/3742184

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

Re: [PROPOSAL] Apache Isis

[Tim Williams]

On Mon, Aug 30, 2010 at 7:39 AM, Mohammad Nour El-Din
nour.moham...@gmail.com wrote:
 Hi Tim...

   From this link - http://sourceforge.net/projects/nakedobjects -
 project details section, it is stated that the code of this project is
 licensed under (Apache License v2.0), and hence it is the
 responsibility of the person who contributed any code to the project
 to understand that his/her contribution is going to be under the same
 license as long as it is committed as a patch to source code of
 project they contributed to, just like what happens from contributors
 contributing code to different Apache projects. I hope this can reply
 your question ? :)

Short answer is that I am not totally sure - I just saw that there
were clearly other sources for the code other than the two parties
mentioned and so I thought that should be highlighted in the IP
Clearance section.  The question, AIUI, isn't about the license of the
code being patched, it's the granting of the code in the patch itself.
 We ask contributors to either submit an ICLA or check the Grant for
inclusion... checkbox in JIRA.  I don't have a lot of Incubator
experience so I'll defer on this one, it just caught my eye - my own
understanding is that contributors would need to be tracked down[1].

--tim

[1] - http://incubator.apache.org/guides/mentor.html#initial-ip-clearance

 On Mon, Aug 30, 2010 at 11:26 AM, Tim Williams william...@gmail.com wrote:
 On Tue, Aug 24, 2010 at 1:12 PM, Dan Haywood dkhayw...@gmail.com wrote:
  I'd like to formally propose a new project for the incubator, Apache Isis.

 ... snipped

 == Source and IP Submission Plan ==
 As mentioned earlier, the NO framework is ASLv2 but copyright belongs to
 Naked Objects Group Ltd. NOGL is happy to donate the relevant rights to
 Apache, while Dan is also happy to donate the various sister projects that
 he has written. Having a single legal entity - ASF - owning the relevant
 rights to all this software would be very desirable.

 Your proposal caused me to poke around the NO site and the first forum
 topic I came upon[1] had someone providing a [simple] patch.  This has
 me curious about the code provenance.  Assuming this isn't the only
 one, could you say something about getting clearance from outside
 contributors?  At least, it seems to me that it could be slightly more
 complicated than the two parties you mention above.

 Thanks,
 --tim

 [1] - 
 http://sourceforge.net/projects/nakedobjects/forums/forum/544071/topic/3742184

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





 --
 Thanks
 - Mohammad Nour
   Author of (WebSphere Application Server Community Edition 2.0 User Guide)
   http://www.redbooks.ibm.com/abstracts/sg247585.html
 - LinkedIn: http://www.linkedin.com/in/mnour
 - Blog: http://tadabborat.blogspot.com
 
 Life is like riding a bicycle. To keep your balance you must keep moving
 - Albert Einstein

 Writing clean code is what you must do in order to call yourself a
 professional. There is no reasonable excuse for doing anything less
 than your best.
 - Clean Code: A Handbook of Agile Software Craftsmanship

 Stay hungry, stay foolish.
 - Steve Jobs

 -
 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: Name change from Lucene Connectors Framework to Apache Connectors Framework

[Tim Williams]

On Mon, Aug 30, 2010 at 1:23 PM, Benson Margulies bimargul...@gmail.com wrote:
 It seems to me that the pivotal problem here is the word connector. On
 the one hand, it could mean almost anything to almost anyone. On the
 other hand, it has a specific denotation in the vicinity of httpd.
 Everything at Apache is in the vicinity of httpd.

 I'd offer the following 'made-up' options, all following Apache:

  - manifold  (many connections)
  - omnivore (eats anything)
  - rapunzel (spins straw into gold)
  - diogenes (seeking for something)
  - lantern (ditto)
  - helium (fuel for Solr)

 The whole question of brand management strikes me as interesting: is
 it, in fact, the job of the incubator PMC to groom the Apache branding
 portfolio by guiding new projects towards better names? Is that in our
 charter, or should we, as Chris suggests, defer to someone else for
 problems in this area.

FWIW, I think we should defer to the project PMC to make their own
decision.  We can advise them that they're making a bad choice - as
has been done - but really, they can either take the advice or leave
it.  The important thing is that they come up with a name that they
can rally around.  Assuming they've done the mark searches, it's not
clear why we have much of a stake in this other than friendly
advice

--tim

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

Re: Subversion full/partial committer (was: Re: an experiment)

[Tim Williams]

On Thu, Aug 19, 2010 at 6:45 PM, Craig L Russell
craig.russ...@oracle.com wrote:
 I wish we had completed this discussion while subversion was still in
 incubation, while the subversion community could learn the common Apache
 terminology and have no need for translation of the terms.

 Instead, a suggestion to that effect was brutally shot down.

 And since it's apparently not clear what my point is, I'll repeat it:

 Apache has a common set of terms that everyone who participates is expected
 to understand. They are documented in the foundation How we work pages.

 Projects are free to have their own set of rules and terminology. If they
 differ much from standard Apache governance, there's an opportunity for them
 to have their own bylaws.

 When communicating with the wider Apache community, the standard terms are
 all that are needed. Parentheticals in such things as board reports, which
 are widely disseminated, might seem useful early in the project but are
 unnecessary very quickly. If they serve to clarify for the wider community,
 ok. But if parentheticals' only purpose is project communication, I believe
 that they are best avoided, as project members should know the Apache
 terminology (before exiting incubation).

Who cares?  This reeks to me of bureaucracy one might find at a
$dayjob.  I mean, the apache terms were used in the report, the
parentheticals were project-specific.  Eventually, they might simply
realize that the apache terminology is cool enough to use directly.
All board members are apparently competent enough to ignore the
parentheticals in their mind's eye - if they had a problem, they would
have mentioned it.  All will be ok, really.  This thread, like Joe's
thread, makes me wonder how such a pioneering group got such an
obeying/mother-may-i culture - it's nearly embarrassing.

--tim

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

Re: [VOTE] experimental delegation of new committer votes to PPMC

[Tim Williams]

On Wed, Aug 18, 2010 at 7:11 PM, Joe Schaefer joe_schae...@yahoo.com wrote:
 Now that the board has declared there are no legal
 obstacles to what I have proposed, I'd like to
 restart the vote.

 Thanks for your patience and consideration.

+1, happy experimenting!

--tim

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

Incubator proposal template

[Tim Williams]

I wonder why the proposal template doesn't explicitly ask the
proposers about their belief in the Apache Way?  It asks about
fascination with the Apache Brand and touch on it a bit in the
Alignment section.  But being that one could easily be fascinated by a
brand from the outside even while not agreeing with their internal
philosophies/methodologies (e.g. Apple), I wonder why we wouldn't want
some explicit discussion of this.  Since the Apache Way is a bit of an
amorphous thing, the section wouldn't really be a litmus test so much
as a way to ensure that they've fully considered the implications of
being a part of Apache.  Just curious...

Thanks,
--tim

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

Re: Incubator proposal template

[Tim Williams]

On Sat, May 29, 2010 at 10:42 AM, Sanjiva Weerawarana
sanj...@opensource.lk wrote:
 Do you seriously expect any answer other than yay of course to such a
 question??

Hi Sanjiva,
Yes, as I'd expect the question to be open-ended.. Why do you think
the Apache Way is a good fit for your project? (or somesuch)  In the
answer, we'd hope to learn if they get it.  We'd also be sure that,
to a certain extent, they'd researched and come to terms with its
elusive nature.  So, yeah, it was a sincere question...

--tim

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

Re: Help reviewing PhotArk podling release

[Tim Williams]

On Tue, Sep 8, 2009 at 7:22 PM, Luciano Resende luckbr1...@gmail.com wrote:
 On Tue, Sep 8, 2009 at 3:59 PM, sebbseb...@gmail.com wrote:
 On 08/09/2009, Luciano Resende luckbr1...@gmail.com wrote:
 Based on the current active members of the community, it's then going
  to be hard to get this release out !!!

 If by community you mean the IPMC, then the lack of response is
 perhaps because AFAICT there has not been a recent VOTE thread on the
 general incubator list. [This is not a VOTE thread]

 If you are referring to the Photark podling community, then the lack
 of activity has implications for graduation as well (there has been a
 VOTE thread there, which should have stirred some responses).


 It's more towards the latter, the PhotArk project is starting and his
 community is very small. While we have started some blogging/facebook
 advertisement for the podling, we are hoping to get a release out to
 get more people interested in the project.

I have a need for something like this coming up and have been
passively looking at PhotArk.  I'd suggest that a project like this
would do itself good by having a simple architecture diagram[1], some
good screenshots[2], and an ounce of documentation[3].  Otherwise,
it's tough for someone poking around to determine exactly *what* it is
and, thus, there's not enough [on the website] to get excited about
right now.  I know, it's a small team now and sort of a catch-22.  The
blogging is good, btw, it's what reminded me of you:)   Oddly enough,
I suspect these things would be more likely to generate developer
interest than a release would.  Anyway, just an opinion...

--tim


[1] - Example: http://couchdb.apache.org/
[2] - Example: http://lenya.apache.org/index/screenshots.html
[3] - http://incubator.apache.org/photark/documentation.html

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

Re: Clutch color coding

[Tim Williams]

On Thu, Dec 4, 2008 at 4:09 AM, David Crossley [EMAIL PROTECTED] wrote:
 David Crossley wrote:
 Tim Williams wrote:
 
  Hi David,

 Nice to hear from you Tim.

  I suppose you can't please everyone, but the red/green colors in this
  version are difficult to distinguish - colorblind.  It would help to
  find a shade of green with lighter/darker tone (e.g. 33cc66)?  Anyway,
  my nit-picky 2cents.

 That is a very important point.

 I will refine the colours today. Thanks for your help.

 Hey wow, i think we can please everyone.

 My searches led to the Color Universal Design (CUD)
 Colorblind barrier-free color Pallette
 by Masataka Okabe and Kei Ito. [1]
 They have developed a set of colours that are
 unambiguous.

 See my test page at
 http://people.apache.org/~crossley/cud/test.html

 The top section shows results for simulation for
 the new CUD scheme. The important parts of the table
 are emphasised for everybody.

It looks great David - it's nice to be able to just 'see' the
differences with colors vs. reading it:)  Thanks for doing the
research and taking the extra time to make this tool accessible to
everyone.

--tim

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Clutch color coding

[Tim Williams]

On Wed, Dec 3, 2008 at 2:30 AM, David Crossley [EMAIL PROTECTED] wrote:
 David Crossley wrote:
 Martijn Dashorst wrote:
 
  Clutch is an invaluable tool, but with some coloring issues according
  to me: the current coloring schema is not well suited to alert me, or
  they alert me at the wrong moment, or don't alert me when things get
  out of shape.

 ...
 Anyway, i will attempt to change to such new colours,
 yet still retain the encouragement.

 I am happy with the result.
 See http://incubator.apache.org/clutch.html
 after the next publishing rsync.

 There are some screenshots for comparison.
 http://people.apache.org/~crossley/temp/

Hi David,
I suppose you can't please everyone, but the red/green colors in this
version are difficult to distinguish - colorblind.  It would help to
find a shade of green with lighter/darker tone (e.g. 33cc66)?  Anyway,
my nit-picky 2cents.

--tim

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]